[QFJ-946] Improve misleading error message during Logon Created: 21/Mar/18  Updated: 26/Mar/18

Status: Open
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.6.4
Fix Version/s: None

Type: Improvement Priority: Default
Reporter: Nikolai Kulakov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Environment:

Linux


 Description   

It seems that the network connection between my company and our partner is very fast and the QuickFix/J engine suppose that their answering Logon message is coming before we send our Logon message:

8=FIX.4.2^A9=86^A35=A^A34=1^A49=fxw2^A52=20180321-14:09:01.447^A56=JLQD^A98=0^A108=30^A141=Y^A554=password^A10=253^A
8=FIX.4.2^A9=0065^A35=A^A34=317^A49=JLQD^A52=20180321-14:09:01.453^A56=fxw2^A98=0^A108=30^A10=119^A
8=FIX.4.2^A9=86^A35=A^A34=1^A49=fxw2^A52=20180321-14:09:04.413^A56=JLQD^A98=0^A108=30^A141=Y^A554=password^A10=249^A
8=FIX.4.2^A9=0065^A35=A^A34=318^A49=JLQD^A52=20180321-14:09:04.417^A56=fxw2^A98=0^A108=30^A10=123^A
8=FIX.4.2^A9=86^A35=A^A34=1^A49=fxw2^A52=20180321-14:09:07.413^A56=JLQD^A98=0^A108=30^A141=Y^A554=password^A10=252^A
8=FIX.4.2^A9=0065^A35=A^A34=319^A49=JLQD^A52=20180321-14:09:07.416^A56=fxw2^A98=0^A108=30^A10=126^A
etc

<2018-03-21 10:09:00.329 0400> <Session FIX.4.2:fxw2>JLQD:MARKET_DATA schedule is weekly, SUN 21:30:00-UTC - SUN 21:00:00-UTC (weekly, SUN 17:30:00-EDT - SUN 17:00:00-EDT)>
<2018-03-21 10:09:00.330 0400> <Created session: FIX.4.2:fxw2>JLQD:MARKET_DATA>
<2018-03-21 10:09:00.409 -0400> <Configured socket addresses for session: [/some_ip:port]>
<2018-03-21 10:09:00.444 -0400> <MINA session created: local=/172.20.30.34:57198, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/some_ip:port>
<2018-03-21 10:09:01.453 -0400> <Initiated logon request>
<2018-03-21 10:09:01.462 -0400> <Received logon>
<2018-03-21 10:09:01.462 -0400> <Disconnecting: Received logon response before sending request>
<2018-03-21 10:09:03.461 -0400> <MINA session created: local=/172.20.30.34:57200, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/some_ip:port>
<2018-03-21 10:09:04.417 -0400> <Initiated logon request>
<2018-03-21 10:09:04.421 -0400> <Received logon>
<2018-03-21 10:09:04.421 -0400> <Disconnecting: Received logon response before sending request>
<2018-03-21 10:09:06.468 -0400> <MINA session created: local=/172.20.30.34:57202, class org.apache.mina.transport.socket.nio.NioSocketSession, remote=/some_ip:port>
<2018-03-21 10:09:07.415 -0400> <Initiated logon request>
<2018-03-21 10:09:07.419 -0400> <Received logon>
<2018-03-21 10:09:07.419 -0400> <Disconnecting: Received logon response before sending request>
etc.

So, I do not see any way to establish the connection.

 Comments   
Comment by Nikolai Kulakov [ 21/Mar/18 ]

After further investigation of the problem, I guess that the problem is not in the speed of the connection, but in the fact that we set ResetSeqNumFlag=Y in the our Logon message but in the answering Logon message it is not presented (so, the priority of the problem can be lowered).

The code that is generating this error is in the method quickfix.Session#nextLogon:

        // Check for proper sequence reset response
        if (state.isResetSent() && !state.isResetReceived()) {
            disconnect("Received logon response before sending request", true);
        }

It can be a problem indeed, but the disconnect message seems totally misleading for me.
Also, I do not see any benefits to break down the connection in this case (we sent ResetSeqNumFlag but did not received it in the answer).

Comment by Christoph John [ 21/Mar/18 ]

I don't know but what sense does it make to reset the sequence numbers only on one side? So I guess the check might have a point. Unless I'm missing something.

Comment by Nikolai Kulakov [ 21/Mar/18 ]

Just a real situation: our partner is ready to reset the sequence number on the one side only. It seems that using ResetSeqNumFlag for this purpose it is not nice by FIX standards, but also it is a fact that this situation is not related with the "Received logon response before sending request".
Also, it is not clear for me why dropping down the connection is better than working.

Comment by Christoph John [ 21/Mar/18 ]

I think it does not make sense to open a bug ticket for every counterparty that does not conform to normal FIX standard.
If the counterparty wanted that you reset your sequence numbers I guess they should be sending you tag 141 in their Logon. At least IMHO.
Why are you sending 141? Does the counterparty require you to do so?

IMHO the best would be to direct such questions to the mailing list. Please post follow up questions and your answers there.
https://sourceforge.net/projects/quickfixj/lists/quickfixj-users

Thanks

Comment by Nikolai Kulakov [ 21/Mar/18 ]

John, I agree that it is no sence to open a bug ticket for a counetrparty that does not conform regular FIX standard (of course, I'll discuss this situation with them directly). But the ticket is about another thing and I'm really sorry if I'm describing it not clear.
The problem is that the engine is disconnecting with "Received logon response before sending request" when there is no such situation (logon response is coming after sending request).
Thank you for the patience.

Generated at Sat Apr 27 20:00:55 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.