{{Quickfixn}} [quickfixn] Heartbeat not sent during constant traffic (#57)

[Chris Busbey]

Hey Matt,

Thanks for re-posting to the mailing list.  Just curious, have you seen
this as an issue in a production environment?  What is the saturation point
(msgs/sec) in constant traffic where the receiving app doesn't get a chance
to send a heartbeat?

On Fri, Apr 27, 2012 at 7:03 AM, James Downs <jcdowns at connamara.com> wrote:

> Matt,
> IMHO, I don't think the receiving app in this case should send a
> heartbeat. Obviously, it is necessary for the sending app to send the
> TestRequest and the receiving app to respond with a heartbeat.
> I have seen the situation where the receiving app is a slow consumer and
> fails to process the TestRequest and send the heartbeat in time to prevent
> the sending app from disconnecting.
>
> Jim
>
>
> On Fri, Apr 27, 2012 at 8:14 AM, Matt Wood <mjwood7 at gmail.com> wrote:
>
>> I have also included the distribution for any commentary on this:
>>
>> I did some further reading, specifically from the sections you quoted.
>> Right before the section you included was this line:
>>
>> "When either end of a FIX connection has not *sent* any data for
>> [HeartBtInt] seconds, it will transmit a Heartbeat
>> message. "
>>
>> source:
>> http://fixprotocol.org/documents/346/fix-44_w_Errata_20030618_PDF.zip
>> Volume2, Page 16, Section “Administrative Messages”:
>>
>>
>> So with the current code, my scenario where I receive constant traffic
>> (perhaps a HeartBtInt+ second long stream of IOI messages) causes me
>> skip a heartbeat. You are right that other end should send a test
>> message, but in the same sense, I should be sending a heartbeat.
>>
>> any thoughts?
>>
>> Thanks,
>>
>> -Matt
>>
>> On Tue, Apr 24, 2012 at 10:42 AM, Chris Busbey
>> <
>> reply+i-3929507-2099e5ccd1f624f6f2364dd2edaa1dde4ad196cb-1503061 at reply.github.com
>> >
>> wrote:
>> > I don't think this is necessarily a bug.  The fix protocol handles both
>> sides of the heartbeat transaction.  Take a look at this:
>> >
>> > http://fixwiki.fixprotocol.org/fixwiki/Heartbeat
>> >
>> > Specifically the part about when a side has not received a heartbeat in
>> the heartbeat interval.
>> >
>> >> When either end of the connection has not received any data for
>> (HeartBtInt + "some reasonable transmission time")
>> >> seconds, it will transmit a Test Request message. If there is still no
>> Heartbeat message received after
>> >> (HeartBtInt + "some reasonable transmission time") seconds then the
>> connection should be considered lost and corrective
>> >> action be initiated.
>> >
>> > In the scenario you gave, the counter party sending the constant
>> traffic should notice that no heartbeat has been sent and send a test
>> message.  Assuming the test message is properly received and responded to
>> (which it will, see Session.Next and Session.NextTestRequest), all should
>> be good.  It won't kill the connection until after the test message is sent
>> + heartbt int + "some reasonable transmission time"
>> >
>> > ---
>> > Reply to this email directly or view it on GitHub:
>> > https://github.com/connamara/quickfixn/issues/57#issuecomment-5305992
>> _______________________________________________
>> Quickfixn mailing list
>> Quickfixn at lists.quickfixn.com
>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>>
>
>
>
> --
>
> *Connamara Systems, LLC*
> *Made-To-Measure Trading Solutions.*
> Exactly what you need. No more. No less.*
> *
> http://www.connamara.com <http://connamara.com/>
>
>
> _______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
>
>


-- 
Chris Busbey
Connamara Systems, LLC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20120427/a6058e19/attachment-0002.htm>