quickfix-users — QuickFIX user support

Re: [Quickfix-users] SessionQualifier and MySQL

[Oren M. <or...@qu...>]

Yeah, as I said, the qualifier was designed to be used with initiators.  
Also note that you cannot currently set up different acceptor sessions 
on different ports.  SocketAcceptPort can only exist in the DEFAULT 
section.  Therefore, every acceptor session in a single config file must 
share a port.  This may change in the future, but that is how it is 
right now.  Basically, what you are trying to do is not supported 
internally.  You would need to run multiple processes to do what you want.

--oren

Nikolay Parshutin wrote:

>QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html
>QuickFIX Support: http://www.quickfixengine.org/services.html
>
>
>No, it does not work.
>Error in acceptor: "Configuration failed: SessionQualifier cannot be used
>with acceptor."
>
>
>--
>View this message in context: http://www.nabble.com/SessionQualifier-and-MySQL-t1318780.html#a3531956
>Sent from the QuickFIX - User forum at Nabble.com.
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by xPML, a groundbreaking scripting language
>that extends applications into web and mobile media. Attend the live webcast
>and join the prime developer group breaking into this new coding territory!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
>_______________________________________________
>Quickfix-users mailing list
>Qui...@li...
>https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>
>  
>

Re: [Quickfix-users] SessionQualifier and MySQL

[Nikolay P. <ko...@xl...>]

No, it does not work.
Error in acceptor: "Configuration failed: SessionQualifier cannot be used
with acceptor."


--
View this message in context: http://www.nabble.com/SessionQualifier-and-MySQL-t1318780.html#a3531956
Sent from the QuickFIX - User forum at Nabble.com.

Re: [Quickfix-users] SessionQualifier and MySQL

[Joerg T. <Joe...@ma...>]

Nikolay Parshutin wrote:

Now we are getting to the point...

> -------------------------------------------------------executor.cfg----=
---------------------------------------------------
> [...]
> [SESSION]
> BeginString=3DFIX.4.2
> SenderCompID=3DEXECUTOR
> TargetCompID=3DCLIENT1
> FileStorePath=3Dstore
> SocketAcceptPort=3D5001

(I moved the SocketAcceptPort down from DEFAULT section...)

Where is the line "SessionQualifier=3DTC1"? Otherwise, the acceptor has n=
o way to know that=20
this is "TC1". As I said, the SessionQualifier is not FIX field and is no=
t transmitted=20
over the connection, but is just a kludge to differentiate sessions which=
 do not differ in=20
the BeginString, SenderCompID or TargetCompID field, but e.g. by ports.

Please add the matching lines with SessionQualifier to the executor.cfg, =
and it should work.

> -------------------------------------------------------tradeclient.cfg-=
---------------------------------------------------
> [...]
> [SESSION]
> BeginString=3DFIX.4.2
> SenderCompID=3DCLIENT1
> TargetCompID=3DEXECUTOR
> SessionQualifier=3DTC1
> SocketConnectPort=3D5001
>=20
> and wgat i've got with tradeclient:
> 1) Enter Order
> 2) Cancel Order
> 3) Replace Order
> 4) Market data test
> 5) Quit
> Action:
> Logon - FIX.4.2:CLIENT1->EXECUTOR:TC1

Hope that solves your issue.

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-users] SessionQualifier and MySQL

[Nikolay P. <ko...@xl...>]

I just compile executor sample with support of MySQL. I expacted that, even
single initated connection using Session Qualifier will be mirrored in
session table with SessionQuilifier field filled with corresponding value.
But it's empty! 
When I use FileStore instead MySQL database, sessions are stored, but then
apear error i explained before.

I don't understand, is SessionQuilifier works somewhere at all? If it does,
please, explain how. I have not found any clear documentation, exacmple or
usecase of that. 
If it doesn't, please, explain how can I append sessions without restarting
acceptor.


--
View this message in context: http://www.nabble.com/SessionQualifier-and-MySQL-t1318780.html#a3531314
Sent from the QuickFIX - User forum at Nabble.com.

Re: [Quickfix-users] SessionQualifier and MySQL

[Nikolay P. <ko...@xl...>]

Example about using SessionQuilifier with connections on different ports.
Using QuickFix examples executor and tradeclient with :
-------------------------------------------------------executor.cfg-------------------------------------------------------
[DEFAULT]
ConnectionType=acceptor
SocketAcceptPort=5001
StartTime=00:00:00
EndTime=00:00:00
DataDictionary=../spec/FIX42.xml

[SESSION]
BeginString=FIX.4.2
SenderCompID=EXECUTOR
TargetCompID=CLIENT1
FileStorePath=store

[SESSION]
BeginString=FIX.4.2
SenderCompID=EXECUTOR
TargetCompID=CLIENT1
FileStorePath=store
SocketAcceptPort=5002

[SESSION]
BeginString=FIX.4.2
SenderCompID=EXECUTOR
TargetCompID=CLIENT1
FileStorePath=store
SocketAcceptPort=5003

[SESSION]
BeginString=FIX.4.2
SenderCompID=EXECUTOR
TargetCompID=CLIENT1
FileStorePath=store
SocketAcceptPort=5004

-------------------------------------------------------tradeclient.cfg-------------------------------------------------------
[DEFAULT]
ConnectionType=initiator
HeartBtInt=30
FileStorePath=store
FileLogPath=log
StartTime=00:00:00
EndTime=00:00:00
UseDataDictionary=N
SocketConnectHost=localhost
SocketConnectPort=5001

[SESSION]
BeginString=FIX.4.2
SenderCompID=CLIENT1
TargetCompID=EXECUTOR
SessionQualifier=TC1
SocketConnectPort=5001


[SESSION]
BeginString=FIX.4.2
SenderCompID=CLIENT1
TargetCompID=EXECUTOR
SocketConnectPort=5002
SessionQualifier=TC2

[SESSION]
BeginString=FIX.4.2
SenderCompID=CLIENT1
TargetCompID=EXECUTOR
SocketConnectPort=5003
SessionQualifier=TC3

and wgat i've got with tradeclient:
1) Enter Order
2) Cancel Order
3) Replace Order
4) Market data test
5) Quit
Action:
Logon - FIX.4.2:CLIENT1->EXECUTOR:TC1

and executor printed no explanation of the reason why other sessions had not
log on

--
View this message in context: http://www.nabble.com/SessionQualifier-and-MySQL-t1318780.html#a3531315
Sent from the QuickFIX - User forum at Nabble.com.

Re: [Quickfix-users] SessionQualifier and MySQL

[Joerg T. <Joe...@ma...>]

Nikolay Parshutin wrote:
> However SessionQualifier is not written in session table, so we cant
> disambiguate identical sessions (except BeginString, SenderCompID,
> TargetCompID) even if connection set up on different ports.
>=20
> Maybe someone can intoduse another way of solving this problem?

OK, so you are saying that even with different ports it does not work in =
your case?

Please provide some code which demonstrates how you try to disambiguate i=
dentical=20
sessions. Maybe there is something missing in QF, which can be easily add=
ed.

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-users] SessionQualifier and MySQL

[Nikolay P. <ko...@xl...>]

Thank you for reply

That's not admissible for us to vary the compIDs. The proplem is that we
need to restart our acceptor when a new initator wants to connect acceptor. 

However SessionQualifier is not written in session table, so we cant
disambiguate identical sessions (except BeginString, SenderCompID,
TargetCompID) even if connection set up on different ports.

Maybe someone can intoduse another way of solving this problem?
--
View this message in context: http://www.nabble.com/SessionQualifier-and-MySQL-t1318780.html#a3530560
Sent from the QuickFIX - User forum at Nabble.com.

Re: [Quickfix-users] SessionQualifier and MySQL

[Oren M. <or...@qu...>]

Yeah, it was mostly designed to be used with initiators to get around =20=

a design flaw of some systems where they have different sessions =20
using the same session identifier on different ports.  The =20
functionality was not put in to enable this design flaw.  I would =20
reccommend instead that you vary the compIDs as is intended by the =20
protocol.

--oren

On Mar 22, 2006, at 2:57 AM, Joerg Thoennes wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Privet, Nikolay,
>
>> We're developing acceptor application, but the specific is that we =20=

>> want to
>> provide many clients to initiate sessions simultaneously. We use =20
>> QuickFIX
>> 1.11 with MySQL storing end logging. I tried to use =20
>> SessionQualifier, but it
>> doesn't works in way I expected. Two initators with same BeginString,
>> SenderCompID, TargetCompID and different SessionQualifier can't logon
>> simultaneously.
>> On acceptor side there are no record with nonempty =20
>> SessionQualifier field in
>> session table. One initator logins successfully, but all other =20
>> initator logs is flooded
>> with:
>> 20060321-16:41:08 : Connecting to localhost on port 5001
>> 20060321-16:41:09 : Connection succeeded
>> 20060321-16:41:09 : Initiated logon request
>> 20060321-16:41:09 : Socket Error: Connection reset by peer.
>> 20060321-16:41:09 : Disconnecting
>> Have you an idea, where is my mistake?
>
> The SessionQualifier was introduced -- if I recollect correctly -- =20
> to allow QF to manage several sessions with same SenderCompID and =20
> TargetCompID, _but_ different accept ports.
>
> Before that a QF session was uniquely identified by (BeginString, =20
> SenderCompID, TargetCompID).
>
> The important point in your case is that the SessionQualifier is =20
> _not_ transmitted over the wire, ie if both of your initiator =20
> clients has a different SessionQualifier configured, but connect to =20=

> the _same_ port with identical (BeginString, SenderCompID, =20
> TargetCompID), QF will forward these requests to the _same_ =20
> session, which results in the disconnects (since the session is =20
> already logged on).
>
> Please try with different ports for each different qualifier.
>
> Cheers, J=F6rg
>
> --=20
> Joerg Thoennes
>                                http://macd.com
> Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
> Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting =20
> language
> that extends applications into web and mobile media. Attend the =20
> live webcast
> and join the prime developer group breaking into this new coding =20
> territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dlnk&kid=110944&bid$1720&dat=121642=

> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] Timestamp in log entries

[Joerg T. <Joe...@ma...>]

Hi Greg,

> Unfourtunately, I am using QF in a C# application.  I see the options
> you added FileIncludeTimeStampForMessages and FileIncludeMilliseconds.
>  I'll add an equivalent of your changes to my code unless someone
> cares to make the same modifications to the primary version.

If you post patches to the native QF version, which are similiar to QF/J =
(ie configurable=20
in the same way), somebody with commit access will probably have a look a=
t them.

Thanks, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-users] SessionQualifier and MySQL

[Joerg T. <Joe...@ma...>]

Privet, Nikolay,

> We're developing acceptor application, but the specific is that we want=
 to
> provide many clients to initiate sessions simultaneously. We use QuickF=
IX
> 1.11 with MySQL storing end logging. I tried to use SessionQualifier, b=
ut it
> doesn't works in way I expected. Two initators with same BeginString,
> SenderCompID, TargetCompID and different SessionQualifier can't logon
> simultaneously.
> On acceptor side there are no record with nonempty SessionQualifier fie=
ld in
> session table.=20
> One initator logins successfully, but all other initator logs is floode=
d
> with:
> 20060321-16:41:08 : Connecting to localhost on port 5001
> 20060321-16:41:09 : Connection succeeded
> 20060321-16:41:09 : Initiated logon request
> 20060321-16:41:09 : Socket Error: Connection reset by peer.
> 20060321-16:41:09 : Disconnecting
> Have you an idea, where is my mistake?

The SessionQualifier was introduced -- if I recollect correctly -- to all=
ow QF to manage=20
several sessions with same SenderCompID and TargetCompID, _but_ different=
 accept ports.

Before that a QF session was uniquely identified by (BeginString, SenderC=
ompID, TargetCompID).

The important point in your case is that the SessionQualifier is _not_ tr=
ansmitted over=20
the wire, ie if both of your initiator clients has a different SessionQua=
lifier=20
configured, but connect to the _same_ port with identical (BeginString, S=
enderCompID,=20
TargetCompID), QF will forward these requests to the _same_ session, whic=
h results in the=20
disconnects (since the session is already logged on).

Please try with different ports for each different qualifier.

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

Re: [Quickfix-users] Timestamp in log entries

[Greg C. <gc...@po...>]

Hi Steve,

Unfourtunately, I am using QF in a C# application.  I see the options
you added FileIncludeTimeStampForMessages and FileIncludeMilliseconds.
 I'll add an equivalent of your changes to my code unless someone
cares to make the same modifications to the primary version.

Thanks,
Greg

On 3/20/06, Steve Bate <sb...@sm...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/i=
ndex.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi Greg,
>
> I'm not sure which version/language of QuickFIX you are
> using, but I committed a modification to QuickFIX/J's
> FileLogFactory to support optional milliseconds in time
> stamps. See the doc/usermanual/usage/configuration.html
> file in the CVS HEAD for details about how to configure
> the options.
>
> Regards,
>
> Steve Bate
>
>
> > -----Original Message-----
> > From: qui...@li...
> > [mailto:qui...@li...] On Behalf
> > Of Greg Chase
> > Sent: Monday, March 20, 2006 11:13 AM
> > To: qui...@li...
> > Subject: [Quickfix-users] Timestamp in log entries
> >
> > QuickFIX Documentation:
> > http://www.quickfixengine.org/quickfix/doc/html/index.html
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > Is there a builtin way to prepend local timestamps (with ms
> > precision) on log file entries?  I've been able to avoid
> > modifying the QF source so far...
> >
> > Many thanks,
> > Greg
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by xPML, a groundbreaking
> > scripting language that extends applications into web and
> > mobile media. Attend the live webcast and join the prime
> > developer group breaking into this new coding territory!
> > http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> > _______________________________________________
> > Quickfix-users mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-users
> >
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting langua=
ge
> that extends applications into web and mobile media. Attend the live webc=
ast
> and join the prime developer group breaking into this new coding territor=
y!
> http://sel.as-us.falkag.net/sel?cmdlnk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>

Re: [Quickfix-users] BusinessMessage Reject

[Oren M. <or...@qu...>]

Did you implement the onMessage method in you cracker which accepts a 
FIX.4.2 ExecutionReport.

--oren

John Haldi wrote:

> I'm pretty sure that this is a stupid user error (or build error), but 
> I'm left scratching my head wondering what's happening.  Here's the 
> log output from the run:
>
> <20060321-20:25:23, FIX.4.2:ALLAGASHRPT->REDI, incoming>
>
> (8=FIX.4.2=2865=89=REDI6=ALLAGASHRPT28=SILK4=1780=gc3112282=20060321-20:26:587=LLG000031=35709=615132156=LOC7=750810021080060=050=19=1=615132155=AA4=18=15000=19=07=A2=4501=29.1200000=N9=151=4504=1050=29.12000=20060321-15:26:5813=N39=SPN0=160)
>
> fromApp event: GetType = QuickFix42.ExecutionReport
>
> fromApp event fired...
>
> toApp event: GetType = QuickFix42.BusinessMessageReject
>
> <20060321-20:25:23, FIX.4.2:ALLAGASHRPT->REDI, outgoing>
>
> (8=FIX.4.2=1065=j4=419=ALLAGASHRPT2=20060321-20:25:23.7816=REDI5=1788=Unsupported 
> Message Type72=880=30=034)
>
> <20060321-20:25:23, FIX.4.2:ALLAGASHRPT->REDI, event>
>
> (Message 178 Rejected: Unsupported Message Type)
>
> A first chance exception of type 'QuickFix.UnsupportedMessageType' 
> occurred in quickfix_net_messages.dll
>
> A first chance exception of type 
> 'System.Runtime.InteropServices.SEHException' occurred in quickfix_net.dll
>
> My code is very straightforward:
>  
>
> Public Sub fromApp(ByVal message As QuickFix.Message, ByVal sessionID 
> As QuickFix.SessionID) Implements QuickFix.Application.fromApp
>
> Console.WriteLine("fromApp event: GetType = " & message.GetType.FullName)
>
> Console.WriteLine("fromApp event fired... ")
>
> crack(message, sessionID)
>
> End Sub
>
>  
>
> I have code in place to handle an execution report, but it never gets 
> to the code.  In the debugger the code is never reached, and instead 
> the quickfix engine throws this exception.  Best I can tell the 
> Execution Report I'm getting is properly formed.
>
> Any suggestions for this newbie?
>
> Thank you,
>
>    John Haldi
>
>  
>  
> --------------------------------------
> John Haldi
> Allagash Trading, LLC
> 120 Broadway, 20th Floor
> New York, NY 10271
> 212.433.3958
> jo...@al...
>  

[Quickfix-users] BusinessMessage Reject

[John H. <JH...@al...>]

I'm pretty sure that this is a stupid user error (or build error), but
I'm left scratching my head wondering what's happening.  Here's the log
output from the run:

<20060321-20:25:23, FIX.4.2:ALLAGASHRPT->REDI, incoming>

(8=3DFIX.4.2=19=3D286=135=3D8=149=3DREDI=156=3DALLAGASHRPT=1128=3DSILK=13=
4=3D178=150=3Dgc311228=152=3D2006
0321-20:26:58=137=3DLLG00003=111=3D357=1109=3D61513215=176=3DLOC=117=3D75=
081002108006=120=3D0=1150
=3D1=139=3D1=11=3D61513215=155=3DAA=154=3D1=138=3D1500=140=3D1=159=3D0=14=
7=3DA=132=3D450=131=3D29.120000=130=3DN=129=3D1=115
1=3D450=114=3D1050=16=3D29.1200=160=3D20060321-15:26:58=1113=3DN=1439=3DS=
PN=110=3D160)

fromApp event: GetType =3D QuickFix42.ExecutionReport

fromApp event fired...=20

toApp event: GetType =3D QuickFix42.BusinessMessageReject

<20060321-20:25:23, FIX.4.2:ALLAGASHRPT->REDI, outgoing>

(8=3DFIX.4.2=19=3D106=135=3Dj=134=3D41=149=3DALLAGASHRPT=152=3D20060321-2=
0:25:23.781=156=3DREDI=145=3D
178=158=3DUnsupported Message Type=1372=3D8=1380=3D3=110=3D034)

<20060321-20:25:23, FIX.4.2:ALLAGASHRPT->REDI, event>

(Message 178 Rejected: Unsupported Message Type)

A first chance exception of type 'QuickFix.UnsupportedMessageType'
occurred in quickfix_net_messages.dll

A first chance exception of type
'System.Runtime.InteropServices.SEHException' occurred in
quickfix_net.dll

My code is very straightforward:
=20
Public Sub fromApp(ByVal message As QuickFix.Message, ByVal sessionID As
QuickFix.SessionID) Implements QuickFix.Application.fromApp

Console.WriteLine("fromApp event: GetType =3D " &
message.GetType.FullName)

Console.WriteLine("fromApp event fired... ")

crack(message, sessionID)

End Sub

=20

I have code in place to handle an execution report, but it never gets to
the code.  In the debugger the code is never reached, and instead the
quickfix engine throws this exception.  Best I can tell the Execution
Report I'm getting is properly formed.

Any suggestions for this newbie?

Thank you,

   John Haldi

=20
=20
--------------------------------------
John Haldi
Allagash Trading, LLC
120 Broadway, 20th Floor
New York, NY 10271
212.433.3958
jo...@al...
=20

[Quickfix-users] SessionQualifier and MySQL

[Nikolay P. <ko...@xl...>]

We're developing acceptor application, but the specific is that we want to
provide many clients to initiate sessions simultaneously. We use QuickFIX
1.11 with MySQL storing end logging. I tried to use SessionQualifier, but it
doesn't works in way I expected. Two initators with same BeginString,
SenderCompID, TargetCompID and different SessionQualifier can't logon
simultaneously.
On acceptor side there are no record with nonempty SessionQualifier field in
session table. 
One initator logins successfully, but all other initator logs is flooded
with:
20060321-16:41:08 : Connecting to localhost on port 5001
20060321-16:41:09 : Connection succeeded
20060321-16:41:09 : Initiated logon request
20060321-16:41:09 : Socket Error: Connection reset by peer.
20060321-16:41:09 : Disconnecting
Have you an idea, where is my mistake?
--
View this message in context: http://www.nabble.com/SessionQualifier-and-MySQL-t1318780.html#a3517035
Sent from the QuickFIX - User forum at Nabble.com.

RE: [Quickfix-users] Timestamp in log entries

[Steve B. <sb...@sm...>]

Hi Greg,

I'm not sure which version/language of QuickFIX you are
using, but I committed a modification to QuickFIX/J's
FileLogFactory to support optional milliseconds in time=20
stamps. See the doc/usermanual/usage/configuration.html
file in the CVS HEAD for details about how to configure
the options.

Regards,

Steve Bate


> -----Original Message-----
> From: qui...@li...=20
> [mailto:qui...@li...] On Behalf=20
> Of Greg Chase
> Sent: Monday, March 20, 2006 11:13 AM
> To: qui...@li...
> Subject: [Quickfix-users] Timestamp in log entries
>=20
> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> Is there a builtin way to prepend local timestamps (with ms=20
> precision) on log file entries?  I've been able to avoid=20
> modifying the QF source so far...
>=20
> Many thanks,
> Greg
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking=20
> scripting language that extends applications into web and=20
> mobile media. Attend the live webcast and join the prime=20
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=3Dk&kid=110944&bid$1720&dat=121642
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>=20

Re: [Quickfix-users] Timestamp in log entries

[Joerg T. <Joe...@ma...>]

Greg Chase wrote:
> Is there a builtin way to prepend local timestamps (with ms precision)
> on log file entries?  I've been able to avoid modifying the QF source
> so far...

How about creating your own class implementing the LogFactory interface? =
Just take the=20
FileLogFactory as a template. Then add it in the constructor of the appro=
priate initiator=20
and acceptor.

E.g. for log4j and java:

public class JavaLogFactory
     implements LogFactory
{
     private final static Logger logger =3D new Logger( "JavaLogFactory" =
);

     public Log create( final SessionID sessionID ) {

         return new FixLog( sessionID );
     }

     private class FixLog
         implements Log {

         final SessionID sessionID;
         final String onIncomingString;
         final String onOutgoingString;
         final String onEventString;

         public FixLog( final SessionID sessionID ) {
             this.sessionID =3D sessionID;
             this.onIncomingString =3D sessionID + ": incoming: ";
             this.onOutgoingString =3D sessionID + ": outgoing: ";
             this.onEventString    =3D sessionID + ": event   : ";
         }

         public void onIncoming( final String string ) {
             logger.logDebug( onIncomingString + string );
         }

         public void onOutgoing( final String string ) {
             logger.logDebug( onOutgoingString + string );
         }

         public void onEvent( final String string ) {
             logger.logInfo( onEventString + string );
         }
     }
}

Cheers, J=F6rg

--=20
Joerg Thoennes
                                http://macd.com
Tel.: +49 (0)241 44597-24      Macdonald Associates GmbH
Fax : +49 (0)241 44597-10      Lothringer Str. 52, D-52070 Aachen

[Quickfix-users] Timestamp in log entries

[Greg C. <gc...@po...>]

Is there a builtin way to prepend local timestamps (with ms precision)
on log file entries?  I've been able to avoid modifying the QF source
so far...

Many thanks,
Greg

[Quickfix-users] QuickFIX 1.11.1 is now available

[Oren M. <or...@qu...>]

QuickFIX 1.11.1 is now available at http://www.quickfixengine.org

You can get the release notes for all versions here: 
http://www.quickfixengine.org/NEWS

This is a small release that fixes some bugs and adds some small 
functionality.  Most of the bug fixes were related to the database and 
the build.  If you are doing anything with logging or the database, you 
will probably want this release.

FPL MEMBERSHIP
---------------------
We are now members of the FPL.  Specifically I am on the Global 
Technical Committee, Global Derivatives Committee, Repository Working 
Group, and the Web Services Working Group.  I will be representing 
quickfixengine.org.

Re: [Quickfix-users] Schema definitions for the datadictionaries?

[Oren M. <or...@qu...>]

Yes, these were in fact derived from parsing the .html and .doc files.  
This was somewhat error prone so the conversion wasn't perfect.  We 
mostly correct mistakes as they are reported.  This was all done well 
before such a thing as the fix repository existed.

We will be switching to using the repository to generate our 
dictionaries.  There currently is no schema for our dictionary format.

--oren

Erik van Zijst wrote:

> QuickFIX Documentation: 
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> The page at http://www.quickfixengine.org/xml.html shows the xml data 
> dictionaries that were derived from the fix specification.
>
> I noticed that, in contrast to the official fixprotocol fixml schemas, 
> your files do include all repeating group count tags (e.g. 
> NoUnderlyings - 711). Where is this information coming from? Where did 
> the quickfix parser got this information from? It didn't harvest the 
> .doc or .pdf files, now did it?
>
> Additionally I'd like to know if there is an xmlschema definition for 
> these data dictionary files. I can't find it online.
>
> cheers,
> Erik
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting 
> language
> that extends applications into web and mobile media. Attend the live 
> webcast
> and join the prime developer group breaking into this new coding 
> territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Quickfix-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-users
>
>

[Quickfix-users] Schema definitions for the datadictionaries?

[Erik v. Z. <er...@er...>]

Hi,

The page at http://www.quickfixengine.org/xml.html shows the xml data 
dictionaries that were derived from the fix specification.

I noticed that, in contrast to the official fixprotocol fixml schemas, 
your files do include all repeating group count tags (e.g. NoUnderlyings 
- 711). Where is this information coming from? Where did the quickfix 
parser got this information from? It didn't harvest the .doc or .pdf 
files, now did it?

Additionally I'd like to know if there is an xmlschema definition for 
these data dictionary files. I can't find it online.

cheers,
Erik

RE: [Quickfix-users] Session resync problem

[Ajay K. <Aja...@tr...>]

Coalescing multiple overlapping resend requests into a single resend
should definitely help in Sean's case where there were only 125 messages
to resend.=20

However, note that with a single thread serving all FIX sessions there
is still the possibility of a massive resend request on one FIX session
starving the other FIX sessions. I have seen some cases in production in
which a catastrophic sequence number problem on one side of a FIX
connection result in a resend request for thousands of messages. If the
FIX engine on the other end servicing that massive resend request does
so in a tight loop, it will still take just one misbehaving counter
party to affect the other FIX sessions. Obviously this kind of a problem
doesn't occur very often, and would also not be a serious problem for
installations with moderate to light volume of FIX messages.

Regards,

- Ajay

-----Original Message-----
From: Oren Miller [mailto:or...@qu...]=20
Sent: Tuesday, March 07, 2006 9:05 PM
To: Sean Kirkpatrick
Cc: Ajay Kamdar; qui...@li...
Subject: Re: [Quickfix-users] Session resync problem


Although Ajay's analysis is correct, and under other circumstances=20
moving to a threaded model might be appropriate, it is actually a red=20
herring in this case.  I know you guys are running an older version of=20
the engine, and it is the resend logic in there where the fault really=20
lies.  Older versions of QuickFIX did not handle this sort of resend=20
scenario very gracefully.  The old implementation wasn't technically=20
incorrect, but it wasn't especially smart either.  Newer versions of the

engine can detect these sort of recursive resend request scenarios and=20
avoid them so you would only send 125 instead of 125! messages.

The relevant code (in newer versions) that protects against this=20
scenario is implemented with a resendRange in the session class.

--oren

Sean Kirkpatrick wrote:

> Thanks Ajay, I appreciate the response.
> =20
> We had considered that as an option, but I believe the ThreadedSocket
> classes spawn a thread per session.  Having hundreds of threads wasn't

> a desirable approach for us.  A thread pool would probably work, but I

> don't think that is implemented...perhaps I am mistaken?
> =20
> --Sean
>
>     -----Original Message-----
>     *From:* Ajay Kamdar [mailto:Aja...@tr...]
>     *Sent:* Tuesday, March 07, 2006 11:29 AM
>     *To:* Sean Kirkpatrick; qui...@li...
>     *Subject:* RE: [Quickfix-users] Session resync problem
>
>     You might want to consider using the
>     ThreadedSocketAcceptor/ThreadedSocketInitiator classes that will
>     place each Session on its own thread, which I expect should
>     prevent the other sessions getting starved while the engine is
>     busy servicing the resend requests in a tight loop. Obviously your
>     application would need to be thread safe to go this route. Caveat
>     emptor: Not having actually used these classes myself yet, this
>     suggestion is based upon theoritical analysis. YMMV.
>     =20
>     - Ajay
>
>         -----Original Message-----
>         *From:* Sean Kirkpatrick
>         [mailto:sea...@pi...]
>         *Sent:* Tuesday, March 07, 2006 9:05 AM
>         *To:* qui...@li...
>         *Subject:* [Quickfix-users] Session resync problem
>
>         Hello All,
>
>         We had an issue in our production environment that boiled down
>         to the following:
>
>         1. Client has hard disconnect
>         2. We send some messages prior to detecting the session is
down
>         3. Client logs back in with higher than expected seq num and
>         immediately starts sending some messages
>         4. We send resend reqs for each message we receive until they
>         are handled, which the client does by
>             sending us seq reset messages.
>         5. The client heartbeats.
>         6. At this point, we do some message resending.
>         -- this is where the trouble began --
>         7. Since the client did not sync its seq nums after the logon,
>         when we start sending these messages they
>             have higher than expected seq nums.
>         8. Client sends a resend request for each of the messages we
>         sent (125).
>
>         When processing the resend requests, the engine sits in a
>         tight loop processing its queue.  The trouble
>         here is that the resend requests took approx. 5 minutes to get
>         through and all other connections were
>         starved.
>
>         Has anyone come across this problem, or have a suggestion for
>         dealing with it gracefully?
>
>         Regards,
>
>         Sean Kirkpatrick
>

_________________________________________________________________________=
__

The information in this email is confidential and may be legally =
privileged. It is intended solely for the addressee. Access to this =
email by anyone else is unauthorized. If you are not the intended =
recipient, any disclosure, copying, distribution or any action taken or =
omitted to be taken in reliance on it, is prohibited and may be =
unlawful.
_________________________________________________________________________=
__

Re: [Quickfix-users] Session resync problem

[Oren M. <or...@qu...>]

Although Ajay's analysis is correct, and under other circumstances 
moving to a threaded model might be appropriate, it is actually a red 
herring in this case.  I know you guys are running an older version of 
the engine, and it is the resend logic in there where the fault really 
lies.  Older versions of QuickFIX did not handle this sort of resend 
scenario very gracefully.  The old implementation wasn't technically 
incorrect, but it wasn't especially smart either.  Newer versions of the 
engine can detect these sort of recursive resend request scenarios and 
avoid them so you would only send 125 instead of 125! messages.

The relevant code (in newer versions) that protects against this 
scenario is implemented with a resendRange in the session class.

--oren

Sean Kirkpatrick wrote:

> Thanks Ajay, I appreciate the response.
>  
> We had considered that as an option, but I believe the ThreadedSocket 
> classes spawn a thread per session.  Having hundreds of threads wasn't 
> a desirable approach for us.  A thread pool would probably work, but I 
> don't think that is implemented...perhaps I am mistaken?
>  
> --Sean
>
>     -----Original Message-----
>     *From:* Ajay Kamdar [mailto:Aja...@tr...]
>     *Sent:* Tuesday, March 07, 2006 11:29 AM
>     *To:* Sean Kirkpatrick; qui...@li...
>     *Subject:* RE: [Quickfix-users] Session resync problem
>
>     You might want to consider using the
>     ThreadedSocketAcceptor/ThreadedSocketInitiator classes that will
>     place each Session on its own thread, which I expect should
>     prevent the other sessions getting starved while the engine is
>     busy servicing the resend requests in a tight loop. Obviously your
>     application would need to be thread safe to go this route. Caveat
>     emptor: Not having actually used these classes myself yet, this
>     suggestion is based upon theoritical analysis. YMMV.
>      
>     - Ajay
>
>         -----Original Message-----
>         *From:* Sean Kirkpatrick
>         [mailto:sea...@pi...]
>         *Sent:* Tuesday, March 07, 2006 9:05 AM
>         *To:* qui...@li...
>         *Subject:* [Quickfix-users] Session resync problem
>
>         Hello All,
>
>         We had an issue in our production environment that boiled down
>         to the following:
>
>         1. Client has hard disconnect
>         2. We send some messages prior to detecting the session is down
>         3. Client logs back in with higher than expected seq num and
>         immediately starts sending some messages
>         4. We send resend reqs for each message we receive until they
>         are handled, which the client does by
>             sending us seq reset messages.
>         5. The client heartbeats.
>         6. At this point, we do some message resending.
>         -- this is where the trouble began --
>         7. Since the client did not sync its seq nums after the logon,
>         when we start sending these messages they
>             have higher than expected seq nums.
>         8. Client sends a resend request for each of the messages we
>         sent (125).
>
>         When processing the resend requests, the engine sits in a
>         tight loop processing its queue.  The trouble
>         here is that the resend requests took approx. 5 minutes to get
>         through and all other connections were
>         starved.
>
>         Has anyone come across this problem, or have a suggestion for
>         dealing with it gracefully?
>
>         Regards,
>
>         Sean Kirkpatrick
>

RE: [Quickfix-users] Session resync problem

[Sean K. <sea...@pi...>]

Thanks Ajay, I appreciate the response.
=20
We had considered that as an option, but I believe the ThreadedSocket =
classes spawn a thread per session.  Having hundreds of threads wasn't a =
desirable approach for us.  A thread pool would probably work, but I =
don't think that is implemented...perhaps I am mistaken?
=20
--Sean

-----Original Message-----
From: Ajay Kamdar [mailto:Aja...@tr...]
Sent: Tuesday, March 07, 2006 11:29 AM
To: Sean Kirkpatrick; qui...@li...
Subject: RE: [Quickfix-users] Session resync problem


You might want to consider using the =
ThreadedSocketAcceptor/ThreadedSocketInitiator classes that will place =
each Session on its own thread, which I expect should prevent the other =
sessions getting starved while the engine is busy servicing the resend =
requests in a tight loop. Obviously your application would need to be =
thread safe to go this route. Caveat emptor: Not having actually used =
these classes myself yet, this suggestion is based upon theoritical =
analysis. YMMV.
=20
- Ajay

-----Original Message-----
From: Sean Kirkpatrick [mailto:sea...@pi...]=20
Sent: Tuesday, March 07, 2006 9:05 AM
To: qui...@li...
Subject: [Quickfix-users] Session resync problem



Hello All,=20

We had an issue in our production environment that boiled down to the =
following:=20

1. Client has hard disconnect=20
2. We send some messages prior to detecting the session is down=20
3. Client logs back in with higher than expected seq num and immediately =
starts sending some messages=20
4. We send resend reqs for each message we receive until they are =
handled, which the client does by=20
    sending us seq reset messages.=20
5. The client heartbeats.=20
6. At this point, we do some message resending.=20
-- this is where the trouble began --=20
7. Since the client did not sync its seq nums after the logon, when we =
start sending these messages they=20
    have higher than expected seq nums.=20
8. Client sends a resend request for each of the messages we sent (125). =


When processing the resend requests, the engine sits in a tight loop =
processing its queue.  The trouble=20
here is that the resend requests took approx. 5 minutes to get through =
and all other connections were=20
starved.=20

Has anyone come across this problem, or have a suggestion for dealing =
with it gracefully?=20

Regards,=20

Sean Kirkpatrick=20

RE: [Quickfix-users] Session resync problem

[Ajay K. <Aja...@tr...>]

You might want to consider using the
ThreadedSocketAcceptor/ThreadedSocketInitiator classes that will place
each Session on its own thread, which I expect should prevent the other
sessions getting starved while the engine is busy servicing the resend
requests in a tight loop. Obviously your application would need to be
thread safe to go this route. Caveat emptor: Not having actually used
these classes myself yet, this suggestion is based upon theoritical
analysis. YMMV.
=20
- Ajay

	-----Original Message-----
	From: Sean Kirkpatrick
[mailto:sea...@pi...]=20
	Sent: Tuesday, March 07, 2006 9:05 AM
	To: qui...@li...
	Subject: [Quickfix-users] Session resync problem
=09
=09

	Hello All,=20

	We had an issue in our production environment that boiled down
to the following:=20

	1. Client has hard disconnect=20
	2. We send some messages prior to detecting the session is down=20
	3. Client logs back in with higher than expected seq num and
immediately starts sending some messages=20
	4. We send resend reqs for each message we receive until they
are handled, which the client does by=20
	    sending us seq reset messages.=20
	5. The client heartbeats.=20
	6. At this point, we do some message resending.=20
	-- this is where the trouble began --=20
	7. Since the client did not sync its seq nums after the logon,
when we start sending these messages they=20
	    have higher than expected seq nums.=20
	8. Client sends a resend request for each of the messages we
sent (125).=20

	When processing the resend requests, the engine sits in a tight
loop processing its queue.  The trouble=20
	here is that the resend requests took approx. 5 minutes to get
through and all other connections were=20
	starved.=20

	Has anyone come across this problem, or have a suggestion for
dealing with it gracefully?=20

	Regards,=20

	Sean Kirkpatrick=20

[Quickfix-users] Session resync problem

[Sean K. <sea...@pi...>]

Hello All,

We had an issue in our production environment that boiled down to the =
following:

1. Client has hard disconnect
2. We send some messages prior to detecting the session is down
3. Client logs back in with higher than expected seq num and immediately =
starts sending some messages
4. We send resend reqs for each message we receive until they are =
handled, which the client does by
    sending us seq reset messages.
5. The client heartbeats.
6. At this point, we do some message resending.
-- this is where the trouble began --
7. Since the client did not sync its seq nums after the logon, when we =
start sending these messages they
    have higher than expected seq nums.
8. Client sends a resend request for each of the messages we sent (125).

When processing the resend requests, the engine sits in a tight loop =
processing its queue.  The trouble
here is that the resend requests took approx. 5 minutes to get through =
and all other connections were
starved.

Has anyone come across this problem, or have a suggestion for dealing =
with it gracefully?

Regards,

Sean Kirkpatrick