[QFJ-648] Logon with negative heartbeat interval (HeartBtInt) should be rejected Created: 08/Nov/11  Updated: 01/Dec/11  Resolved: 01/Dec/11

Status: Closed
Project: QuickFIX/J
Component/s: Engine
Affects Version/s: 1.5.1
Fix Version/s: 1.5.2

Type: Bug Priority: Default
Reporter: Christoph John Assignee: Christoph John
Resolution: Fixed Votes: 0
Labels: session, timeout


 Description   

When logging on with a negative heartbeat interval, the Logon is accepted but then the connection is terminated immediately due to a Heartbeat timeout ("Disconnecting: Timed out waiting for heartbeat").

I would propose to reject the Logon in case of a negative HeartBtInt setting.

Maybe the check for the negative interval should be done somewhere at the beginning inside Session.nextLogon(). Is this a valid place for this check? Any comments?



 Comments   
Comment by Grant Birchmeier [ 08/Nov/11 ]

I can't resist asking: Who is sending you a negative heartbeat interval?

Comment by Christoph John [ 08/Nov/11 ]

This is an issue that came up when one of our customers was doing internal tests.

In my opinion this issue should be handled more clearly by QF/J since the current handling is not very optimal: The acceptor receives the Logon message and even replies with a Logon message. The initiator receives the Logon message and immediately afterwards the connection is dropped by the counterparty.

According to the spec: "In general a Logout message should always be sent prior to shutting down a connection. If the Logout is being sent due to an error condition, the Text field of the Logout should provide a descriptive reason, so that operational support of the remote FIX system can diagnosis the problem."

I agree that a lot of people would spot this problem once they look at the Logon messages. But most of the support staff does not have such a low level view. So for the support staff it can be very time-consuming to tackle problems that do not look like a problem at first sight (since the Logon is accepted).

Generated at Sat May 04 09:45:41 UTC 2024 using JIRA 7.5.2#75007-sha1:9f5725bb824792b3230a5d8716f0c13e296a3cae.