[QFJ-380] Incorrect response to invalid sequence reset acknowledgment Created: 09/Dec/08  Updated: 05/Apr/10  Resolved: 05/Apr/10

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.3.0, 1.3.1, 1.3.2, 1.3.3
Fix Version/s: 1.4.0

Type: Bug Priority: Default
Reporter: Nataraj Dasgupta Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: None
Environment:

All environments. Clients using Java Sample Code provided by QuickFIX

Issue Links:
Relates
is related to QFJ-383 Add ability to infer sequence reset a... Closed

 Description   

Hi,

We work on a number of FIX implementation where users connect to us using the QuickFIX FIX engine. Ours us a Cameron Engine. We offer 2 sessions - an Order Session and a MKD Session for each user.

We have been observing issues lately with Logon sessions with 141=Y at initial startup. There are 2 different issues we have observed that we need to attend urgently. We have worked numerous possibilities including modifying Configuration settings, but to no avail. Also, it is not viable for us to request all QuickFIX users to modify the source.

1) Client sends Logon with 141=Y with MsgSeqNum=1. Cameron replies with Logon Acnowledgment but without 141=Y and SeqNum=1. QuickFIX is unable to handle the Logon Acknowledgment with missing 141 Tag. QuickFIX assumes that the initial Logon was not acknowledged and sends a second Logon with SeqNum 2. Cameron sees a duplicate Logon request (whilst already connected) and rejects the Logon message. At this point, although both systems are connected, the Engine goes into a strange state and certain procedures such as MKD requests begin failing.

2) Client sends Logon with 141=Y. Cameron sends Logon Acknowledgment without 141=Y and SeqNum=1. QuickFIX assumes that no Logon Acknowledgement was received. QuickFIX then sends the following message, for eg., a TestRequest or Heartbeat with SeqNum=1. Cameron sees MesgSeqNum lower than the expected SeqNum of 2 and terminates the session.

Thanks. Nataraj.

 Comments   
Comment by Nataraj Dasgupta [ 09/Dec/08 ]

I should add that we have observed this behaviour with FIX 4.3.

Comment by Steve Bate [ 09/Dec/08 ]

You mention QuickFIX several time in your issue rather than QuickFIX/J which is a completely different implementation. Are you sure the issue is with QuickFIX/J (the Java implementation of the C++ QuickFIX)?

Comment by Steve Bate [ 09/Dec/08 ]

I've found the code related to this behavior and there are a couple of issues. First, it appears that Cameron FIX is behaving in a nonstandard way. According to the FIX spec (FIX 4.4, but I'm assuming it's the same in FIX 4.3):

" ... 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."

Therefore, QFJ is also not behaving according to the spec. If the 141=Y value is not in the response logon message, we should drop the connection. Sending another logon is clearly incorrect behavior. However, my guess is that you'd like QFJ to accomodate the nonstandard Cameron behavior. Have you spoken to the vendor about this issue?

Comment by Nataraj Dasgupta [ 09/Dec/08 ]

Hi Steve,

Thanks for your reply. It is QuickFIX/J. Regarding the requirement to send 141 in acnowledgment if Logon has 141=Y, as per the FIX specs, is a requirement IF the logon is performed while already connected to maintain 24 hr. connectivity. The FIX specs however does not have specs for Logon Acknowledgment for the Intial Logon, ...

I'd think that this would happen for other clients too who are using the sample code to connect Cameron-QFJ and trying reset at logon ...

Thanks. Nataraj.

Comment by Nataraj Dasgupta [ 10/Dec/08 ]

Hi,

Could someone from the QF/J dev group please comment on the issue. This has been also discussed on the fixprotocol site and it is deemed that this is a potential bug in QF/J and needs to be resolved. I'd imagine that this would involve minimal code change and can be deployed soon,

Thanks. Nataraj.

Comment by Steve Bate [ 11/Dec/08 ]

I'll modify the code to disconnect in this scenario. I'll also add an feature request to add the ability to optionally infer that the reset was successful if the response logon has a sequence number of 1.

Comment by Steve Bate [ 11/Dec/08 ]

A logon with 141=Y is, by definition, always an initial login of a session.

I've responded to the comments on the FPL site. Once again, I suggest you submit a bug report to Orc Software. The root problem is with Cameron FIX. The change I have made makes QFJ response compliant with the spec but does NOT solve your problem in general. All QFJ users not upgrade immediately and the Cameron FIX behavior may cause problems with other FIX engine implementations. You need to get a patched version of Cameron FIX or modify it to respond properly to the sequence reset. Those are the only safe solutions on your end.

Comment by Nataraj Dasgupta [ 12/Dec/08 ]


Ah, Hi Steve, didn't realize you were from QFJ dev ! Sure, we can talk with Orc Software as you have pointed out. In the meantime, could you also please give me an estimate of when the updated code will be released, so that we can inform users who are currently experiencing this issue. Thanks ! - Raj.

Comment by Nataraj Dasgupta [ 14/Jan/09 ]

Hi Steve,

I am told that with the new changes, the application is still trying to reconnect. The following is the behaviour

"When quickfixj tries to connect with 141=Y and if in response there is no 141=Y, application disconnects and try to connect again. This cycle continues."

Could you please comment,

Thanks,

  • Nataraj.
Generated at Sat May 11 08:02:37 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.