quickfix-developers — QuickFIX developers forum

[Quickfix-developers] Session qualifier?

[Steve B. <st...@te...>]

Hello,

I am curious about why QF uses session qualifiers as part of
the session identification rather than using subID and location.

I'm looking into implementing third-party message routing in
QFJ and this looks like the session qualifier technique might be 
a problem.

Steve

[Quickfix-developers] QuickFIX 1.10.2 is now available

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

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

A couple of point releases went out before I had a chance to announce  
1.10.0.  You can get the release notes for all versions here: http:// 
www.quickfixengine.org/NEWS

Well now.  It's been a bit longer between releases then normal, but  
here it is.  Not everything we wanted to get in here did, but we will  
be pushing for a 2.0 release and hope to incorporate some of our more  
ambitious goals.

Some of the things you will find in this version is automated support  
for SequenceResets.  If your engine receives one, it will reset your  
sequence numbers and send the appropriate ack.  If you attach a  
ResetSeqNumFlag=Y to your logon message, the engine will reset its  
sequence numbers appropriately.  This flag will also automatically  
attach itself at the appropriate time if you have ResetOnDisconnect  
or ResetOnLogoff set.

You can now reliably stop and start initiators and acceptors as much  
as you like.  Previously once you stopped in initiator or acceptor,  
it wasn't designed to be brought back up and you'd have to throw it  
away.  Now you can call start/stop as much as you like.  Even better,  
the initiator/acceptor will attempt to properly logout of all  
sessions before shutting down.  It will only forcibly take down a  
session if it doesn't respond withing 5 seconds to the logout attempt.

Some things with field validation.  You can turn them off for user  
defined fields with the ValidateUserDefinedFields configuration  
setting.  Also the validation algorithm will now check for required  
fields in the header, trailer, and repeating groups instead of just  
the main message body.

The much wanted method to getSessions from an initiator/acceptor is  
now available in all APIs.

And you can check the release notes for all the details.  Did we miss  
something?  Please enter it into the bugtracker (http:// 
www.quickfixengine.org/bugtracker/).  That's the best way to ensure  
that we don't miss it.  The mailing list has grown a bit much to be  
used as a way to reliably track such things (the developer list alone  
had 190 posts last month).  After reporting something to the list, if  
the discussion reveals a need for action, please help us out by  
entering it into the bugtracker and attaching any relevant log files.

--oren

[Quickfix-developers] Expected/Received Length seems wrong in error message

[Rich H. <rh...@ql...>]

Does this code look right?  I am receiving invalid messages from a FIX 
engine (unrelated issue).
However, when looking at the code, it seems that this error message is 
backwards.  Should
aBodyLength (actual?) be the expected length and bodyLength() be the 
received length?

It looks like the checksum is incorrect too...

Cheers,
Rich


void Message::validate()
{ QF_STACK_PUSH(Message::validate)

  try
  {
    BodyLength aBodyLength;
    m_header.getField( aBodyLength );
    if ( aBodyLength != bodyLength() )
    {
      std::stringstream text;
      text << "Expected BodyLength=" << bodyLength()
           << ", Recieved BodyLength=" << (int)aBodyLength;
      throw InvalidMessage(text.str());
    }  

    CheckSum aCheckSum;
    m_trailer.getField( aCheckSum );
    if ( aCheckSum != checkSum() )
    {
      std::stringstream text;
      text << "Expected CheckSum=" << checkSum()
           << ", Recieved CheckSum=" << (int)aCheckSum;
      throw InvalidMessage(text.str());
    }
  }
  catch ( FieldNotFound& )
  {
    throw InvalidMessage("BodyLength or CheckSum missing");
  }

  QF_STACK_POP
}

Re: [Quickfix-developers] Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1

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

Hold off on that patch.  I found a bug in it.  I'm preparing another.

--oren

On Jun 30, 2005, at 12:07 PM, Alexey Zubko wrote:

> Oren,
>
> It looks like due to the specification the server acts correctly.
> So, QF initiator should not reset sequence numbers on logon =20
> confirmation I think.
>
> Here are the logs:
>
> QF initiator:
> 8=3DFIX.4.2.9=3D88.35=3DA.34=3D1.49=3DF.52=3D20050630-13:05:01.022.56=3D=
CURRENEX-=20
> FXTRADES-FIX.98=3D0.108=3D30.141=3DY.10=3D154.
> 8=3DFIX.4.2.9=3D139.35=3DV.34=3D1.49=3DF.52=3D20050630-13:05:01.304.56=3D=
CURRENEX-=20
> FXTRADES-FIX.146=3D1.55=3DAUD/USD.262=3DICMD0.263=3D1.264=3D1.265=3D1.26=
6=3DY.=20
> 267=3D2.269=3D0.269=3D1.10=3D233.
> 8=3DFIX.4.2.9=3D139.35=3DV.34=3D2.49=3DF.52=3D20050630-13:05:01.304.56=3D=
CURRENEX-=20
> FXTRADES-FIX.146=3D1.55=3DEUR/USD.262=3DICMD1.263=3D1.264=3D1.265=3D1.26=
6=3DY.=20
> 267=3D2.269=3D0.269=3D1.10=3D253.
>
>
> The server:
> 8=3DFIX.4.2.9=3D84.35=3DA.49=3DCURRENEX-FXTRADES-FIX.56=3DF.=20
> 34=3D1.52=3D20050630-13:05:01.108=3D30.141=3DY.98=3D0.10=3D212.
> 8=3DFIX.4.2.9=3D78.35=3Dh.49=3DCURRENEX-FXTRADES-FIX.56=3DF.=20
> 34=3D2.52=3D20050630-13:05:01.336=3D0.340=3D2.10=3D202.
> 8=3DFIX.4.2.9=3D133.35=3D5.49=3DCURRENEX-FXTRADES-FIX.56=3DF.=20
> 34=3D3.52=3D20050630-13:05:01.58=3DMsgSeqNum too low, expecting 2 but =20=

> received 1 MarketDataRequest.10=3D045.
>
>
>
> Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000 =20
> ext. 305
>
> Oren Miller wrote:
>> Well, here is what the spec says on the subject:
>>
>> "When using the ResetSeqNumFlag to maintain 24 hour connectivity =20
>> and  establish a new set of sequence numbers, the process should =20
>> be as  follows.  Both sides should agree on a reset time and the =20
>> party that  will be the initiator of the process.  Note that the =20
>> initiator of the  ResetSeqNum process may be different than the =20
>> initiator of the Logon  process. One side will initiate the =20
>> process by sending a TestRequest  and wait for a Heartbeat in =20
>> response to ensure of no sequence number  gaps.  Once the =20
>> Heartbeat has been received, the initiator should  send a Logon =20
>> with ResetSeqNumFlag set to Y and with MsgSeqNum of 1.   The =20
>> acceptor should respond with a Logon with ResetSeqNumFlag set to  =20
>> Y and with MsgSeqNum of 1.  At this point new messages from =20
>> either  side should continue with MsgSeqNum of 2.  It should be =20
>> noted that  once the initiator sends the Logon with the =20
>> ResetSeqNumFlag set, the  acceptor must obey this request and the =20
>> message with the last  sequence number transmitted =93yesterday=94 =
may =20
>> no longer be available.   The connection should be shutdown and =20
>> manual intervention taken if  this process is initiated but not =20
>> followed properly."
>>
>> So it would seem to me that when they send a Logon with the  =20
>> ResetSeqNumFlag set, the first thing QF should do is send a Logon  =20=

>> message with a MsgSeqNum of 1, followed by your message with a  =20
>> sequence number of 2.  Is this message going out?  If not then =20
>> that  could be a problem.  I don't think we have a test case for =20
>> an  initiator processing a ResetSeqNumFlag, so I can imagine this  =20=

>> scenario might not be handled correctly.
>>
>> --oren
>>
>> On Jun 30, 2005, at 9:04 AM, Alexey Zubko wrote:
>>
>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/=20
>>> doc/ html/indexhtml.
>>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php? =20
>>> QuickFixFAQ
>>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>> Hi,
>>>
>>> I've got a new sequencing problem and I want to know who is =20
>>> right  in this situation.
>>>
>>> In the CVS version QF reset sequence number if ResetSeqNumFlag =20
>>> is  present in logon message.
>>>
>>> So I fail in the following scenario:
>>> My QF initiator connects to a third-part server (Currenex) with =20
>>> the  flag and receives logon
>>> message with sequence number 1 and with this flag too. QF =20
>>> (Session  class) resets sequence number,
>>> and the next message I send has sequence number 1. So, the =20
>>> server  sends me logout -
>>> "MsgSeqNum too low, expecting 2 but received 1".
>>>
>>> Who is right? Should QF reset sequence number on logon =20
>>> confirmation  or the server shouldn't
>>> send the flag, or QF reset is correct?
>>>
>>> Thank you in advance.
>>>
>>> --=20
>>>
>>> Regards,
>>>         Alexey Zubko
>>>
>>> Infinium Capital Corporation
>>> (416) 360-7000 ext. 305
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> SF.Net email is sponsored by: Discover Easy Linux Migration =20
>>> Strategies
>>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>>> informative Webcasts and more! Get everything you need to get up to
>>> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dc=
lick
>>> _______________________________________________
>>> Quickfix-developers mailing list
>>> Qui...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>>
>>
>>

[Quickfix-developers] Re: Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1

[Francis G. <fr...@at...>]

I am having the same problem with another server.  QuickFix assigns a
sequence number of 1 to the second message after a ResetSeqNumFlag reset.

Initiator outgoing log:
8=FIX.4.2
9=87
35=A
34=1
49=FIXUSER2
52=20050630-15:46:05.625
56=PRICES
96=F
IXPASS2
98=0
108=15
141=Y
10=080

-->Result: the acceptor logs "Expecting sequence number 2 after receiving
reset from client" but it does not drop the connection.

8=FIX.4.2
9=69
35=c
34=1
49=FIXUSER2
52=20050630-15:46:06.921
56=PRICES
320=
0
321=3
10=054

-->Result: disconnected.   Th acceptor logs "Receive message with sequence
number too low without PossDupFlag = Yes.  Disconnecting"

Francis Gingras

RE: [Quickfix-developers] Java Exception reveals the problem with TAG 52

[Steve B. <st...@te...>]

Hi,

Yes, I found the bug in the SessionFactory object. I've added a unit
test for the problem and fixed it. The factory was defaulting to an
initiator if the connection type was unspecified. The change should=20
be available in the anonymous CVS repository soon (if it's not=20
already there).

Thanks for reporting this.=20

Steve

> -----Original Message-----
> From: qui...@li... =
[mailto:quickfix-
> dev...@li...] On Behalf Of VP Marketing IT =
Asset
> Enterprise Technologies
> Sent: Thursday, June 30, 2005 8:40 AM
> To: Steve Bate
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] Java Exception reveals the problem =
with
> TAG 52
>=20
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: =
http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> The config file for QF-J appears to be not the standard QF settings =
file.
>=20
> Here is an example:
> [DEFAULT]
> ConnectionType=3Dinitiator
> HeartBtInt=3D30
> FileStorePath=3Dstore
> StartTime=3D00:00:00
> EndTime=3D00:00:00
> UseDataDictionary=3DN
> SocketConnectHost=3D0.0.0.0
> SocketConnectPort=3D7379
> ReconnectInterval=3D1
>=20
> [SESSION]
> BeginString=3DFIX.4.2
> SenderCompID=3DCTEST
> TargetCompID=3DTTEST
>=20
> ---------
> The java app. fails complaining about
>=20
> quickfix.ConfigError: no initiators in settings
>         at
> =
quickfix.netty.AbstractSocketInitiator.initialize(AbstractSocketInitiator=
.
> java:178)
>         at
> =
quickfix.netty.AbstractSocketInitiator.start(AbstractSocketInitiator.java=
:
> 117)
>         at FixGwy.<init>(Unknown Source)
>         at FixGwy.main(Unknown Source)
>=20
> ----
>=20
> If I remove
>=20
> ConnectionType=3Dinitiator
>=20
> the stack works fine.
>=20
> FYI
> --
> Raman
>=20
> IMHO: the same settings file should work. We should strive for that.
> Except for loading the jni nothing else should be different.
>=20
>=20
> I have one class QuickfixLoader
> --------
> public class QuickfixLoader {
> static Object guard =3D new Object();
> static boolean loaded =3D false;
> static public boolean isLoaded() { return loaded ; }
>      static {
>         synchronized (guard)
>             {
>                 // boolean loaded =3D false;
>                 if (!loaded) {
>                     loaded =3D true;
>                     try {System.loadLibrary("quickfix_jni");}
>                     catch(UnsatisfiedLinkError e) {
>                         loaded =3D false;
>                         System.out.println("Could not load
> quickfix_jni library" +
>                                            e.toString());
>                     }
>                     if ( loaded )
>                         {
>                             System.out.println("Loaded library
> quickfix_jni");
>                         }
>                 } // if !loaded
>             } // synchronized
>      } // static
> } // class
> ------------------
> and one line in my application...
>  //static { QuickfixLoader loader =3D new QuickfixLoader() ;}
> ------------------
> Uncomment this line and build to create C++ based app.
> Comment this line and build to create Pure Java based app.
>=20
>=20
> On 6/28/05, VP Marketing IT Asset Enterprise Technologies
> <ass...@gm...> wrote:
> > 52=3D20050628-18:27:49
> >
> > The solution however was simple...changed datadictionary=3DY to N
> > and it worked fine after that.
> >
> >
> > On 6/28/05, Steve Bate <st...@te...> wrote:
> > > QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> > > QuickFIX FAQ:
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> > > QuickFIX Support: http://www.quickfixengine.org/services.html
> > >
> > > > Here is what I see happening
> > > > F (my company) sends a 35=3DA to C the client
> > > > Client sends 35=3DA
> > > > QF does not like tag 52...do not know why yet...
> > > > and it tries to reject that message before login occurs
> > > > so an exception is thrown and then we know the rest...
> > > >
> > > > I guess the same thing happened yesterday with Quickfix.
> > > >
> > > > This is with QuickfixJ.
> > >
> > > Ah, a good compatibility test. ;-)
> > >
> > > What is the value of tag 52 in the logon response (assuming
> > > the tag exists)?
> > >
> > > Steve
> > >
> > > > Oren, now I am going to do the cvs up command see if the updates
> help
> > > > me nudge along.
> > > > ( I am guessing the CVS up is shorthand for CVS update...I am
> severely
> > > > handicapped with  C++,  CVS and windows)
> > > > I hope am not being taken for high maintenance user
> > > > --
> > > > RK
> > > >
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> > > > (8=3DFIX.4.29=3D7135=3DA34=3D149=3DFTEST52=3D20050628-
> > > > 18:28:04.33156=3DCTEST98=3D0108=3D3010=3D197)
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated =
logon
> request)
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> > > > (8=3DFIX.4.29=3D7135=3DA34=3D149=3DFTEST52=3D20050628-
> > > > 18:28:04.33156=3DCTEST98=3D0108=3D3010=3D197)
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, incoming>
> > > > =
(8=3DFIX.4.29=3D8735=3DA49=3DCTEST56=3DFTEST34=3D0000198=3D052=3D20050628=
-
> > > > 18:27:49108=3D60141=3DN383=3D5600010=3D203)
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (error while
> receiving
> > > > message
> > > > quickfix.SessionException: Tried to send a reject while not =
logged
> on:
> > > > Tag specified out of required order (field 52)
> > > >         at quickfix.Session.generateReject(Session.java:753)
> > > >         at quickfix.Session.next(Session.java:508)
> > > >         at
> > > >
> =
quickfix.netty.AbstractSocketInitiator.processMessage(AbstractSocketIniti=
a
> > > > tor.java:210)
> > > >         at
> quickfix.SocketInitiator.onMessage(SocketInitiator.java:94)
> > > >         at
> > > >
> =
quickfix.netty.AbstractSocketInitiator$SessionConnection$NettySessionList=
e
> > > > ner.messageReceived(AbstractSocketInitiator.java:380)
> > > >         at
> > > > =
net.gleamynode.netty2.Session.fireMessageReceived(Session.java:733)
> > > >         at
> > > >
> =
net.gleamynode.netty2.LowLatencyEventDispatcher.flush(LowLatencyEventDisp=
a
> > > > tcher.java:67)
> > > >         at
> > > >
> =
net.gleamynode.netty2.ReadController.processEvent(ReadController.java:360=
)
> > > >         at
> net.gleamynode.netty2.IoProcessor.process(IoProcessor.java:334)
> > > >         at
> > > > =
net.gleamynode.netty2.IoProcessor.access$500(IoProcessor.java:73)
> > > >         at
> > > > =
net.gleamynode.netty2.IoProcessor$Worker.run(IoProcessor.java:364)
> > > > )
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Dropped
> Connection)
> > > > FIX.4.2:FTEST->CTEST is LOGGED OUT <20050628-18:28:04,
> > > > FIX.4.2:FTEST->CTEST, outgoing>
> > > > (8=3DFIX.4.29=3D7135=3DA34=3D249=3DFTEST52=3D20050628-
> > > > 18:28:04.63356=3DCTEST98=3D0108=3D3010=3D203)
> > > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated =
logon
> request)
> > > >
> > > > On 6/28/05, VP Marketing IT Asset Enterprise Technologies
> > > > <ass...@gm...> wrote:
> > > > > I switched to an executor in the LAN and it worked fine. You =
are
> correct
> > > > > the trouble earlier was with the settings file...
> > > > >
> > > > > The file is there. But there is only one session and that is =
with
> an
> > > > external
> > > > > party and it could be failing for a number of reasons.
> > > > >
> > > > > The error (console) output did not indicate that. It =
misdirects to
> an
> > > > > initiator not
> > > > > being there.
> > > > >
> > > > > We can talk about how to structure a generic Error control and
> > > > communication
> > > > > exception hierarchy.
> > > > >
> > > > > Consider the following three classes:
> > > > >
> > > > > class QuickfixJErrorList
> > > > > {
> > > > > final String error_string[] =3D
> > > > > {
> > > > > "ILLEGAL ARGUMENT/INTERNAL ERROR",
> > > > > "CONFIG FILE NOT READABLE",
> > > > > "CONFIG NOT ACCORDING TO SPECIFICATION", // somethign simpler =
may
> be
> > > > > "SESSION COULD NOT BE INITIALIZED",
> > > > >
> > > > > };
> > > > > final int base_error=3D1300;
> > > > > final int error_no[] =3D {1300,1301,1302, 1303} ; // this =
coudl be
> > > > > base_error, base_error+1, etc
> > > > >
> > > > > static public String getErrorMessage(int code) {
> > > > > return
> > > >
> =
error_string[(code>base_error&&(code<(base_error+error_no.length)))?code:=
0
> > > > );
> > > > > }
> > > > > static public String getErrorMessage(String code){
> > > > > try {
> > > > > return getErrorMessage(Integer.parseInt(code.trim()));
> > > > > } catch(Exception e) { }
> > > > > return getErrorMessage(0);
> > > > > }
> > > > > }
> > > > > class QuickfixException extends Exception
> > > > > {
> > > > > QuickfixException (String msgCode)
> > > > > {
> > > > > super(QuickfixJErrorList.getErrorMessage(msg);
> > > > > }
> > > > > }
> > > > >
> > > > > And we can implement the JErrorList in XML and load the DOM
> > > > > or put it on HSQLDB or some such thing and manage it from
> anywhere.
> > > > > instead of being static class...
> > > > >
> > > > > I am hacking as I am writing this email.. the idea may be
> clearer...
> > > > > I can do this..if you send me a specification what you want.
> > > > > --
> > > > > rk
> > > > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is sponsored by: Discover Easy Linux Migration =
Strategies
> > > from IBM. Find simple to follow Roadmaps, straightforward =
articles,
> > > informative Webcasts and more! Get everything you need to get up =
to
> > > speed, fast. =
http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclick
> > > _______________________________________________
> > > Quickfix-developers mailing list
> > > Qui...@li...
> > > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > >
> >
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1

[Alexey Z. <ale...@in...>]

Oren,

It looks like due to the specification the server acts correctly.
So, QF initiator should not reset sequence numbers on logon confirmation 
I think.

Here are the logs:

QF initiator:
8=FIX.4.2.9=88.35=A.34=1.49=F.52=20050630-13:05:01.022.56=CURRENEX-FXTRADES-FIX.98=0.108=30.141=Y.10=154.
8=FIX.4.2.9=139.35=V.34=1.49=F.52=20050630-13:05:01.304.56=CURRENEX-FXTRADES-FIX.146=1.55=AUD/USD.262=ICMD0.263=1.264=1.265=1.266=Y.267=2.269=0.269=1.10=233.
8=FIX.4.2.9=139.35=V.34=2.49=F.52=20050630-13:05:01.304.56=CURRENEX-FXTRADES-FIX.146=1.55=EUR/USD.262=ICMD1.263=1.264=1.265=1.266=Y.267=2.269=0.269=1.10=253.


The server:
8=FIX.4.2.9=84.35=A.49=CURRENEX-FXTRADES-FIX.56=F.34=1.52=20050630-13:05:01.108=30.141=Y.98=0.10=212.
8=FIX.4.2.9=78.35=h.49=CURRENEX-FXTRADES-FIX.56=F.34=2.52=20050630-13:05:01.336=0.340=2.10=202.
8=FIX.4.2.9=133.35=5.49=CURRENEX-FXTRADES-FIX.56=F.34=3.52=20050630-13:05:01.58=MsgSeqNum 
too low, expecting 2 but received 1 MarketDataRequest.10=045.



Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Oren Miller wrote:

> Well, here is what the spec says on the subject:
>
> "When using the ResetSeqNumFlag to maintain 24 hour connectivity and  
> establish a new set of sequence numbers, the process should be as  
> follows.  Both sides should agree on a reset time and the party that  
> will be the initiator of the process.  Note that the initiator of the  
> ResetSeqNum process may be different than the initiator of the Logon  
> process. One side will initiate the process by sending a TestRequest  
> and wait for a Heartbeat in response to ensure of no sequence number  
> gaps.  Once the Heartbeat has been received, the initiator should  
> send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1.   
> The acceptor should respond with a Logon with ResetSeqNumFlag set to  
> Y and with MsgSeqNum of 1.  At this point new messages from either  
> side should continue with MsgSeqNum of 2.  It should be noted that  
> once the initiator sends the Logon with the ResetSeqNumFlag set, the  
> acceptor must obey this request and the message with the last  
> sequence number transmitted “yesterday” may no longer be available.   
> The connection should be shutdown and manual intervention taken if  
> this process is initiated but not followed properly."
>
> So it would seem to me that when they send a Logon with the  
> ResetSeqNumFlag set, the first thing QF should do is send a Logon  
> message with a MsgSeqNum of 1, followed by your message with a  
> sequence number of 2.  Is this message going out?  If not then that  
> could be a problem.  I don't think we have a test case for an  
> initiator processing a ResetSeqNumFlag, so I can imagine this  
> scenario might not be handled correctly.
>
> --oren
>
> On Jun 30, 2005, at 9:04 AM, Alexey Zubko wrote:
>
>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/ 
>> html/index.html
>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php? 
>> QuickFixFAQ
>> QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>> Hi,
>>
>> I've got a new sequencing problem and I want to know who is right  in 
>> this situation.
>>
>> In the CVS version QF reset sequence number if ResetSeqNumFlag is  
>> present in logon message.
>>
>> So I fail in the following scenario:
>> My QF initiator connects to a third-part server (Currenex) with the  
>> flag and receives logon
>> message with sequence number 1 and with this flag too. QF (Session  
>> class) resets sequence number,
>> and the next message I send has sequence number 1. So, the server  
>> sends me logout -
>> "MsgSeqNum too low, expecting 2 but received 1".
>>
>> Who is right? Should QF reset sequence number on logon confirmation  
>> or the server shouldn't
>> send the flag, or QF reset is correct?
>>
>> Thank you in advance.
>>
>> -- 
>>
>> Regards,
>>         Alexey Zubko
>>
>> Infinium Capital Corporation
>> (416) 360-7000 ext. 305
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Quickfix-developers mailing list
>> Qui...@li...
>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>
>
>

Re: [Quickfix-developers] Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1

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

Well, here is what the spec says on the subject:

"When using the ResetSeqNumFlag to maintain 24 hour connectivity and =20
establish a new set of sequence numbers, the process should be as =20
follows.  Both sides should agree on a reset time and the party that =20
will be the initiator of the process.  Note that the initiator of the =20=

ResetSeqNum process may be different than the initiator of the Logon =20
process. One side will initiate the process by sending a TestRequest =20
and wait for a Heartbeat in response to ensure of no sequence number =20
gaps.  Once the Heartbeat has been received, the initiator should =20
send a Logon with ResetSeqNumFlag set to Y and with MsgSeqNum of 1.  =20
The acceptor should respond with a Logon with ResetSeqNumFlag set to =20
Y and with MsgSeqNum of 1.  At this point new messages from either =20
side should continue with MsgSeqNum of 2.  It should be noted that =20
once the initiator sends the Logon with the ResetSeqNumFlag set, the =20
acceptor must obey this request and the message with the last =20
sequence number transmitted =93yesterday=94 may no longer be available.  =
=20
The connection should be shutdown and manual intervention taken if =20
this process is initiated but not followed properly."

So it would seem to me that when they send a Logon with the =20
ResetSeqNumFlag set, the first thing QF should do is send a Logon =20
message with a MsgSeqNum of 1, followed by your message with a =20
sequence number of 2.  Is this message going out?  If not then that =20
could be a problem.  I don't think we have a test case for an =20
initiator processing a ResetSeqNumFlag, so I can imagine this =20
scenario might not be handled correctly.

--oren

On Jun 30, 2005, at 9:04 AM, Alexey Zubko wrote:

> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/=20
> html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?=20
> QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> Hi,
>
> I've got a new sequencing problem and I want to know who is right =20
> in this situation.
>
> In the CVS version QF reset sequence number if ResetSeqNumFlag is =20
> present in logon message.
>
> So I fail in the following scenario:
> My QF initiator connects to a third-part server (Currenex) with the =20=

> flag and receives logon
> message with sequence number 1 and with this flag too. QF (Session =20
> class) resets sequence number,
> and the next message I send has sequence number 1. So, the server =20
> sends me logout -
> "MsgSeqNum too low, expecting 2 but received 1".
>
> Who is right? Should QF reset sequence number on logon confirmation =20=

> or the server shouldn't
> send the flag, or QF reset is correct?
>
> Thank you in advance.
>
> --=20
>
> Regards,
>         Alexey Zubko
>
> Infinium Capital Corporation
> (416) 360-7000 ext. 305
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcli=
ck
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>
>

[Quickfix-developers] Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1

[Alexey Z. <ale...@in...>]

Hi,

I've got a new sequencing problem and I want to know who is right in 
this situation.

In the CVS version QF reset sequence number if ResetSeqNumFlag is 
present in logon message.

So I fail in the following scenario:
My QF initiator connects to a third-part server (Currenex) with the flag 
and receives logon
message with sequence number 1 and with this flag too. QF (Session 
class) resets sequence number,
and the next message I send has sequence number 1. So, the server sends 
me logout -
"MsgSeqNum too low, expecting 2 but received 1".

Who is right? Should QF reset sequence number on logon confirmation or 
the server shouldn't
send the flag, or QF reset is correct?

Thank you in advance.

-- 

Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305

Re: [Quickfix-developers] Java Exception reveals the problem with TAG 52

[VP M. IT A. E. T. <ass...@gm...>]

The config file for QF-J appears to be not the standard QF settings file.

Here is an example:
[DEFAULT]
ConnectionType=3Dinitiator
HeartBtInt=3D30
FileStorePath=3Dstore
StartTime=3D00:00:00
EndTime=3D00:00:00
UseDataDictionary=3DN
SocketConnectHost=3D0.0.0.0
SocketConnectPort=3D7379
ReconnectInterval=3D1

[SESSION]
BeginString=3DFIX.4.2
SenderCompID=3DCTEST
TargetCompID=3DTTEST

---------
The java app. fails complaining about=20

quickfix.ConfigError: no initiators in settings
        at quickfix.netty.AbstractSocketInitiator.initialize(AbstractSocket=
Initiator.java:178)
        at quickfix.netty.AbstractSocketInitiator.start(AbstractSocketIniti=
ator.java:117)
        at FixGwy.<init>(Unknown Source)
        at FixGwy.main(Unknown Source)

----

If I remove=20

ConnectionType=3Dinitiator

the stack works fine.

FYI
--
Raman

IMHO: the same settings file should work. We should strive for that.
Except for loading the jni nothing else should be different.


I have one class QuickfixLoader
--------
public class QuickfixLoader {
static Object guard =3D new Object();
static boolean loaded =3D false;
static public boolean isLoaded() { return loaded ; }
     static {
        synchronized (guard)=20
            {
                // boolean loaded =3D false;
                if (!loaded) {
                    loaded =3D true;
                    try {System.loadLibrary("quickfix_jni");}=20
                    catch(UnsatisfiedLinkError e) {
                        loaded =3D false;
                        System.out.println("Could not load
quickfix_jni library" +
                                           e.toString());
                    }
                    if ( loaded )=20
                        {
                            System.out.println("Loaded library quickfix_jni=
");
                        }
                } // if !loaded
            } // synchronized=20
     } // static=20
} // class=20
------------------
and one line in my application...
 //static { QuickfixLoader loader =3D new QuickfixLoader() ;}
------------------
Uncomment this line and build to create C++ based app.
Comment this line and build to create Pure Java based app.


On 6/28/05, VP Marketing IT Asset Enterprise Technologies
<ass...@gm...> wrote:
> 52=3D20050628-18:27:49
>=20
> The solution however was simple...changed datadictionary=3DY to N
> and it worked fine after that.
>=20
>=20
> On 6/28/05, Steve Bate <st...@te...> wrote:
> > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html=
/index.html
> > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixF=
AQ
> > QuickFIX Support: http://www.quickfixengine.org/services.html
> >
> > > Here is what I see happening
> > > F (my company) sends a 35=3DA to C the client
> > > Client sends 35=3DA
> > > QF does not like tag 52...do not know why yet...
> > > and it tries to reject that message before login occurs
> > > so an exception is thrown and then we know the rest...
> > >
> > > I guess the same thing happened yesterday with Quickfix.
> > >
> > > This is with QuickfixJ.
> >
> > Ah, a good compatibility test. ;-)
> >
> > What is the value of tag 52 in the logon response (assuming
> > the tag exists)?
> >
> > Steve
> >
> > > Oren, now I am going to do the cvs up command see if the updates help
> > > me nudge along.
> > > ( I am guessing the CVS up is shorthand for CVS update...I am severel=
y
> > > handicapped with  C++,  CVS and windows)
> > > I hope am not being taken for high maintenance user
> > > --
> > > RK
> > >
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> > > (8=3DFIX.4.29=3D7135=3DA34=3D149=3DFTEST52=3D20050628-
> > > 18:28:04.33156=3DCTEST98=3D0108=3D3010=3D197)
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated logon req=
uest)
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> > > (8=3DFIX.4.29=3D7135=3DA34=3D149=3DFTEST52=3D20050628-
> > > 18:28:04.33156=3DCTEST98=3D0108=3D3010=3D197)
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, incoming>
> > > (8=3DFIX.4.29=3D8735=3DA49=3DCTEST56=3DFTEST34=3D0000198=3D052=3D2005=
0628-
> > > 18:27:49108=3D60141=3DN383=3D5600010=3D203)
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (error while receivi=
ng
> > > message
> > > quickfix.SessionException: Tried to send a reject while not logged on=
:
> > > Tag specified out of required order (field 52)
> > >         at quickfix.Session.generateReject(Session.java:753)
> > >         at quickfix.Session.next(Session.java:508)
> > >         at
> > > quickfix.netty.AbstractSocketInitiator.processMessage(AbstractSocketI=
nitia
> > > tor.java:210)
> > >         at quickfix.SocketInitiator.onMessage(SocketInitiator.java:94=
)
> > >         at
> > > quickfix.netty.AbstractSocketInitiator$SessionConnection$NettySession=
Liste
> > > ner.messageReceived(AbstractSocketInitiator.java:380)
> > >         at
> > > net.gleamynode.netty2.Session.fireMessageReceived(Session.java:733)
> > >         at
> > > net.gleamynode.netty2.LowLatencyEventDispatcher.flush(LowLatencyEvent=
Dispa
> > > tcher.java:67)
> > >         at
> > > net.gleamynode.netty2.ReadController.processEvent(ReadController.java=
:360)
> > >         at net.gleamynode.netty2.IoProcessor.process(IoProcessor.java=
:334)
> > >         at
> > > net.gleamynode.netty2.IoProcessor.access$500(IoProcessor.java:73)
> > >         at
> > > net.gleamynode.netty2.IoProcessor$Worker.run(IoProcessor.java:364)
> > > )
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Dropped Connection)
> > > FIX.4.2:FTEST->CTEST is LOGGED OUT <20050628-18:28:04,
> > > FIX.4.2:FTEST->CTEST, outgoing>
> > > (8=3DFIX.4.29=3D7135=3DA34=3D249=3DFTEST52=3D20050628-
> > > 18:28:04.63356=3DCTEST98=3D0108=3D3010=3D203)
> > > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated logon req=
uest)
> > >
> > > On 6/28/05, VP Marketing IT Asset Enterprise Technologies
> > > <ass...@gm...> wrote:
> > > > I switched to an executor in the LAN and it worked fine. You are co=
rrect
> > > > the trouble earlier was with the settings file...
> > > >
> > > > The file is there. But there is only one session and that is with a=
n
> > > external
> > > > party and it could be failing for a number of reasons.
> > > >
> > > > The error (console) output did not indicate that. It misdirects to =
an
> > > > initiator not
> > > > being there.
> > > >
> > > > We can talk about how to structure a generic Error control and
> > > communication
> > > > exception hierarchy.
> > > >
> > > > Consider the following three classes:
> > > >
> > > > class QuickfixJErrorList
> > > > {
> > > > final String error_string[] =3D
> > > > {
> > > > "ILLEGAL ARGUMENT/INTERNAL ERROR",
> > > > "CONFIG FILE NOT READABLE",
> > > > "CONFIG NOT ACCORDING TO SPECIFICATION", // somethign simpler may b=
e
> > > > "SESSION COULD NOT BE INITIALIZED",
> > > >
> > > > };
> > > > final int base_error=3D1300;
> > > > final int error_no[] =3D {1300,1301,1302, 1303} ; // this coudl be
> > > > base_error, base_error+1, etc
> > > >
> > > > static public String getErrorMessage(int code) {
> > > > return
> > > error_string[(code>base_error&&(code<(base_error+error_no.length)))?c=
ode:0
> > > );
> > > > }
> > > > static public String getErrorMessage(String code){
> > > > try {
> > > > return getErrorMessage(Integer.parseInt(code.trim()));
> > > > } catch(Exception e) { }
> > > > return getErrorMessage(0);
> > > > }
> > > > }
> > > > class QuickfixException extends Exception
> > > > {
> > > > QuickfixException (String msgCode)
> > > > {
> > > > super(QuickfixJErrorList.getErrorMessage(msg);
> > > > }
> > > > }
> > > >
> > > > And we can implement the JErrorList in XML and load the DOM
> > > > or put it on HSQLDB or some such thing and manage it from anywhere.
> > > > instead of being static class...
> > > >
> > > > I am hacking as I am writing this email.. the idea may be clearer..=
.
> > > > I can do this..if you send me a specification what you want.
> > > > --
> > > > rk
> > > >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> > from IBM. Find simple to follow Roadmaps, straightforward articles,
> > informative Webcasts and more! Get everything you need to get up to
> > speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dcl=
ick
> > _______________________________________________
> > Quickfix-developers mailing list
> > Qui...@li...
> > https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> >
>

[Quickfix-developers] Re: even after configure --with-java --enable-callstack does not

[VP M. IT A. E. T. <ass...@gm...>]

Hi Oren

Version 1.9.4 (not the update from CVS) does not fix the problem I was havi=
ng.
The java version seems to fix it. Out of curiosity I put the 1.9.4
version back in
and ran the system with the same counterparty and same settings files.

Aborted. Logon Message was rejected first and the system aborted
attempting to  send reject message to the cp without a valid session.

I will try to get everything from CVS and try to test it out by COB today.
Has there been any update on CVS since yesterday.

Thanks=20

On 6/28/05, VP Marketing IT Asset Enterprise Technologies
<ass...@gm...> wrote:
> Thanks very much. I will do that and let you know.
>=20
> On 6/28/05, Oren Miller <or...@qu...> wrote:
> > This was fixed last night.  Run 'cvs up' to get the fix.
> >
> > --oren
> >
> > On Jun 27, 2005, at 8:16 PM, VP Marketing IT Asset Enterprise
> > Technologies wrote:
> >
> > > make[4]: *** No rule to make target
> > > `../../lib/libquickfix_jni.jnilib', needed by `all-am'.  Stop.
> > > make[4]: Leaving directory `/home/rkannan/FIX/dist/qf.cvs/quickfix/
> > > src/java'
> > > make[3]: *** [all-recursive] Error 1
> > > make[3]: Leaving directory `/home/rkannan/FIX/dist/qf.cvs/quickfix/
> > > src/java'
> > > make[2]: *** [all-recursive] Error 1
> > > make[2]: Leaving directory `/home/rkannan/FIX/dist/qf.cvs/quickfix/
> > > src'
> > > make[1]: *** [all-recursive] Error 1
> > > make[1]: Leaving directory `/home/rkannan/FIX/dist/qf.cvs/quickfix'
> > > make: *** [all] Error 2
> > >
> > >
> > > produce quickfix_jni...
> > > what is the proc. to build for java with jni?
> > >
> > > On 6/27/05, VP Marketing IT Asset Enterprise Technologies
> > > <ass...@gm...> wrote:
> > >
> > >> done make at the top level
> > >> and build in java.
> > >> Everything builds without any error.
> > >> What about the quickfix_jni?
> > >> Please drop a line if this is done by different command.
> > >>
> > >> --
> > >> RK
> > >>
> > >>
> > >> On 6/27/05, VP Marketing IT Asset Enterprise Technologies
> > >> <ass...@gm...> wrote:
> > >>
> > >>> am building now...
> > >>> Thanks
> > >>> On 6/27/05, Oren Miller <or...@qu...> wrote:
> > >>>
> > >>>> You should run the bootstrap script instead of manually running
> > >>>> autoconf.
> > >>>>
> > >>>> --oren
> > >>>>
> > >>>> On Jun 27, 2005, at 6:29 PM, VP Marketing IT Asset Enterprise
> > >>>> Technologies wrote:
> > >>>>
> > >>>>
> > >>>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/
> > >>>>> doc/
> > >>>>> html/index.html
> > >>>>> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?
> > >>>>> QuickFixFAQ
> > >>>>> QuickFIX Support: http://www.quickfixengine.org/services.html
> > >>>>>
> > >>>>> I pulled down the QF src from CVS using the help instructions.
> > >>>>>
> > >>>>> I am trying to build the src at this point on linux.
> > >>>>>
> > >>>>> I run autoconf and I get the following errors
> > >>>>> configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE
> > >>>>>       If this token and others are legitimate, please use
> > >>>>> m4_pattern_allow.
> > >>>>>       See the Autoconf documentation.
> > >>>>> configure.in:5: error: possibly undefined macro: AM_CONFIG_HEADER
> > >>>>> configure.in:6: error: possibly undefined macro: AM_DISABLE_STATI=
C
> > >>>>> configure.in:12: error: possibly undefined macro:
> > >>>>> AC_DISABLE_STATIC
> > >>>>> configure.in:13: error: possibly undefined macro:
> > >>>>> AC_LIBTOOL_WIN32_DLL
> > >>>>> configure.in:14: error: possibly undefined macro: AM_PROG_LIBTOOL
> > >>>>> configure.in:15: error: possibly undefined macro: AM_PROG_LEX
> > >>>>> configure.in:83: error: possibly undefined macro: AM_CONDITIONAL
> > >>>>> configure.in:139: error: possibly undefined macro: AM_PATH_XML2
> > >>>>> I tried configure (little khaky at this point)
> > >>>>> /configure: line 1277: syntax error near unexpected token
> > >>>>> `quickfix,'.
> > >>>>> /configure: line 1277: `AM_INIT_AUTOMAKE(quickfix, 1.10.0)'.
> > >>>>>
> > >>>>> Are these normal ..
> > >>>>> One line response would do..
> > >>>>> --
> > >>>>> RK
> > >>>>>
> > >>>>> On 6/27/05, VP Marketing IT Asset Enterprise Technologies
> > >>>>> <ass...@gm...> wrote:
> > >>>>>
> > >>>>>
> > >>>>>> Hi
> > >>>>>>
> > >>>>>> I am running a Java quickfix application on linux.
> > >>>>>>
> > >>>>>> Due to sequence number mismatch the counterparty
> > >>>>>> rejects the logon (35=3DA) msg.
> > >>>>>>
> > >>>>>> <20050627-16:25:41, FIX.4.2:FEST->CTEST, incoming>
> > >>>>>>  (8=3DFIX.
> > >>>>>> 4.2^A9=3D121^A35=3D3^A49=3DCTEST^A56=3DFTEST^A34=3D00026^A43=3DN=
^A52=3D20050627
> > >>>>>> -16:
> > >>>>>> 25:27^A97=3DN^A45=3D009^A58=3DIncoming
> > >>>>>> MsgSeqNum is 9 whi\
> > >>>>>> le expected 11^A10=3D251^A)
> > >>>>>> <20050627-16:25:41, FIX.4.2:FTEST->CTEST, event>
> > >>>>>>  (Logon state is not valid for message)
> > >>>>>> <20050627-16:25:41, FIX.4.2:FTEST->CTEST, event>
> > >>>>>>  (Dropped Connection)
> > >>>>>> FIX.4.2:FTEST->CTEST is LOGGED OUT <20050627-16:25:41,
> > >>>>>> FIX.4.2:FTEST->CTEST, event>
> > >>>>>>  (Initiated logon request)
> > >>>>>> FIX.4.2:FTEST->CTEST is LOGGED OUT <20050627-16:25:42,
> > >>>>>> FIX.4.2:FTEST->CTEST, event>
> > >>>>>>  (Connecting to 199.53.16.226 on port 5545)
> > >>>>>> <20050627-16:25:42, FIX.4.2:FTEST->CTEST, event>
> > >>>>>>  (Connection succeeded)
> > >>>>>> <20050627-16:25:42, FIX.4.2:FTEST->CTEST, outgoing>
> > >>>>>>  (8=3DFIX.
> > >>>>>> 4.2^A9=3D72^A35=3DA^A34=3D11^A49=3DFTEST^A52=3D20050627-16:25:42=
.065^A56=3DCT
> > >>>>>> EST^
> > >>>>>> A98=3D0^A108=3D30^A10=3D247^A)
> > >>>>>> <20050627-16:25:42, FIX.4.2:FTEST->CTEST, event>
> > >>>>>>  (Initiated logon request)
> > >>>>>> <20050627-16:25:42, FIX.4.2:FTEST->CTEST, incoming>
> > >>>>>>  (8=3DFIX.
> > >>>>>> 4.2^A9=3D87^A35=3DA^A49=3DCTEST^A56=3DFTEST^A34=3D00027^A98=3D0^=
A52=3D20050627-
> > >>>>>> 16:2
> > >>>>>> 5:28^A108=3D60^A141=3DN^A383=3D56000^A10=3D203^A)
> > >>>>>> Aborted
> > >>>>>>
> > >>>>>> It cannot be the static link item from FAQ.
> > >>>>>>
> > >>>>>> Scanned for duplicate tags cannot find any...
> > >>>>>>
> > >>>>>> Any hint? thank you
> > >>>>>> --
> > >>>>>> Raman
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>>
> > >>>>> -------------------------------------------------------
> > >>>>> SF.Net email is sponsored by: Discover Easy Linux Migration
> > >>>>> Strategies
> > >>>>> from IBM. Find simple to follow Roadmaps, straightforward
> > >>>>> articles,
> > >>>>> informative Webcasts and more! Get everything you need to get
> > >>>>> up to
> > >>>>> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&op=3Dcl=
ick
> > >>>>> _______________________________________________
> > >>>>> Quickfix-developers mailing list
> > >>>>> Qui...@li...
> > >>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>
> > >>
> > >
> > >
> >
> >
>

Re: [Quickfix-developers] MsgSeqNum too high problem

[Alexey Z. <ale...@in...>]

Oren,

I didn't send resend messages manually.

One of a Globex (CME) certification step is not to send resend request 
for more than 2500 messages.
QF sets endSeqNo field to 0 (or 99999) in the generateResendRequest and 
the only way I found is
to comment out those code and set the field to 0 in my toAdmin callback.
I set it to 0 because the initiator was written for FIX4.2 and I didn't 
expected to use it for the other versions.

The problem occurred because I used the initiator for version FIX4.0 and 
absolutely forgot about this patch.
Now I set the field to 99999 for version <FIX4.2 and it solved the problem.

It may say that the resend messages were corrupted, but QF's reaction 
wasn't correct anyway.
I think versions checks need to be eliminated int the nextResendRequest 
function:

  if (endSeqNo == 0 ||
       endSeqNo == 999999 ||
       endSeqNo >= getExpectedSenderNum() )
  { endSeqNo = getExpectedSenderNum() - 1; }


Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Oren Miller wrote:

> Were you manually sending ResendRequest messages?
>
> --oren
>
> On Jun 28, 2005, at 4:15 PM, Alexey Zubko wrote:
>
>> HI,
>>
>> I found the problem.
>> Acceptor didn't resend messages because my endSeqNo field is 0 but  
>> my beginString is FIX4.0.
>> So, in the nextResendRequest function QF tried to get messages from  
>> say 15 to 0.
>> It's my mistake that I put 0 in my initiator instead of 999999, of  
>> course,
>> but may be we need to change the code anyway?
>>
>>
>> void Session::nextResendRequest( const Message& resendRequest )
>> .......
>> .   std::string beginString = m_sessionID.getBeginString();
>>   if ( beginString >= FIX::BeginString_FIX42 && endSeqNo == 0 ||
>>        beginString <= FIX::BeginString_FIX42 && endSeqNo == 999999 ||
>>        endSeqNo >= getExpectedSenderNum() )
>>   { endSeqNo = getExpectedSenderNum() - 1; }
>>
>>   std::vector < std::string > messages;
>>   m_state.get( beginSeqNo, endSeqNo, messages );
>> .........
>> .
>>
>>
>> Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000  
>> ext. 305
>>
>> Oren Miller wrote:
>>
>>> Any idea on why the acceptor is not responding to the  
>>> ResendRequest?   Those acceptance tests are passing.  Do you have  
>>> the incoming/ outgoing log files for both processes?
>>>
>>> --oren
>>>
>>> On Jun 28, 2005, at 2:49 PM, Alexey Zubko wrote:
>>>
>>>> Hello Brian,
>>>>
>>>> Your fix prevents the disconnecting, but I still have a  
>>>> sequencing  problem.
>>>>
>>>> Actually I thing there are two problems -
>>>> 1. Acceptor sends nothing back.
>>>> 2. Initiator ignores incoming application messages.
>>>>
>>>> I've got the problem during debugging - terminating initiator's   
>>>> process, but it's easy to reproduce:
>>>> If to increase NextSenderMsgSeqNum number in acceptor's file,  
>>>> after  restart the initiator sends resend requests, the acceptor  
>>>> sends  nothing back and ignores all incoming application messages  
>>>> (there  is no fromApp() call).
>>>> Both acceptor and initiator are QF (CVS version + your patch).
>>>>
>>>>
>>>> Initiator:
>>>>
>>>> 20050628-19:38:55 : Created session
>>>> 20050628-19:38:55 : Connecting to eng-server on port 57258
>>>> 20050628-19:38:55 : Connection succeeded
>>>> 20050628-19:38:56 : Initiated logon request
>>>> 20050628-19:38:59 : Received logon response
>>>> 20050628-19:40:50 : Created session
>>>> 20050628-19:40:50 : Connecting to eng-server on port 57258
>>>> 20050628-19:40:50 : Connection succeeded
>>>> 20050628-19:40:51 : Initiated logon request
>>>> 20050628-19:40:51 : Received logon response
>>>> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 7
>>>> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 6
>>>> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 8
>>>> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 7
>>>> 20050628-19:41:06 : MsgSeqNum too high, expecting  5 but received 9
>>>> 20050628-19:41:06 : Sent ResendRequest FROM: 5 TO: 8
>>>> ........
>>>> .
>>>> Acceptor:
>>>>
>>>> 20050628-19:38:48 : Created session
>>>> 20050628-19:38:56 : Received logon request
>>>> 20050628-19:38:56 : Responding to logon request
>>>> 20050628-19:39:41 : Socket Error
>>>> 20050628-19:39:41 : Disconnecting
>>>> 20050628-19:40:42 : Created session
>>>> 20050628-19:40:51 : Received logon request
>>>> 20050628-19:40:51 : Responding to logon request
>>>> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
>>>> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
>>>> 20050628-19:41:06 : Received ResendRequest FROM: 5 TO: 0
>>>> 20050628-19:41:21 : Received ResendRequest FROM: 5 TO: 0
>>>> 20050628-19:41:36 : Received ResendRequest FROM: 5 TO: 0
>>>> 20050628-19:41:51 : Socket Error
>>>> 20050628-19:41:51 : Disconnecting
>>>>
>>>>
>>>> Regards, Alexey Zubko Infinium Capital Corporation (416)  360-7000  
>>>> ext. 305
>>>>
>>>> Brian Erst wrote:
>>>>
>>>>> Oren - I believe the following change to Session.cpp will fix  
>>>>> the  timeout problem when receiving out-of-sequence messages  
>>>>> while  awaiting a sequence reset/gap-fill: Move the following  
>>>>> lines in  Session::verify(...) UtcTimeStamp now;  
>>>>> m_state.lastReceivedTime ( now ); from their current position up  
>>>>> to a spot just before the  preceding if/else clause: -->>Place  
>>>>> the code here<<-- if  ( checkTooHigh && isTargetTooHigh ( 
>>>>> msgSeqNum ) )  This will  increment the "lastReceivedTime" in  the 
>>>>> SessionState object even  when the sequence number is wrong.  This 
>>>>> appears to solve a whole  bunch of interrelated timeouts  that 
>>>>> could occur in this scenario  (test request, heartbeat,  logon 
>>>>> response, etc.) in one quick hit.  Sequence too low is  largely 
>>>>> unaffected by this change, as it will  cause a  disconnect when 
>>>>> hit, so that part of the code shouldn't  need to  be rearranged. 
>>>>> It was somewhat unclear to me whether the   following line: 
>>>>> m_state.testRequest( 0 ); Also needed to be  moved,  but it seemed 
>>>>> like it did not. - Brian Erst Thynk  Software, Inc.  --- Oren 
>>>>> Miller <or...@qu...> wrote:
>>>>>
>>>>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/  
>>>>>> doc/html/index.html QuickFIX FAQ: http:// www.quickfixengine.org/ 
>>>>>> wikifix/index.php?QuickFixFAQ QuickFIX  Support: http:// 
>>>>>> www.quickfixengine.org/services.html Seems to  me this shouldn't  
>>>>>> be happening. I'm guessing that the engine  isn't processing the  
>>>>>> message because the sequence number is  too high, hence no  
>>>>>> heartbeat is processed. I believe that out  of sequence messages  
>>>>>> should probably count as a keep-alive  even if their contents  
>>>>>> arn't processed. --oren ----- Original  Message ----- From:  
>>>>>> "Alexey Zubko"  <ale...@in...> To: <quickfix-  
>>>>>> dev...@li...> Sent: Monday, June 27, 2005   
>>>>>> 1:44 PM Subject: [Quickfix-developers] MsgSeqNum too high problem
>>>>>>
>>>>>>> QuickFIX Documentation: http://www.quickfixengine.org/ quickfix/ 
>>>>>>> doc/html/index.html QuickFIX FAQ:
>>>>>>
>>>>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>>>>>
>>>>>>> QuickFIX Support: http://www.quickfixengine.org/services.html   
>>>>>>> Hi, I'd like to ask if QF initiator acts correctly in the  
>>>>>>> following
>>>>>>
>>>>>> scenario.
>>>>>>
>>>>>>> The initiator detects that seqnum of a server is too high and  
>>>>>>> sends
>>>>>>
>>>>>> a
>>>>>>
>>>>>>> resend message. The server doesn't resend requested messages,   
>>>>>>> but there are
>>>>>>
>>>>>> heartbeat
>>>>>>
>>>>>>> messages. The initiator disconnects because of timeout on   
>>>>>>> heartbeat. :-) Below is the initiator's log.  20050627-17:52:50 
>>>>>>> :  Created session 20050627-17:52:51 :  Connecting to eng-server 
>>>>>>> on  port 5725 20050627-17:52:51 :  Connection succeeded  
>>>>>>> 20050627-17:52:52 : Initiated logon  request 20050627-17:53:15 
>>>>>>> :  Received logon response  20050627-17:53:15 : MsgSeqNum too 
>>>>>>> high,  expecting 13 but  received
>>>>>>
>>>>>> 15
>>>>>>
>>>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14   
>>>>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>>>>>
>>>>>> 16
>>>>>>
>>>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15   
>>>>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>>>>>
>>>>>> 17
>>>>>>
>>>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16   
>>>>>>> 20050627-17:53:22 : Sent test request TEST  20050627-17:53:22 :  
>>>>>>> MsgSeqNum too high, expecting 13 but  received
>>>>>>
>>>>>> 18
>>>>>>
>>>>>>> 20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17   
>>>>>>> 20050627-17:53:37 : MsgSeqNum too high, expecting 13 but received
>>>>>>
>>>>>> 19
>>>>>>
>>>>>>> 20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18   
>>>>>>> 20050627-17:53:40 : Timed out waiting for heartbeat   
>>>>>>> 20050627-17:53:40 : Disconnecting -- Regards, Alexey Zubko   
>>>>>>> Infinium Capital Corporation (416) 360-7000 ext. 305   
>>>>>>> -------------------------------------------------------  SF.Net  
>>>>>>> email is sponsored by: Discover Easy Linux Migration
>>>>>>
>>>>>> Strategies
>>>>>>
>>>>>>> from IBM. Find simple to follow Roadmaps, straightforward   
>>>>>>> articles, informative Webcasts and more! Get everything you  
>>>>>>> need  to get up to speed, fast.
>>>>>>
>>>>>> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>>>>
>>>>>>> _______________________________________________ Quickfix-  
>>>>>>> developers mailing list Quickfix-  
>>>>>>> dev...@li... https:// lists.sourceforge.net/ 
>>>>>>> lists/listinfo/quickfix-developers
>>>>>>
>>>>>> ------------------------------------------------------- SF.Net   
>>>>>> email is sponsored by: Discover Easy Linux Migration  Strategies  
>>>>>> from IBM. Find simple to follow Roadmaps,  straightforward  
>>>>>> articles, informative Webcasts and more! Get  everything you 
>>>>>> need  to get up to speed, fast. http:// ads.osdn.com/? 
>>>>>> ad_id=7477&alloc_id=16492&op=click   
>>>>>> _______________________________________________ Quickfix-  
>>>>>> developers mailing list Quickfix- 
>>>>>> dev...@li...  https://lists.sourceforge.net/ 
>>>>>> lists/listinfo/quickfix-developers
>>>>>
>>>
>>>
>
>

Re: [Quickfix-developers] Java Exception reveals the problem with TAG 52

[VP M. IT A. E. T. <ass...@gm...>]

52=3D20050628-18:27:49

The solution however was simple...changed datadictionary=3DY to N
and it worked fine after that.


On 6/28/05, Steve Bate <st...@te...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/i=
ndex.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> > Here is what I see happening
> > F (my company) sends a 35=3DA to C the client
> > Client sends 35=3DA
> > QF does not like tag 52...do not know why yet...
> > and it tries to reject that message before login occurs
> > so an exception is thrown and then we know the rest...
> >
> > I guess the same thing happened yesterday with Quickfix.
> >
> > This is with QuickfixJ.
>=20
> Ah, a good compatibility test. ;-)
>=20
> What is the value of tag 52 in the logon response (assuming
> the tag exists)?
>=20
> Steve
>=20
> > Oren, now I am going to do the cvs up command see if the updates help
> > me nudge along.
> > ( I am guessing the CVS up is shorthand for CVS update...I am severely
> > handicapped with  C++,  CVS and windows)
> > I hope am not being taken for high maintenance user
> > --
> > RK
> >
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> > (8=3DFIX.4.29=3D7135=3DA34=3D149=3DFTEST52=3D20050628-
> > 18:28:04.33156=3DCTEST98=3D0108=3D3010=3D197)
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated logon reque=
st)
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> > (8=3DFIX.4.29=3D7135=3DA34=3D149=3DFTEST52=3D20050628-
> > 18:28:04.33156=3DCTEST98=3D0108=3D3010=3D197)
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, incoming>
> > (8=3DFIX.4.29=3D8735=3DA49=3DCTEST56=3DFTEST34=3D0000198=3D052=3D200506=
28-
> > 18:27:49108=3D60141=3DN383=3D5600010=3D203)
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (error while receiving
> > message
> > quickfix.SessionException: Tried to send a reject while not logged on:
> > Tag specified out of required order (field 52)
> >         at quickfix.Session.generateReject(Session.java:753)
> >         at quickfix.Session.next(Session.java:508)
> >         at
> > quickfix.netty.AbstractSocketInitiator.processMessage(AbstractSocketIni=
tia
> > tor.java:210)
> >         at quickfix.SocketInitiator.onMessage(SocketInitiator.java:94)
> >         at
> > quickfix.netty.AbstractSocketInitiator$SessionConnection$NettySessionLi=
ste
> > ner.messageReceived(AbstractSocketInitiator.java:380)
> >         at
> > net.gleamynode.netty2.Session.fireMessageReceived(Session.java:733)
> >         at
> > net.gleamynode.netty2.LowLatencyEventDispatcher.flush(LowLatencyEventDi=
spa
> > tcher.java:67)
> >         at
> > net.gleamynode.netty2.ReadController.processEvent(ReadController.java:3=
60)
> >         at net.gleamynode.netty2.IoProcessor.process(IoProcessor.java:3=
34)
> >         at
> > net.gleamynode.netty2.IoProcessor.access$500(IoProcessor.java:73)
> >         at
> > net.gleamynode.netty2.IoProcessor$Worker.run(IoProcessor.java:364)
> > )
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Dropped Connection)
> > FIX.4.2:FTEST->CTEST is LOGGED OUT <20050628-18:28:04,
> > FIX.4.2:FTEST->CTEST, outgoing>
> > (8=3DFIX.4.29=3D7135=3DA34=3D249=3DFTEST52=3D20050628-
> > 18:28:04.63356=3DCTEST98=3D0108=3D3010=3D203)
> > <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated logon reque=
st)
> >
> > On 6/28/05, VP Marketing IT Asset Enterprise Technologies
> > <ass...@gm...> wrote:
> > > I switched to an executor in the LAN and it worked fine. You are corr=
ect
> > > the trouble earlier was with the settings file...
> > >
> > > The file is there. But there is only one session and that is with an
> > external
> > > party and it could be failing for a number of reasons.
> > >
> > > The error (console) output did not indicate that. It misdirects to an
> > > initiator not
> > > being there.
> > >
> > > We can talk about how to structure a generic Error control and
> > communication
> > > exception hierarchy.
> > >
> > > Consider the following three classes:
> > >
> > > class QuickfixJErrorList
> > > {
> > > final String error_string[] =3D
> > > {
> > > "ILLEGAL ARGUMENT/INTERNAL ERROR",
> > > "CONFIG FILE NOT READABLE",
> > > "CONFIG NOT ACCORDING TO SPECIFICATION", // somethign simpler may be
> > > "SESSION COULD NOT BE INITIALIZED",
> > >
> > > };
> > > final int base_error=3D1300;
> > > final int error_no[] =3D {1300,1301,1302, 1303} ; // this coudl be
> > > base_error, base_error+1, etc
> > >
> > > static public String getErrorMessage(int code) {
> > > return
> > error_string[(code>base_error&&(code<(base_error+error_no.length)))?cod=
e:0
> > );
> > > }
> > > static public String getErrorMessage(String code){
> > > try {
> > > return getErrorMessage(Integer.parseInt(code.trim()));
> > > } catch(Exception e) { }
> > > return getErrorMessage(0);
> > > }
> > > }
> > > class QuickfixException extends Exception
> > > {
> > > QuickfixException (String msgCode)
> > > {
> > > super(QuickfixJErrorList.getErrorMessage(msg);
> > > }
> > > }
> > >
> > > And we can implement the JErrorList in XML and load the DOM
> > > or put it on HSQLDB or some such thing and manage it from anywhere.
> > > instead of being static class...
> > >
> > > I am hacking as I am writing this email.. the idea may be clearer...
> > > I can do this..if you send me a specification what you want.
> > > --
> > > rk
> > >
>=20
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=3D7477&alloc_id=3D16492&op=3Dclic=
k
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] MsgSeqNum too high problem

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

Were you manually sending ResendRequest messages?

--oren

On Jun 28, 2005, at 4:15 PM, Alexey Zubko wrote:

> HI,
>
> I found the problem.
> Acceptor didn't resend messages because my endSeqNo field is 0 but  
> my beginString is FIX4.0.
> So, in the nextResendRequest function QF tried to get messages from  
> say 15 to 0.
> It's my mistake that I put 0 in my initiator instead of 999999, of  
> course,
> but may be we need to change the code anyway?
>
>
> void Session::nextResendRequest( const Message& resendRequest )
> .......
> .   std::string beginString = m_sessionID.getBeginString();
>   if ( beginString >= FIX::BeginString_FIX42 && endSeqNo == 0 ||
>        beginString <= FIX::BeginString_FIX42 && endSeqNo == 999999 ||
>        endSeqNo >= getExpectedSenderNum() )
>   { endSeqNo = getExpectedSenderNum() - 1; }
>
>   std::vector < std::string > messages;
>   m_state.get( beginSeqNo, endSeqNo, messages );
> .........
> .
>
>
> Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000  
> ext. 305
>
> Oren Miller wrote:
>> Any idea on why the acceptor is not responding to the  
>> ResendRequest?   Those acceptance tests are passing.  Do you have  
>> the incoming/ outgoing log files for both processes?
>>
>> --oren
>>
>> On Jun 28, 2005, at 2:49 PM, Alexey Zubko wrote:
>>
>>> Hello Brian,
>>>
>>> Your fix prevents the disconnecting, but I still have a  
>>> sequencing  problem.
>>>
>>> Actually I thing there are two problems -
>>> 1. Acceptor sends nothing back.
>>> 2. Initiator ignores incoming application messages.
>>>
>>> I've got the problem during debugging - terminating initiator's   
>>> process, but it's easy to reproduce:
>>> If to increase NextSenderMsgSeqNum number in acceptor's file,  
>>> after  restart the initiator sends resend requests, the acceptor  
>>> sends  nothing back and ignores all incoming application messages  
>>> (there  is no fromApp() call).
>>> Both acceptor and initiator are QF (CVS version + your patch).
>>>
>>>
>>> Initiator:
>>>
>>> 20050628-19:38:55 : Created session
>>> 20050628-19:38:55 : Connecting to eng-server on port 57258
>>> 20050628-19:38:55 : Connection succeeded
>>> 20050628-19:38:56 : Initiated logon request
>>> 20050628-19:38:59 : Received logon response
>>> 20050628-19:40:50 : Created session
>>> 20050628-19:40:50 : Connecting to eng-server on port 57258
>>> 20050628-19:40:50 : Connection succeeded
>>> 20050628-19:40:51 : Initiated logon request
>>> 20050628-19:40:51 : Received logon response
>>> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 7
>>> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 6
>>> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 8
>>> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 7
>>> 20050628-19:41:06 : MsgSeqNum too high, expecting  5 but received 9
>>> 20050628-19:41:06 : Sent ResendRequest FROM: 5 TO: 8
>>> ........
>>> .
>>> Acceptor:
>>>
>>> 20050628-19:38:48 : Created session
>>> 20050628-19:38:56 : Received logon request
>>> 20050628-19:38:56 : Responding to logon request
>>> 20050628-19:39:41 : Socket Error
>>> 20050628-19:39:41 : Disconnecting
>>> 20050628-19:40:42 : Created session
>>> 20050628-19:40:51 : Received logon request
>>> 20050628-19:40:51 : Responding to logon request
>>> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
>>> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
>>> 20050628-19:41:06 : Received ResendRequest FROM: 5 TO: 0
>>> 20050628-19:41:21 : Received ResendRequest FROM: 5 TO: 0
>>> 20050628-19:41:36 : Received ResendRequest FROM: 5 TO: 0
>>> 20050628-19:41:51 : Socket Error
>>> 20050628-19:41:51 : Disconnecting
>>>
>>>
>>> Regards, Alexey Zubko Infinium Capital Corporation (416)  
>>> 360-7000  ext. 305
>>>
>>> Brian Erst wrote:
>>>> Oren - I believe the following change to Session.cpp will fix  
>>>> the  timeout problem when receiving out-of-sequence messages  
>>>> while  awaiting a sequence reset/gap-fill: Move the following  
>>>> lines in  Session::verify(...) UtcTimeStamp now;  
>>>> m_state.lastReceivedTime ( now ); from their current position up  
>>>> to a spot just before the  preceding if/else clause: -->>Place  
>>>> the code here<<-- if  ( checkTooHigh && isTargetTooHigh 
>>>> ( msgSeqNum ) )  This will  increment the "lastReceivedTime" in  
>>>> the SessionState object even  when the sequence number is wrong.  
>>>> This appears to solve a whole  bunch of interrelated timeouts  
>>>> that could occur in this scenario  (test request, heartbeat,  
>>>> logon response, etc.) in one quick hit.  Sequence too low is  
>>>> largely unaffected by this change, as it will  cause a  
>>>> disconnect when hit, so that part of the code shouldn't  need to  
>>>> be rearranged. It was somewhat unclear to me whether the   
>>>> following line: m_state.testRequest( 0 ); Also needed to be  
>>>> moved,  but it seemed like it did not. - Brian Erst Thynk  
>>>> Software, Inc.  --- Oren Miller <or...@qu...> wrote:
>>>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/  
>>>>> doc/html/index.html QuickFIX FAQ: http:// 
>>>>> www.quickfixengine.org/ wikifix/index.php?QuickFixFAQ QuickFIX  
>>>>> Support: http:// www.quickfixengine.org/services.html Seems to  
>>>>> me this shouldn't  be happening. I'm guessing that the engine  
>>>>> isn't processing the  message because the sequence number is  
>>>>> too high, hence no  heartbeat is processed. I believe that out  
>>>>> of sequence messages  should probably count as a keep-alive  
>>>>> even if their contents  arn't processed. --oren ----- Original  
>>>>> Message ----- From:  "Alexey Zubko"  
>>>>> <ale...@in...> To: <quickfix-  
>>>>> dev...@li...> Sent: Monday, June 27, 2005   
>>>>> 1:44 PM Subject: [Quickfix-developers] MsgSeqNum too high problem
>>>>>> QuickFIX Documentation: http://www.quickfixengine.org/ 
>>>>>> quickfix/ doc/html/index.html QuickFIX FAQ:
>>>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>>>>> QuickFIX Support: http://www.quickfixengine.org/services.html   
>>>>>> Hi, I'd like to ask if QF initiator acts correctly in the  
>>>>>> following
>>>>> scenario.
>>>>>> The initiator detects that seqnum of a server is too high and  
>>>>>> sends
>>>>> a
>>>>>> resend message. The server doesn't resend requested messages,   
>>>>>> but there are
>>>>> heartbeat
>>>>>> messages. The initiator disconnects because of timeout on   
>>>>>> heartbeat. :-) Below is the initiator's log.  
>>>>>> 20050627-17:52:50 :  Created session 20050627-17:52:51 :  
>>>>>> Connecting to eng-server on  port 5725 20050627-17:52:51 :  
>>>>>> Connection succeeded  20050627-17:52:52 : Initiated logon  
>>>>>> request 20050627-17:53:15 :  Received logon response  
>>>>>> 20050627-17:53:15 : MsgSeqNum too high,  expecting 13 but  
>>>>>> received
>>>>> 15
>>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14   
>>>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>>>> 16
>>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15   
>>>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>>>> 17
>>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16   
>>>>>> 20050627-17:53:22 : Sent test request TEST  
>>>>>> 20050627-17:53:22 :  MsgSeqNum too high, expecting 13 but  
>>>>>> received
>>>>> 18
>>>>>> 20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17   
>>>>>> 20050627-17:53:37 : MsgSeqNum too high, expecting 13 but received
>>>>> 19
>>>>>> 20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18   
>>>>>> 20050627-17:53:40 : Timed out waiting for heartbeat   
>>>>>> 20050627-17:53:40 : Disconnecting -- Regards, Alexey Zubko   
>>>>>> Infinium Capital Corporation (416) 360-7000 ext. 305   
>>>>>> -------------------------------------------------------  
>>>>>> SF.Net  email is sponsored by: Discover Easy Linux Migration
>>>>> Strategies
>>>>>> from IBM. Find simple to follow Roadmaps, straightforward   
>>>>>> articles, informative Webcasts and more! Get everything you  
>>>>>> need  to get up to speed, fast.
>>>>> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>>>> _______________________________________________ Quickfix-  
>>>>>> developers mailing list Quickfix-  
>>>>>> dev...@li... https:// 
>>>>>> lists.sourceforge.net/ lists/listinfo/quickfix-developers
>>>>> ------------------------------------------------------- SF.Net   
>>>>> email is sponsored by: Discover Easy Linux Migration  
>>>>> Strategies  from IBM. Find simple to follow Roadmaps,  
>>>>> straightforward  articles, informative Webcasts and more! Get  
>>>>> everything you need  to get up to speed, fast. http:// 
>>>>> ads.osdn.com/? ad_id=7477&alloc_id=16492&op=click   
>>>>> _______________________________________________ Quickfix-  
>>>>> developers mailing list Quickfix- 
>>>>> dev...@li...  https://lists.sourceforge.net/ 
>>>>> lists/listinfo/quickfix-developers
>>
>>

RE: [Quickfix-developers] Java Exception reveals the problem with TAG 52

[Steve B. <st...@te...>]

> Here is what I see happening
> F (my company) sends a 35=A to C the client
> Client sends 35=A
> QF does not like tag 52...do not know why yet...
> and it tries to reject that message before login occurs
> so an exception is thrown and then we know the rest...
> 
> I guess the same thing happened yesterday with Quickfix.
> 
> This is with QuickfixJ.

Ah, a good compatibility test. ;-)

What is the value of tag 52 in the logon response (assuming
the tag exists)?

Steve

> Oren, now I am going to do the cvs up command see if the updates help
> me nudge along.
> ( I am guessing the CVS up is shorthand for CVS update...I am severely
> handicapped with  C++,  CVS and windows)
> I hope am not being taken for high maintenance user
> --
> RK
> 
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> (8=FIX.4.29=7135=A34=149=FTEST52=20050628-
> 18:28:04.33156=CTEST98=0108=3010=197)
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated logon request)
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, outgoing>
> (8=FIX.4.29=7135=A34=149=FTEST52=20050628-
> 18:28:04.33156=CTEST98=0108=3010=197)
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, incoming>
> (8=FIX.4.29=8735=A49=CTEST56=FTEST34=0000198=052=20050628-
> 18:27:49108=60141=N383=5600010=203)
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (error while receiving
> message
> quickfix.SessionException: Tried to send a reject while not logged on:
> Tag specified out of required order (field 52)
>         at quickfix.Session.generateReject(Session.java:753)
>         at quickfix.Session.next(Session.java:508)
>         at
> quickfix.netty.AbstractSocketInitiator.processMessage(AbstractSocketInitia
> tor.java:210)
>         at quickfix.SocketInitiator.onMessage(SocketInitiator.java:94)
>         at
> quickfix.netty.AbstractSocketInitiator$SessionConnection$NettySessionListe
> ner.messageReceived(AbstractSocketInitiator.java:380)
>         at
> net.gleamynode.netty2.Session.fireMessageReceived(Session.java:733)
>         at
> net.gleamynode.netty2.LowLatencyEventDispatcher.flush(LowLatencyEventDispa
> tcher.java:67)
>         at
> net.gleamynode.netty2.ReadController.processEvent(ReadController.java:360)
>         at net.gleamynode.netty2.IoProcessor.process(IoProcessor.java:334)
>         at
> net.gleamynode.netty2.IoProcessor.access$500(IoProcessor.java:73)
>         at
> net.gleamynode.netty2.IoProcessor$Worker.run(IoProcessor.java:364)
> )
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Dropped Connection)
> FIX.4.2:FTEST->CTEST is LOGGED OUT <20050628-18:28:04,
> FIX.4.2:FTEST->CTEST, outgoing>
> (8=FIX.4.29=7135=A34=249=FTEST52=20050628-
> 18:28:04.63356=CTEST98=0108=3010=203)
> <20050628-18:28:04, FIX.4.2:FTEST->CTEST, event> (Initiated logon request)
> 
> On 6/28/05, VP Marketing IT Asset Enterprise Technologies
> <ass...@gm...> wrote:
> > I switched to an executor in the LAN and it worked fine. You are correct
> > the trouble earlier was with the settings file...
> >
> > The file is there. But there is only one session and that is with an
> external
> > party and it could be failing for a number of reasons.
> >
> > The error (console) output did not indicate that. It misdirects to an
> > initiator not
> > being there.
> >
> > We can talk about how to structure a generic Error control and
> communication
> > exception hierarchy.
> >
> > Consider the following three classes:
> >
> > class QuickfixJErrorList
> > {
> > final String error_string[] =
> > {
> > "ILLEGAL ARGUMENT/INTERNAL ERROR",
> > "CONFIG FILE NOT READABLE",
> > "CONFIG NOT ACCORDING TO SPECIFICATION", // somethign simpler may be
> > "SESSION COULD NOT BE INITIALIZED",
> >
> > };
> > final int base_error=1300;
> > final int error_no[] = {1300,1301,1302, 1303} ; // this coudl be
> > base_error, base_error+1, etc
> >
> > static public String getErrorMessage(int code) {
> > return
> error_string[(code>base_error&&(code<(base_error+error_no.length)))?code:0
> );
> > }
> > static public String getErrorMessage(String code){
> > try {
> > return getErrorMessage(Integer.parseInt(code.trim()));
> > } catch(Exception e) { }
> > return getErrorMessage(0);
> > }
> > }
> > class QuickfixException extends Exception
> > {
> > QuickfixException (String msgCode)
> > {
> > super(QuickfixJErrorList.getErrorMessage(msg);
> > }
> > }
> >
> > And we can implement the JErrorList in XML and load the DOM
> > or put it on HSQLDB or some such thing and manage it from anywhere.
> > instead of being static class...
> >
> > I am hacking as I am writing this email.. the idea may be clearer...
> > I can do this..if you send me a specification what you want.
> > --
> > rk
> >

[Quickfix-developers] RE: No change needed... I like the way it is done..I just changed three lines (modeled after Executor.java) and I got this far..

[Steve B. <st...@te...>]

> It is conceivable that it could not initialize with the host I had 
> given as it is restricted host.

Do you mean it couldn't read the data dictionary from that host?
A failure to connect to the server host shouldn't have caused that
particular error.

> In that case a one liner that the session could not be initialized 
> would be better when the error is detected and continue on with the 
> initialization of other sessions. > One session not hindering the 
> setup of other sessions is a good design principle.

That's what I was thinking, but there are tradeoffs. It sounds like the QF
C++  aborts the startup when a session configuration fails so I think I'll
change QFJ to be the same.
Actually I may add the ability to configure the initiator and acceptor
configuration for either behavior.

> --- I will sign up for some documents and MBean ...as detailed below.
> 
> What we need is set of documents to help people get it to run. Leave 
> that to me...By this Weekend I will send you a word document 
> illustrating everything I did right from downloading for you to edit 
> and share it with everyone.

That sounds good. Thanks.

> quickfix is an excellent idea. And quickfixj makes it irresistible.
> I have the MBean that loads quickfix but dies without trying due to 
> jni issues or when a logon arrives.
> Now with purej we can be cruising along..I have already put the 
> procedure to get JBOSS on gmane and quickfix dev groups.

I've seen you post information about JMX code you were writing with
QuickFIX. One of the QFJ developers has done some prototyping on JMX MBeans
for Sessions and SessionManager (acceptor/initiator).
He's on vacation this week, but maybe we can get a discussion started on
that next week.

Steve

RE: [Quickfix-developers] RE: I have a question about QF-J

[Steve B. <st...@te...>]

I'll look into some better error messages for the session
configuration. For the initial release of QFJ we are being
careful to maintain API upward compatibility with the 
JNI version. However, we may be able to implement your 
suggestion by only adding to the existing API, which 
doesn't break compatibility.

Steve

> -----Original Message-----
> From: qui...@li... [mailto:quickfix-
> dev...@li...] On Behalf Of VP Marketing IT Asset
> Enterprise Technologies
> Sent: Tuesday, June 28, 2005 12:35 PM
> To: Steve Bate
> Cc: qui...@li...
> Subject: Re: [Quickfix-developers] RE: I have a question about QF-J
> 
> QuickFIX Documentation:
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
> 
> I switched to an executor in the LAN and it worked fine. You are correct
> the trouble earlier was with the settings file...
> 
> The file is there. But there is only one session and that is with an
> external
> party and it could be failing for a number of reasons.
> 
> The error (console) output did not indicate that. It misdirects to an
> initiator not
> being there.
> 
> We can talk about how to structure a generic Error control and
> communication
> exception hierarchy.
> 
> Consider the following three classes:
> 
> class QuickfixJErrorList
> {
> final String error_string[] =
> {
> "ILLEGAL ARGUMENT/INTERNAL ERROR",
> "CONFIG FILE NOT READABLE",
> "CONFIG NOT ACCORDING TO SPECIFICATION", // somethign simpler may be
> "SESSION COULD NOT BE INITIALIZED",
> 
> };
> final int base_error=1300;
> final int error_no[] = {1300,1301,1302, 1303} ; // this coudl be
> base_error, base_error+1, etc
> 
> static public String getErrorMessage(int code) {
> return
> error_string[(code>base_error&&(code<(base_error+error_no.length)))?code:0
> );
> }
> static public String getErrorMessage(String code){
> try {
> return getErrorMessage(Integer.parseInt(code.trim()));
> } catch(Exception e) { }
> return getErrorMessage(0);
> }
> }
> class QuickfixException extends Exception
> {
> QuickfixException (String msgCode)
> {
> super(QuickfixJErrorList.getErrorMessage(msg);
> }
> }
> 
> And we can implement the JErrorList in XML and load the DOM
> or put it on HSQLDB or some such thing and manage it from anywhere.
> instead of being static class...
> 
> I am hacking as I am writing this email.. the idea may be clearer...
> I can do this..if you send me a specification what you want.
> --
> rk
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id 492&op=ick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] MsgSeqNum too high problem

[Alexey Z. <ale...@in...>]

HI,

I found the problem.
Acceptor didn't resend messages because my endSeqNo field is 0 but my 
beginString is FIX4.0.
So, in the nextResendRequest function QF tried to get messages from say 
15 to 0.
It's my mistake that I put 0 in my initiator instead of 999999, of course,
but may be we need to change the code anyway?


void Session::nextResendRequest( const Message& resendRequest )
........
  std::string beginString = m_sessionID.getBeginString();
  if ( beginString >= FIX::BeginString_FIX42 && endSeqNo == 0 ||
       beginString <= FIX::BeginString_FIX42 && endSeqNo == 999999 ||
       endSeqNo >= getExpectedSenderNum() )
  { endSeqNo = getExpectedSenderNum() - 1; }

  std::vector < std::string > messages;
  m_state.get( beginSeqNo, endSeqNo, messages );
..........



Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Oren Miller wrote:

> Any idea on why the acceptor is not responding to the ResendRequest?   
> Those acceptance tests are passing.  Do you have the incoming/ 
> outgoing log files for both processes?
>
> --oren
>
> On Jun 28, 2005, at 2:49 PM, Alexey Zubko wrote:
>
>> Hello Brian,
>>
>> Your fix prevents the disconnecting, but I still have a sequencing  
>> problem.
>>
>> Actually I thing there are two problems -
>> 1. Acceptor sends nothing back.
>> 2. Initiator ignores incoming application messages.
>>
>> I've got the problem during debugging - terminating initiator's  
>> process, but it's easy to reproduce:
>> If to increase NextSenderMsgSeqNum number in acceptor's file, after  
>> restart the initiator sends resend requests, the acceptor sends  
>> nothing back and ignores all incoming application messages (there  is 
>> no fromApp() call).
>> Both acceptor and initiator are QF (CVS version + your patch).
>>
>>
>> Initiator:
>>
>> 20050628-19:38:55 : Created session
>> 20050628-19:38:55 : Connecting to eng-server on port 57258
>> 20050628-19:38:55 : Connection succeeded
>> 20050628-19:38:56 : Initiated logon request
>> 20050628-19:38:59 : Received logon response
>> 20050628-19:40:50 : Created session
>> 20050628-19:40:50 : Connecting to eng-server on port 57258
>> 20050628-19:40:50 : Connection succeeded
>> 20050628-19:40:51 : Initiated logon request
>> 20050628-19:40:51 : Received logon response
>> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 7
>> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 6
>> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 8
>> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 7
>> 20050628-19:41:06 : MsgSeqNum too high, expecting  5 but received 9
>> 20050628-19:41:06 : Sent ResendRequest FROM: 5 TO: 8
>> ........
>> .
>> Acceptor:
>>
>> 20050628-19:38:48 : Created session
>> 20050628-19:38:56 : Received logon request
>> 20050628-19:38:56 : Responding to logon request
>> 20050628-19:39:41 : Socket Error
>> 20050628-19:39:41 : Disconnecting
>> 20050628-19:40:42 : Created session
>> 20050628-19:40:51 : Received logon request
>> 20050628-19:40:51 : Responding to logon request
>> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
>> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
>> 20050628-19:41:06 : Received ResendRequest FROM: 5 TO: 0
>> 20050628-19:41:21 : Received ResendRequest FROM: 5 TO: 0
>> 20050628-19:41:36 : Received ResendRequest FROM: 5 TO: 0
>> 20050628-19:41:51 : Socket Error
>> 20050628-19:41:51 : Disconnecting
>>
>>
>> Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000  
>> ext. 305
>>
>> Brian Erst wrote:
>>
>>> Oren - I believe the following change to Session.cpp will fix the  
>>> timeout problem when receiving out-of-sequence messages while  
>>> awaiting a sequence reset/gap-fill: Move the following lines in  
>>> Session::verify(...) UtcTimeStamp now; m_state.lastReceivedTime ( 
>>> now ); from their current position up to a spot just before the  
>>> preceding if/else clause: -->>Place the code here<<-- if  ( 
>>> checkTooHigh && isTargetTooHigh( msgSeqNum ) )  This will  increment 
>>> the "lastReceivedTime" in the SessionState object even  when the 
>>> sequence number is wrong. This appears to solve a whole  bunch of 
>>> interrelated timeouts that could occur in this scenario  (test 
>>> request, heartbeat, logon response, etc.) in one quick hit.  
>>> Sequence too low is largely unaffected by this change, as it will  
>>> cause a disconnect when hit, so that part of the code shouldn't  
>>> need to be rearranged. It was somewhat unclear to me whether the  
>>> following line: m_state.testRequest( 0 ); Also needed to be moved,  
>>> but it seemed like it did not. - Brian Erst Thynk Software, Inc.  
>>> --- Oren Miller <or...@qu...> wrote:
>>>
>>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/ 
>>>> doc/html/index.html QuickFIX FAQ: http://www.quickfixengine.org/ 
>>>> wikifix/index.php?QuickFixFAQ QuickFIX Support: http:// 
>>>> www.quickfixengine.org/services.html Seems to me this shouldn't  be 
>>>> happening. I'm guessing that the engine isn't processing the  
>>>> message because the sequence number is too high, hence no  
>>>> heartbeat is processed. I believe that out of sequence messages  
>>>> should probably count as a keep-alive even if their contents  arn't 
>>>> processed. --oren ----- Original Message ----- From:  "Alexey 
>>>> Zubko" <ale...@in...> To: <quickfix- 
>>>> dev...@li...> Sent: Monday, June 27, 2005  1:44 
>>>> PM Subject: [Quickfix-developers] MsgSeqNum too high problem
>>>>
>>>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/ 
>>>>> doc/html/index.html QuickFIX FAQ:
>>>>
>>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>>>
>>>>> QuickFIX Support: http://www.quickfixengine.org/services.html  Hi, 
>>>>> I'd like to ask if QF initiator acts correctly in the following
>>>>
>>>> scenario.
>>>>
>>>>> The initiator detects that seqnum of a server is too high and sends
>>>>
>>>> a
>>>>
>>>>> resend message. The server doesn't resend requested messages,  but 
>>>>> there are
>>>>
>>>> heartbeat
>>>>
>>>>> messages. The initiator disconnects because of timeout on  
>>>>> heartbeat. :-) Below is the initiator's log. 20050627-17:52:50 :  
>>>>> Created session 20050627-17:52:51 : Connecting to eng-server on  
>>>>> port 5725 20050627-17:52:51 : Connection succeeded  
>>>>> 20050627-17:52:52 : Initiated logon request 20050627-17:53:15 :  
>>>>> Received logon response 20050627-17:53:15 : MsgSeqNum too high,  
>>>>> expecting 13 but received
>>>>
>>>> 15
>>>>
>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14  
>>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>>>
>>>> 16
>>>>
>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15  
>>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>>>
>>>> 17
>>>>
>>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16  
>>>>> 20050627-17:53:22 : Sent test request TEST 20050627-17:53:22 :  
>>>>> MsgSeqNum too high, expecting 13 but received
>>>>
>>>> 18
>>>>
>>>>> 20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17  
>>>>> 20050627-17:53:37 : MsgSeqNum too high, expecting 13 but received
>>>>
>>>> 19
>>>>
>>>>> 20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18  
>>>>> 20050627-17:53:40 : Timed out waiting for heartbeat  
>>>>> 20050627-17:53:40 : Disconnecting -- Regards, Alexey Zubko  
>>>>> Infinium Capital Corporation (416) 360-7000 ext. 305  
>>>>> ------------------------------------------------------- SF.Net  
>>>>> email is sponsored by: Discover Easy Linux Migration
>>>>
>>>> Strategies
>>>>
>>>>> from IBM. Find simple to follow Roadmaps, straightforward  
>>>>> articles, informative Webcasts and more! Get everything you need  
>>>>> to get up to speed, fast.
>>>>
>>>> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>>
>>>>> _______________________________________________ Quickfix- 
>>>>> developers mailing list Quickfix- dev...@li... 
>>>>> https://lists.sourceforge.net/ lists/listinfo/quickfix-developers
>>>>
>>>> ------------------------------------------------------- SF.Net  
>>>> email is sponsored by: Discover Easy Linux Migration Strategies  
>>>> from IBM. Find simple to follow Roadmaps, straightforward  
>>>> articles, informative Webcasts and more! Get everything you need  
>>>> to get up to speed, fast. http://ads.osdn.com/? 
>>>> ad_id=7477&alloc_id=16492&op=click  
>>>> _______________________________________________ Quickfix- 
>>>> developers mailing list Qui...@li...  
>>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>
>

Re: [Quickfix-developers] SocketConnection session registration BUG

[VP M. IT A. E. T. <ass...@gm...>]

Hi Sean

I am Raman. Oren has been helping me to decipher a similar trouble.

I am using QF 1.9.4 and I could not get a connection going.
After trying everything I could with C++, I switched to QF-J Implementation=
.
the FIX Version is 4.2. The problem(s) were as follows:
I was using data dictionary in the settings. This caused the Session to
reject a legitimate LOGON message  from the counterparty.
Java Exception indicated the problem with Tag 52 SendingTime not being in=
=20
order. Since the LOGON message is rejected the session is not active
and any other message (seq..reset etc) all fail. And the app kind of melts
down.

I agree with you 100% I find QF to be an excellent tool well written.
I am planning to add documentation and how-to kind of messages to the
group so the ease of using QF is brought out. Unfortunately I am allergic t=
o
C++. If you need help with java version send me a note.=20


Regards
--
RK
On 6/27/05, Sean Kirkpatrick <Sea...@pi...> wrote:
> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/i=
ndex.html
> QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>=20
> I have added proprietary logging to the quickfix library to help debug
> an issue we have been having with a client not being able to log in.
> We could see the logon message coming across via tethereal, but were
> unable to determine the reason why the socket was being dropped.
>=20
> The following logs expose where the logic error in quickfix occurs:
>=20
> 09:00:20.452 {QF::SocketMonitor::block} Socket [393] has data
> 09:00:20.452 {QF::ServerWrapper::onEvent} data found on socket [393]
> 09:00:20.452 {QF::SocketAcceptor::onData} getting SocketConnection [393]
> 09:00:20.452 {QF::SocketAcceptor::onData} found SocketConnection [393]
> 09:00:20.452 {QF::SocketConnection::read} reading message
> 09:00:20.452 {QF::Parser::readFromStream} socket_fionread returned [72] b=
ytes
> 09:00:20.452 {QF::Parser::readFromStream} recv [72] bytes on socket [393]
> 09:00:20.452 {QF::Parser::readFixMessage} found BeginString tag 8
> 09:00:20.452 {QF::Parser::readFixMessage} found CheckSum tag 10
> 09:00:20.452 {QF::Parser::readFixMessage} found final SOH char
> 09:00:20.452 {QF::Parser::readFixMessage} message [8=3DFIX.4.0^A9=3D50^A3=
5=3D0^A49=3DSEND^A56=3DRECV
> ^A34=3D1^A52=3D20050627-13:00:20^A10=3D056^A]
> 09:00:20.452 {QF::SocketConnection::read} looking for session based on [8=
=3DFIX.4.0^A9=3D50^A35=3D0
> ^A49=3DSEND^A56=3DRECV^A34=3D1^A52=3D20050627-13:00:20^A10=3D056^A]
> 09:00:20.452 {QF::Session::lookupSession} Looking for session: [FIX.4.0:R=
ECV->SEND]
> 09:00:20.452 {QF::Session::lookupSession} FOUND IT!
> 09:00:20.452 {QF::SocketConnection::read} registering session [FIX.4.0:RE=
CV->SEND]
> 09:00:20.453 {QF::Session::lookupSession} Looking for session: [FIX.4.0:R=
ECV->SEND]
> 09:00:20.453 {QF::Session::lookupSession} FOUND IT!
> 09:00:20.453 {QF::Session::registerSession} found session [FIX.4.0:RECV->=
SEND]
> 09:00:20.453 {QF::Session::registerSession} registering session
> ----
> 09:00:20.453 {QF::SocketConnection::read} getting SocketAcceptor session =
[8=3DFIX.4.0^A9=3D50^A35
> =3D0^A49=3DSEND^A56=3DRECV^A34=3D1^A52=3D20050627-13:00:20^A10=3D056^A]
> 09:00:20.453 {QF::Acceptor::getSession} msgType [0] not valid
> 09:00:20.453 {QF::SocketConnection::read} Dropping socket connection
> 09:00:20.453 {QF::SocketConnection::read} reading message
> 09:00:20.453 {QF::Parser::readFromStream} socket_fionread failed
> 09:00:20.453 {QF::SocketMonitor::block} queue has sockets to drop
> 09:00:20.453 {QF::SocketAcceptor::onDisconnect} Disconnecting socket: [39=
3]
> 09:00:20.453 {QF::SocketConnection::~SocketConnection} destroying SocketC=
onnection
>=20
> The problem occurs between the "----" separated log lines.  The library
> registers the session, but then attempts to validate that the recvd messa=
ge
> is a logon.  If it is not, the function return NULL as the m_pSession
> variable.  The next section of the SocketConnection read checks for a val=
id
> m_pSession.  If the session is NULL, the socket is dropped.  When the
> SocketConnection is destroyed, it's m_pSession is still NULL, and the obj=
ect
> is never unregistered.  Subsequent attempts to connect to this session lo=
g
> the following:
>=20
> 09:04:26.744 {QF::SocketMonitor::block} Socket [393] has data
> 09:04:26.744 {QF::ServerWrapper::onEvent} data found on socket [393]
> 09:04:26.744 {QF::SocketAcceptor::onData} getting SocketConnection [393]
> 09:04:26.744 {QF::SocketAcceptor::onData} found SocketConnection [393]
> 09:04:26.744 {QF::SocketConnection::read} reading message
> 09:04:26.744 {QF::Parser::readFromStream} socket_fionread returned [84] b=
ytes
> 09:04:26.744 {QF::Parser::readFromStream} recv [84] bytes on socket [393]
> 09:04:26.745 {QF::Parser::readFixMessage} found BeginString tag 8
> 09:04:26.745 {QF::Parser::readFixMessage} found CheckSum tag 10
> 09:04:26.745 {QF::Parser::readFixMessage} found final SOH char
> 09:04:26.745 {QF::Parser::readFixMessage} message [8=3DFIX.4.0^A9=3D62^A3=
5=3DA^A49=3DSEND^A56=3DRECV
> ^A34=3D3^A52=3D20050627-13:04:26^A98=3D0^A108=3D20^A10=3D112^A]
> 09:04:26.745 {QF::SocketConnection::read} looking for session based on [8=
=3DFIX.4.0^A9=3D62^A35=3DA
> ^A49=3DSEND^A56=3DRECV^A34=3D3^A52=3D20050627-13:04:26^A98=3D0^A108=3D20^=
A10=3D112^A]
> 09:04:26.745 {QF::Session::lookupSession} Looking for session: [FIX.4.0:R=
ECV->SEND]
> 09:04:26.745 {QF::Session::lookupSession} FOUND IT!
> 09:04:26.745 {QF::SocketConnection::read} registering session [FIX.4.0:RE=
CV->SEND]
> 09:04:26.745 {QF::Session::lookupSession} Looking for session: [FIX.4.0:R=
ECV->SEND]
> 09:04:26.745 {QF::Session::lookupSession} FOUND IT!
> 09:04:26.745 {QF::Session::registerSession} found session [FIX.4.0:RECV->=
SEND]
> ----
> 09:04:26.745 {QF::SocketConnection::read} Dropping socket connection
> 09:04:26.745 {QF::SocketConnection::read} reading message
> 09:04:26.745 {QF::Parser::readFromStream} socket_fionread failed
> 09:04:26.745 {QF::SocketMonitor::block} queue has sockets to drop
> 09:04:26.745 {QF::SocketAcceptor::onDisconnect} Disconnecting socket: [39=
3]
> 09:04:26.745 {QF::SocketConnection::~SocketConnection} destroying SocketC=
onnection
>=20
> In between the "----" separated log lines, the session is detected as alr=
eady
> registered and the m_pSession member is again set to NULL and the socket =
is
> dropped.
>=20
> I believe that there is a very simple fix that will correct this issue.  =
The
> order of the following code in SocketConnection::read (the LOGDEBUG lines=
 are
> for the logging I added):
>=20
>  if ( m_pSession ) {
>    LOGDEBUG(funcname,"registering session [%s]",m_pSession->getSessionID(=
).toString().c_str());
>    m_pSession =3D Session::registerSession( m_pSession->getSessionID() );
>  }
>=20
>  if ( m_pSession ) {
>    LOGDEBUG(funcname,"getting SocketAcceptor session [%s]",msg.c_str());
>    m_pSession =3D a.getSession( msg, *this );
>  }
>=20
> needs to be reversed to be:
>=20
>  if ( m_pSession ) {
>    LOGDEBUG(funcname,"getting SocketAcceptor session [%s]",msg.c_str());
>    m_pSession =3D a.getSession( msg, *this );
>  }
>=20
>  if ( m_pSession ) {
>    LOGDEBUG(funcname,"registering session [%s]",m_pSession->getSessionID(=
).toString().c_str());
>    m_pSession =3D Session::registerSession( m_pSession->getSessionID() );
>  }
>=20
> If this is the case, any invalid initial messages will invalidate the
> m_pSession member prior to attempting to register the session.  Only vali=
d
> connections will be registered, and the disconnect logic works fine so
> long as the registration is done properly.  A week of development was los=
t
> due to the lack of engine-level logging in the quickfix library, and I
> know that this is an issue that has been raised several times in the past=
.
>=20
> Please provide feedback.
>=20
> --Sean
>=20
>=20
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id=16492&opclick
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>

Re: [Quickfix-developers] MsgSeqNum too high problem

[Brian E. <azz...@ya...>]

Alexey -

I'm not a QuickFIX developer, but I've rooted around the code a little
bit and about the only explanation I can think of that might explain
your problem is if the sequence number being used by the acceptor is
corrupt or the message offset table is broken.

Looking at nextResendRequest(...) in Session.cpp, it looks like it may
be possible to fall into a trap when an attempt to retrieve the
"missing" messages fails. This may be because the message store is bad
in some non-fatal way (read fails but doesn't throw an exception -
looks like FileStore may do this if message number 'n' simply doesn't
exist in the offsets table) or because the "beginning" sequence number
is greater than the "end" sequence number that actually got stored
(corrupt sequence number). This could happen if, in your scenario,
message number "5" for some reason did not exist in the message store -
the FileStore get() will stop on the first non-existent message number.
Even if 6-8 exist (in the form of heartbeats), the get will return an
empty set.

In this case, because the main for loop is skipped (no messages to
iterate thru), no messages are sent and, as a side-effect of this, no
sequence number reset gets sent either (the code that calls a
generateSequenceReset() call is within an if clause that won't be true
- the "begin" variable never gets set [fails check #1] and endSeqNo and
msgSeqNum are both 0 [fails check #2]).

The acceptor is happy because it increments the initiator's "expected"
sequence number regardless of whether any messages are sent in response
to the resend request, so it will continue to send heartbeats and will
not error out on additional sequence resets.

This is all EXTREMELY seat-of-the-pants analysis - there may well be
checks gonig on under the covers that I'm not aware of. It's an odd
sort of scenario.

- Brian Erst
Thynk Software, Inc.

--- Alexey Zubko <ale...@in...> wrote:

> Hello Brian,
> 
> Your fix prevents the disconnecting, but I still have a sequencing
> problem.
> 
> Actually I thing there are two problems -
> 1. Acceptor sends nothing back.
> 2. Initiator ignores incoming application messages.
> 
> I've got the problem during debugging - terminating initiator's
> process, 
> but it's easy to reproduce:
> If to increase NextSenderMsgSeqNum number in acceptor's file, after 
> restart the initiator sends resend requests, the acceptor sends
> nothing 
> back and ignores all incoming application messages (there is no 
> fromApp() call).
> Both acceptor and initiator are QF (CVS version + your patch).
> 
> 
> Initiator:
> 
> 20050628-19:38:55 : Created session
> 20050628-19:38:55 : Connecting to eng-server on port 57258
> 20050628-19:38:55 : Connection succeeded
> 20050628-19:38:56 : Initiated logon request
> 20050628-19:38:59 : Received logon response
> 20050628-19:40:50 : Created session
> 20050628-19:40:50 : Connecting to eng-server on port 57258
> 20050628-19:40:50 : Connection succeeded
> 20050628-19:40:51 : Initiated logon request
> 20050628-19:40:51 : Received logon response
> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 7
> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 6
> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 8
> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 7
> 20050628-19:41:06 : MsgSeqNum too high, expecting  5 but received 9
> 20050628-19:41:06 : Sent ResendRequest FROM: 5 TO: 8
> .........
> 
> Acceptor:
> 
> 20050628-19:38:48 : Created session
> 20050628-19:38:56 : Received logon request
> 20050628-19:38:56 : Responding to logon request
> 20050628-19:39:41 : Socket Error
> 20050628-19:39:41 : Disconnecting
> 20050628-19:40:42 : Created session
> 20050628-19:40:51 : Received logon request
> 20050628-19:40:51 : Responding to logon request
> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:06 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:21 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:36 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:51 : Socket Error
> 20050628-19:41:51 : Disconnecting
> 
> 
> Regards,
> 		Alexey Zubko
> 
> Infinium Capital Corporation
> (416) 360-7000 ext. 305
> 
> 
> 
> Brian Erst wrote:
> 
> >Oren -
> >
> >I believe the following change to Session.cpp will fix the timeout
> >problem when receiving out-of-sequence messages while awaiting a
> >sequence reset/gap-fill:
> >
> >Move the following lines in Session::verify(...)
> >
> >    UtcTimeStamp now;
> >    m_state.lastReceivedTime( now );
> >
> >from their current position up to a spot just before the preceding
> >if/else clause:
> >
> >-->>Place the code here<<--
> >if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
> >
> >This will increment the "lastReceivedTime" in the SessionState
> object
> >even when the sequence number is wrong. This appears to solve a
> whole
> >bunch of interrelated timeouts that could occur in this scenario
> (test
> >request, heartbeat, logon response, etc.) in one quick hit. Sequence
> >too low is largely unaffected by this change, as it will cause a
> >disconnect when hit, so that part of the code shouldn't need to be
> >rearranged.
> >
> >It was somewhat unclear to me whether the following line:
> >
> >    m_state.testRequest( 0 );
> >
> >Also needed to be moved, but it seemed like it did not.
> >
> >- Brian Erst
> >Thynk Software, Inc.
> >--- Oren Miller <or...@qu...> wrote:
> >
> >  
> >
> >>QuickFIX Documentation:
> >>http://www.quickfixengine.org/quickfix/doc/html/index.html
> >>QuickFIX FAQ:
> >>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> >>QuickFIX Support: http://www.quickfixengine.org/services.html
> >>
> >>Seems to me this shouldn't be happening.  I'm guessing that the
> >>engine isn't 
> >>processing the message because the sequence number is too high,
> hence
> >>no 
> >>heartbeat is processed.  I believe that out of sequence messages
> >>should 
> >>probably count as a keep-alive even if their contents arn't
> >>processed.
> >>
> >>--oren
> >>
> >>----- Original Message ----- 
> >>From: "Alexey Zubko" <ale...@in...>
> >>To: <qui...@li...>
> >>Sent: Monday, June 27, 2005 1:44 PM
> >>Subject: [Quickfix-developers] MsgSeqNum too high problem
> >>
> >>
> >>    
> >>
> >>>QuickFIX Documentation: 
> >>>http://www.quickfixengine.org/quickfix/doc/html/index.html
> >>>QuickFIX FAQ:
> >>>      
> >>>
> >>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> >>    
> >>
> >>>QuickFIX Support: http://www.quickfixengine.org/services.html
> >>>
> >>>Hi,
> >>>
> >>>I'd like to ask if QF initiator acts correctly in the following
> >>>      
> >>>
> >>scenario.
> >>    
> >>
> >>>The initiator detects that seqnum of a server is too high and
> sends
> >>>      
> >>>
> >>a 
> >>    
> >>
> >>>resend message.
> >>>The server doesn't resend requested messages, but there are
> >>>      
> >>>
> >>heartbeat 
> >>    
> >>
> >>>messages.
> >>>The initiator disconnects because of timeout on heartbeat. :-)
> >>>Below is the initiator's log.
> >>>
> >>>20050627-17:52:50 : Created session
> >>>20050627-17:52:51 : Connecting to eng-server on port 5725
> >>>20050627-17:52:51 : Connection succeeded
> >>>20050627-17:52:52 : Initiated logon request
> >>>20050627-17:53:15 : Received logon response
> >>>20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
> >>>      
> >>>
> >>15
> >>    
> >>
> >>>20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14
> >>>20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
> >>>      
> >>>
> >>16
> >>    
> >>
> >>>20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15
> >>>20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
> >>>      
> >>>
> >>17
> >>    
> >>
> >>>20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16
> >>>20050627-17:53:22 : Sent test request TEST
> >>>20050627-17:53:22 : MsgSeqNum too high, expecting  13 but received
> >>>      
> 
=== message truncated ===

RE: [Quickfix-developers] SocketConnection session registration BUG

[Sean K. <Sea...@Pi...>]

I'll have to take a look at the logging you mentioned. It would
definitely be an additional debugging property that would only
write logs if explicitly specified by the end-user.  So would
this DEBUG/TRACE level logging be a welcome addition?

--Sean

> -----Original Message-----
> From: Joerg Thoennes [mailto:Joe...@ma...]
> Sent: Tuesday, June 28, 2005 4:02 PM
> To: Sean Kirkpatrick
> Cc: Oren Miller; qui...@li...
> Subject: Re: [Quickfix-developers] SocketConnection session=20
> registration
> BUG
>=20
>=20
> Sean Kirkpatrick wrote:
> > I'd like to offer my services to get some engine-level logging into
> > the next release of quickfix.  It's a great product and this would
> > help cover any remaining unknowns about messaging prior to=20
> establishing
> > a logon.  I'd be more than happy to follow any coding practices you
> > have so that the logging will integrate seamlessly.  Please=20
> let me know
> > if you are interested in this.
>=20
> Sean, I would suggest to use some Log4J-style logging=20
> library, e.g. log4cplus on=20
> sourceforge. Your engine level logging would be at DEBUG or=20
> TRACE level.
>=20
> Cheers, J=F6rg
>=20
> --=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
>=20

Re: [Quickfix-developers] SocketConnection session registration BUG

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

Yeah, I think that will do although clearly I have not tested that  
exact code block.  The point of the patch is that the session will  
only get registered when all other tests have succeeded.  Just make  
sure that in addition to fixing your problem, you are also still  
passing all the unit/acceptance tests.

--oren

On Jun 28, 2005, at 11:48 AM, Sean Kirkpatrick wrote:

> I was putting this code in, but there is neither readFromSocket() nor
> readMessages() in the SocketConnection object/base in 1.9.4.  Is this
> the version in CVS?  I would prefer to patch the released source,
> if possible.  The function taken directly from 1.9.4 is as follows:
>
> bool SocketConnection::read( SocketAcceptor& a, SocketServer& s )
> { QF_STACK_PUSH(SocketConnection::read)
>
>   std::string msg;
>   try
>   {
>     if ( !readMessage( msg ) ) return false;
>
>     if ( !m_pSession )
>     {
>       m_pSession = Session::lookupSession( msg, true );
>       if ( m_pSession )
>         m_pSession = Session::registerSession( m_pSession- 
> >getSessionID() );
>       if ( m_pSession )
>         m_pSession = a.getSession( msg, *this );
>     }
>
>     if ( m_pSession )
>       m_pSession->next( msg );
>     else
>       s.getMonitor().drop( m_socket );
>     return true;
>   }
>   catch ( RecvFailed& )
>   {
>     s.getMonitor().drop( m_socket );
>   }
>   catch ( InvalidMessage& )
>   {
>     if ( !m_pSession->isLoggedOn() )
>       s.getMonitor().drop( m_socket );
>   }
>   return true;
>
>   QF_STACK_POP
> }
>
> Will modifying the code to be the following (with the extra
> isSessionRegistered check) be a sufficient fix?  Or is it
> necessary to pull the call to readMessage and Session::next
> into the if (!m_pSession) block?
>
> bool SocketConnection::read( SocketAcceptor& a, SocketServer& s )
> { QF_STACK_PUSH(SocketConnection::read)
>
>   std::string msg;
>   try
>   {
>     if ( !readMessage( msg ) ) return false;
>
>     if ( !m_pSession )
>     {
>       m_pSession = Session::lookupSession( msg, true );
>     if ( m_pSession &&
>            Session::isSessionRegistered(m_pSession->getSessionID()) )
>         m_pSession = 0;
>       if ( m_pSession )
>         m_pSession = a.getSession( msg, *this );
>       if ( m_pSession )
>         m_pSession = Session::registerSession( m_pSession- 
> >getSessionID() );
>     }
>
>     if ( m_pSession )
>       m_pSession->next( msg );
>     else
>       s.getMonitor().drop( m_socket );
>     return true;
>   }
>   catch ( RecvFailed& )
>   {
>     s.getMonitor().drop( m_socket );
>   }
>   catch ( InvalidMessage& )
>   {
>     if ( !m_pSession->isLoggedOn() )
>       s.getMonitor().drop( m_socket );
>   }
>   return true;
>
>   QF_STACK_POP
> }
>
> --Sean
>
>
>> -----Original Message-----
>> From: Oren Miller [mailto:or...@qu...]
>> Sent: Tuesday, June 28, 2005 9:27 AM
>> To: Sean Kirkpatrick; qui...@li...
>> Subject: Re: [Quickfix-developers] SocketConnection session
>> registration
>> BUG
>>
>>
>> Sean,
>>
>> When applying your patch, other acceptance tests break.  In
>> fact it results
>> in a crash during a typical multiple logon scenario.  (If you
>> run your
>> acceptance tests, it should reveal the same thing to you).
>> I've included
>> another implementation of SocketConnection::read which passes all the
>> acceptance tests and should also fix the bug you've reported.
>>  Please report
>> back if that is the case:
>>
>> bool SocketConnection::read( SocketAcceptor& a, SocketServer& s )
>> { QF_STACK_PUSH(SocketConnection::read)
>>
>>   std::string msg;
>>   try
>>   {
>>     readFromSocket();
>>
>>     if ( !m_pSession )
>>     {
>>       if ( !readMessage( msg ) ) return false;
>>       m_pSession = Session::lookupSession( msg, true );
>>       if( m_pSession &&
>> Session::isSessionRegistered(m_pSession->getSessionID()) )
>>         m_pSession = 0;
>>       if( m_pSession )
>>         m_pSession = a.getSession( msg, *this );
>>       if( m_pSession )
>>         m_pSession->next( msg );
>>       if( !m_pSession )
>>       {
>>         s.getMonitor().drop( m_socket );
>>         return false;
>>       }
>>
>>       Session::registerSession( m_pSession->getSessionID() );
>>     }
>>
>>     readMessages( s.getMonitor() );
>>     return true;
>>   }
>>   catch ( SocketRecvFailed& e )
>>   {
>>     if( m_pSession )
>>       m_pSession->getLog()->onEvent( e.what() );
>>     s.getMonitor().drop( m_socket );
>>   }
>>   catch ( InvalidMessage& )
>>   {
>>     s.getMonitor().drop( m_socket );
>>   }
>>   return false;
>>
>>   QF_STACK_POP
>> }
>> ----- Original Message -----
>> From: "Sean Kirkpatrick" <Sea...@Pi...>
>> To: <qui...@li...>
>> Sent: Monday, June 27, 2005 10:34 AM
>> Subject: [Quickfix-developers] SocketConnection session
>> registration BUG
>>
>>
>> QuickFIX Documentation:
>> http://www.quickfixengine.org/quickfix/doc/html/index.html
>> QuickFIX FAQ:
>>
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> I believe that there is a very simple fix that will correct this  
> issue.  The
> order of the following code in SocketConnection::read (the LOGDEBUG  
> lines
> are
> for the logging I added):
>
>   if ( m_pSession ) {
>     LOGDEBUG(funcname,"registering session
> [%s]",m_pSession->getSessionID().toString().c_str());
>     m_pSession = Session::registerSession( m_pSession->getSessionID 
> () );
>   }
>
>   if ( m_pSession ) {
>     LOGDEBUG(funcname,"getting SocketAcceptor session [% 
> s]",msg.c_str());
>     m_pSession = a.getSession( msg, *this );
>   }
>
> needs to be reversed to be:
>
>   if ( m_pSession ) {
>     LOGDEBUG(funcname,"getting SocketAcceptor session [% 
> s]",msg.c_str());
>     m_pSession = a.getSession( msg, *this );
>   }
>
>   if ( m_pSession ) {
>     LOGDEBUG(funcname,"registering session
> [%s]",m_pSession->getSessionID().toString().c_str());
>     m_pSession = Session::registerSession( m_pSession->getSessionID 
> () );
>   }
>
>
>
>

Re: [Quickfix-developers] SocketConnection session registration BUG

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

Sean Kirkpatrick wrote:
> I'd like to offer my services to get some engine-level logging into
> the next release of quickfix.  It's a great product and this would
> help cover any remaining unknowns about messaging prior to establishing
> a logon.  I'd be more than happy to follow any coding practices you
> have so that the logging will integrate seamlessly.  Please let me know
> if you are interested in this.

Sean, I would suggest to use some Log4J-style logging library, e.g. log4cplus on 
sourceforge. Your engine level logging would be at DEBUG or TRACE level.

Cheers, Jörg

-- 
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-developers] MsgSeqNum too high problem

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

Any idea on why the acceptor is not responding to the ResendRequest?   
Those acceptance tests are passing.  Do you have the incoming/ 
outgoing log files for both processes?

--oren

On Jun 28, 2005, at 2:49 PM, Alexey Zubko wrote:

> Hello Brian,
>
> Your fix prevents the disconnecting, but I still have a sequencing  
> problem.
>
> Actually I thing there are two problems -
> 1. Acceptor sends nothing back.
> 2. Initiator ignores incoming application messages.
>
> I've got the problem during debugging - terminating initiator's  
> process, but it's easy to reproduce:
> If to increase NextSenderMsgSeqNum number in acceptor's file, after  
> restart the initiator sends resend requests, the acceptor sends  
> nothing back and ignores all incoming application messages (there  
> is no fromApp() call).
> Both acceptor and initiator are QF (CVS version + your patch).
>
>
> Initiator:
>
> 20050628-19:38:55 : Created session
> 20050628-19:38:55 : Connecting to eng-server on port 57258
> 20050628-19:38:55 : Connection succeeded
> 20050628-19:38:56 : Initiated logon request
> 20050628-19:38:59 : Received logon response
> 20050628-19:40:50 : Created session
> 20050628-19:40:50 : Connecting to eng-server on port 57258
> 20050628-19:40:50 : Connection succeeded
> 20050628-19:40:51 : Initiated logon request
> 20050628-19:40:51 : Received logon response
> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 7
> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 6
> 20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 8
> 20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 7
> 20050628-19:41:06 : MsgSeqNum too high, expecting  5 but received 9
> 20050628-19:41:06 : Sent ResendRequest FROM: 5 TO: 8
> ........
> .
> Acceptor:
>
> 20050628-19:38:48 : Created session
> 20050628-19:38:56 : Received logon request
> 20050628-19:38:56 : Responding to logon request
> 20050628-19:39:41 : Socket Error
> 20050628-19:39:41 : Disconnecting
> 20050628-19:40:42 : Created session
> 20050628-19:40:51 : Received logon request
> 20050628-19:40:51 : Responding to logon request
> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:06 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:21 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:36 : Received ResendRequest FROM: 5 TO: 0
> 20050628-19:41:51 : Socket Error
> 20050628-19:41:51 : Disconnecting
>
>
> Regards, Alexey Zubko Infinium Capital Corporation (416) 360-7000  
> ext. 305
>
> Brian Erst wrote:
>> Oren - I believe the following change to Session.cpp will fix the  
>> timeout problem when receiving out-of-sequence messages while  
>> awaiting a sequence reset/gap-fill: Move the following lines in  
>> Session::verify(...) UtcTimeStamp now; m_state.lastReceivedTime 
>> ( now ); from their current position up to a spot just before the  
>> preceding if/else clause: -->>Place the code here<<-- if  
>> ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )  This will  
>> increment the "lastReceivedTime" in the SessionState object even  
>> when the sequence number is wrong. This appears to solve a whole  
>> bunch of interrelated timeouts that could occur in this scenario  
>> (test request, heartbeat, logon response, etc.) in one quick hit.  
>> Sequence too low is largely unaffected by this change, as it will  
>> cause a disconnect when hit, so that part of the code shouldn't  
>> need to be rearranged. It was somewhat unclear to me whether the  
>> following line: m_state.testRequest( 0 ); Also needed to be moved,  
>> but it seemed like it did not. - Brian Erst Thynk Software, Inc.  
>> --- Oren Miller <or...@qu...> wrote:
>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/ 
>>> doc/html/index.html QuickFIX FAQ: http://www.quickfixengine.org/ 
>>> wikifix/index.php?QuickFixFAQ QuickFIX Support: http:// 
>>> www.quickfixengine.org/services.html Seems to me this shouldn't  
>>> be happening. I'm guessing that the engine isn't processing the  
>>> message because the sequence number is too high, hence no  
>>> heartbeat is processed. I believe that out of sequence messages  
>>> should probably count as a keep-alive even if their contents  
>>> arn't processed. --oren ----- Original Message ----- From:  
>>> "Alexey Zubko" <ale...@in...> To: <quickfix- 
>>> dev...@li...> Sent: Monday, June 27, 2005  
>>> 1:44 PM Subject: [Quickfix-developers] MsgSeqNum too high problem
>>>> QuickFIX Documentation: http://www.quickfixengine.org/quickfix/ 
>>>> doc/html/index.html QuickFIX FAQ:
>>> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>>> QuickFIX Support: http://www.quickfixengine.org/services.html  
>>>> Hi, I'd like to ask if QF initiator acts correctly in the following
>>> scenario.
>>>> The initiator detects that seqnum of a server is too high and sends
>>> a
>>>> resend message. The server doesn't resend requested messages,  
>>>> but there are
>>> heartbeat
>>>> messages. The initiator disconnects because of timeout on  
>>>> heartbeat. :-) Below is the initiator's log. 20050627-17:52:50 :  
>>>> Created session 20050627-17:52:51 : Connecting to eng-server on  
>>>> port 5725 20050627-17:52:51 : Connection succeeded  
>>>> 20050627-17:52:52 : Initiated logon request 20050627-17:53:15 :  
>>>> Received logon response 20050627-17:53:15 : MsgSeqNum too high,  
>>>> expecting 13 but received
>>> 15
>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14  
>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>> 16
>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15  
>>>> 20050627-17:53:15 : MsgSeqNum too high, expecting 13 but received
>>> 17
>>>> 20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16  
>>>> 20050627-17:53:22 : Sent test request TEST 20050627-17:53:22 :  
>>>> MsgSeqNum too high, expecting 13 but received
>>> 18
>>>> 20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17  
>>>> 20050627-17:53:37 : MsgSeqNum too high, expecting 13 but received
>>> 19
>>>> 20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18  
>>>> 20050627-17:53:40 : Timed out waiting for heartbeat  
>>>> 20050627-17:53:40 : Disconnecting -- Regards, Alexey Zubko  
>>>> Infinium Capital Corporation (416) 360-7000 ext. 305  
>>>> ------------------------------------------------------- SF.Net  
>>>> email is sponsored by: Discover Easy Linux Migration
>>> Strategies
>>>> from IBM. Find simple to follow Roadmaps, straightforward  
>>>> articles, informative Webcasts and more! Get everything you need  
>>>> to get up to speed, fast.
>>> http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>>> _______________________________________________ Quickfix- 
>>>> developers mailing list Quickfix- 
>>>> dev...@li... https://lists.sourceforge.net/ 
>>>> lists/listinfo/quickfix-developers
>>> ------------------------------------------------------- SF.Net  
>>> email is sponsored by: Discover Easy Linux Migration Strategies  
>>> from IBM. Find simple to follow Roadmaps, straightforward  
>>> articles, informative Webcasts and more! Get everything you need  
>>> to get up to speed, fast. http://ads.osdn.com/? 
>>> ad_id=7477&alloc_id=16492&op=click  
>>> _______________________________________________ Quickfix- 
>>> developers mailing list Qui...@li...  
>>> https://lists.sourceforge.net/lists/listinfo/quickfix-developers

Re: [Quickfix-developers] MsgSeqNum too high problem

[Alexey Z. <ale...@in...>]

Hello Brian,

Your fix prevents the disconnecting, but I still have a sequencing problem.

Actually I thing there are two problems -
1. Acceptor sends nothing back.
2. Initiator ignores incoming application messages.

I've got the problem during debugging - terminating initiator's process, 
but it's easy to reproduce:
If to increase NextSenderMsgSeqNum number in acceptor's file, after 
restart the initiator sends resend requests, the acceptor sends nothing 
back and ignores all incoming application messages (there is no 
fromApp() call).
Both acceptor and initiator are QF (CVS version + your patch).


Initiator:

20050628-19:38:55 : Created session
20050628-19:38:55 : Connecting to eng-server on port 57258
20050628-19:38:55 : Connection succeeded
20050628-19:38:56 : Initiated logon request
20050628-19:38:59 : Received logon response
20050628-19:40:50 : Created session
20050628-19:40:50 : Connecting to eng-server on port 57258
20050628-19:40:50 : Connection succeeded
20050628-19:40:51 : Initiated logon request
20050628-19:40:51 : Received logon response
20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 7
20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 6
20050628-19:40:51 : MsgSeqNum too high, expecting  5 but received 8
20050628-19:40:51 : Sent ResendRequest FROM: 5 TO: 7
20050628-19:41:06 : MsgSeqNum too high, expecting  5 but received 9
20050628-19:41:06 : Sent ResendRequest FROM: 5 TO: 8
.........

Acceptor:

20050628-19:38:48 : Created session
20050628-19:38:56 : Received logon request
20050628-19:38:56 : Responding to logon request
20050628-19:39:41 : Socket Error
20050628-19:39:41 : Disconnecting
20050628-19:40:42 : Created session
20050628-19:40:51 : Received logon request
20050628-19:40:51 : Responding to logon request
20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
20050628-19:40:51 : Received ResendRequest FROM: 5 TO: 0
20050628-19:41:06 : Received ResendRequest FROM: 5 TO: 0
20050628-19:41:21 : Received ResendRequest FROM: 5 TO: 0
20050628-19:41:36 : Received ResendRequest FROM: 5 TO: 0
20050628-19:41:51 : Socket Error
20050628-19:41:51 : Disconnecting


Regards,
		Alexey Zubko

Infinium Capital Corporation
(416) 360-7000 ext. 305



Brian Erst wrote:

>Oren -
>
>I believe the following change to Session.cpp will fix the timeout
>problem when receiving out-of-sequence messages while awaiting a
>sequence reset/gap-fill:
>
>Move the following lines in Session::verify(...)
>
>    UtcTimeStamp now;
>    m_state.lastReceivedTime( now );
>
>from their current position up to a spot just before the preceding
>if/else clause:
>
>-->>Place the code here<<--
>if ( checkTooHigh && isTargetTooHigh( msgSeqNum ) )
>
>This will increment the "lastReceivedTime" in the SessionState object
>even when the sequence number is wrong. This appears to solve a whole
>bunch of interrelated timeouts that could occur in this scenario (test
>request, heartbeat, logon response, etc.) in one quick hit. Sequence
>too low is largely unaffected by this change, as it will cause a
>disconnect when hit, so that part of the code shouldn't need to be
>rearranged.
>
>It was somewhat unclear to me whether the following line:
>
>    m_state.testRequest( 0 );
>
>Also needed to be moved, but it seemed like it did not.
>
>- Brian Erst
>Thynk Software, Inc.
>--- Oren Miller <or...@qu...> wrote:
>
>  
>
>>QuickFIX Documentation:
>>http://www.quickfixengine.org/quickfix/doc/html/index.html
>>QuickFIX FAQ:
>>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>
>>Seems to me this shouldn't be happening.  I'm guessing that the
>>engine isn't 
>>processing the message because the sequence number is too high, hence
>>no 
>>heartbeat is processed.  I believe that out of sequence messages
>>should 
>>probably count as a keep-alive even if their contents arn't
>>processed.
>>
>>--oren
>>
>>----- Original Message ----- 
>>From: "Alexey Zubko" <ale...@in...>
>>To: <qui...@li...>
>>Sent: Monday, June 27, 2005 1:44 PM
>>Subject: [Quickfix-developers] MsgSeqNum too high problem
>>
>>
>>    
>>
>>>QuickFIX Documentation: 
>>>http://www.quickfixengine.org/quickfix/doc/html/index.html
>>>QuickFIX FAQ:
>>>      
>>>
>>http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
>>    
>>
>>>QuickFIX Support: http://www.quickfixengine.org/services.html
>>>
>>>Hi,
>>>
>>>I'd like to ask if QF initiator acts correctly in the following
>>>      
>>>
>>scenario.
>>    
>>
>>>The initiator detects that seqnum of a server is too high and sends
>>>      
>>>
>>a 
>>    
>>
>>>resend message.
>>>The server doesn't resend requested messages, but there are
>>>      
>>>
>>heartbeat 
>>    
>>
>>>messages.
>>>The initiator disconnects because of timeout on heartbeat. :-)
>>>Below is the initiator's log.
>>>
>>>20050627-17:52:50 : Created session
>>>20050627-17:52:51 : Connecting to eng-server on port 5725
>>>20050627-17:52:51 : Connection succeeded
>>>20050627-17:52:52 : Initiated logon request
>>>20050627-17:53:15 : Received logon response
>>>20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
>>>      
>>>
>>15
>>    
>>
>>>20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 14
>>>20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
>>>      
>>>
>>16
>>    
>>
>>>20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 15
>>>20050627-17:53:15 : MsgSeqNum too high, expecting  13 but received
>>>      
>>>
>>17
>>    
>>
>>>20050627-17:53:15 : Sent ResendRequest FROM: 13 TO: 16
>>>20050627-17:53:22 : Sent test request TEST
>>>20050627-17:53:22 : MsgSeqNum too high, expecting  13 but received
>>>      
>>>
>>18
>>    
>>
>>>20050627-17:53:22 : Sent ResendRequest FROM: 13 TO: 17
>>>20050627-17:53:37 : MsgSeqNum too high, expecting  13 but received
>>>      
>>>
>>19
>>    
>>
>>>20050627-17:53:37 : Sent ResendRequest FROM: 13 TO: 18
>>>20050627-17:53:40 : Timed out waiting for heartbeat
>>>20050627-17:53:40 : Disconnecting
>>>
>>>
>>>
>>>-- 
>>>
>>>Regards,
>>>Alexey Zubko
>>>
>>>Infinium Capital Corporation
>>>(416) 360-7000 ext. 305
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>SF.Net email is sponsored by: Discover Easy Linux Migration
>>>      
>>>
>>Strategies
>>    
>>
>>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>>informative Webcasts and more! Get everything you need to get up to
>>>speed, fast.
>>>      
>>>
>>http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>    
>>
>>>_______________________________________________
>>>Quickfix-developers mailing list
>>>Qui...@li...
>>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>>
>>>      
>>>
>>
>>-------------------------------------------------------
>>SF.Net email is sponsored by: Discover Easy Linux Migration
>>Strategies
>>from IBM. Find simple to follow Roadmaps, straightforward articles,
>>informative Webcasts and more! Get everything you need to get up to
>>speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>>_______________________________________________
>>Quickfix-developers mailing list
>>Qui...@li...
>>https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>>
>>    
>>
>
>
>  
>