Matt,<div>Yeah. After thinking about it some more, the receiving app should send out the heartbeat if it hasn't sent any data for a heartbeat interval. I just got back from vacation today so I must still be "on the beach".</div>
<div>Jim<br><br><div class="gmail_quote">On Fri, Apr 27, 2012 at 10:26 AM, Matt Wood <span dir="ltr"><<a href="mailto:mjwood7@gmail.com">mjwood7@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
And James, to your point: Why don't you think the app (my side) should<br>
be sending a heartbeat during that time? From the perspective of the<br>
other end (vendor side) they haven't heard from me for several<br>
heartbeat intervals. Plus, what are your thoughts on what the protocol<br>
spec said (that I quoted previously) with regard to this? Perhaps its<br>
open to a bit of interpretation so I'm curious to hear your thoughts.<br>
<br>
Thanks,<br>
<br>
Matt<br>
<div class="HOEnZb"><div class="h5"><br>
On Fri, Apr 27, 2012 at 11:16 AM, Matt Wood <<a href="mailto:mjwood7@gmail.com">mjwood7@gmail.com</a>> wrote:<br>
> Yes I have seen it in our production environment. At the start of the<br>
> trading day today I saw ~68 IOI's/second. This can go on for several<br>
> minutes until we reach the typical market inventory of about 30,000<br>
> offerings. I calculate that at that rate it should take just over 7<br>
> minutes, which seems about right when I'm watching it. Before I<br>
> applied any logic to force a heartbeat every 30 seconds, we'd get<br>
> logged off around (2x HeartBtInt), if I remember correctly.<br>
><br>
> -Matt<br>
><br>
> On Fri, Apr 27, 2012 at 10:18 AM, Chris Busbey <<a href="mailto:cbusbey@connamara.com">cbusbey@connamara.com</a>> wrote:<br>
>> Hey Matt,<br>
>><br>
>> Thanks for re-posting to the mailing list. Just curious, have you seen this<br>
>> as an issue in a production environment? What is the saturation point<br>
>> (msgs/sec) in constant traffic where the receiving app doesn't get a chance<br>
>> to send a heartbeat?<br>
>><br>
>> On Fri, Apr 27, 2012 at 7:03 AM, James Downs <<a href="mailto:jcdowns@connamara.com">jcdowns@connamara.com</a>> wrote:<br>
>>><br>
>>> Matt,<br>
>>> IMHO, I don't think the receiving app in this case should send a<br>
>>> heartbeat. Obviously, it is necessary for the sending app to send the<br>
>>> TestRequest and the receiving app to respond with a heartbeat.<br>
>>> I have seen the situation where the receiving app is a slow consumer and<br>
>>> fails to process the TestRequest and send the heartbeat in time to prevent<br>
>>> the sending app from disconnecting.<br>
>>><br>
>>> Jim<br>
>>><br>
>>><br>
>>> On Fri, Apr 27, 2012 at 8:14 AM, Matt Wood <<a href="mailto:mjwood7@gmail.com">mjwood7@gmail.com</a>> wrote:<br>
>>>><br>
>>>> I have also included the distribution for any commentary on this:<br>
>>>><br>
>>>> I did some further reading, specifically from the sections you quoted.<br>
>>>> Right before the section you included was this line:<br>
>>>><br>
>>>> "When either end of a FIX connection has not *sent* any data for<br>
>>>> [HeartBtInt] seconds, it will transmit a Heartbeat<br>
>>>> message. "<br>
>>>><br>
>>>> source:<br>
>>>> <a href="http://fixprotocol.org/documents/346/fix-44_w_Errata_20030618_PDF.zip" target="_blank">http://fixprotocol.org/documents/346/fix-44_w_Errata_20030618_PDF.zip</a><br>
>>>> Volume2, Page 16, Section “Administrative Messages”:<br>
>>>><br>
>>>><br>
>>>> So with the current code, my scenario where I receive constant traffic<br>
>>>> (perhaps a HeartBtInt+ second long stream of IOI messages) causes me<br>
>>>> skip a heartbeat. You are right that other end should send a test<br>
>>>> message, but in the same sense, I should be sending a heartbeat.<br>
>>>><br>
>>>> any thoughts?<br>
>>>><br>
>>>> Thanks,<br>
>>>><br>
>>>> -Matt<br>
>>>><br>
>>>> On Tue, Apr 24, 2012 at 10:42 AM, Chris Busbey<br>
>>>><br>
>>>> <<a href="mailto:reply%2Bi-3929507-2099e5ccd1f624f6f2364dd2edaa1dde4ad196cb-1503061@reply.github.com">reply+i-3929507-2099e5ccd1f624f6f2364dd2edaa1dde4ad196cb-1503061@reply.github.com</a>><br>
>>>> wrote:<br>
>>>> > I don't think this is necessarily a bug. The fix protocol handles both<br>
>>>> > sides of the heartbeat transaction. Take a look at this:<br>
>>>> ><br>
>>>> > <a href="http://fixwiki.fixprotocol.org/fixwiki/Heartbeat" target="_blank">http://fixwiki.fixprotocol.org/fixwiki/Heartbeat</a><br>
>>>> ><br>
>>>> > Specifically the part about when a side has not received a heartbeat in<br>
>>>> > the heartbeat interval.<br>
>>>> ><br>
>>>> >> When either end of the connection has not received any data for<br>
>>>> >> (HeartBtInt + "some reasonable transmission time")<br>
>>>> >> seconds, it will transmit a Test Request message. If there is still no<br>
>>>> >> Heartbeat message received after<br>
>>>> >> (HeartBtInt + "some reasonable transmission time") seconds then the<br>
>>>> >> connection should be considered lost and corrective<br>
>>>> >> action be initiated.<br>
>>>> ><br>
>>>> > In the scenario you gave, the counter party sending the constant<br>
>>>> > traffic should notice that no heartbeat has been sent and send a test<br>
>>>> > message. Assuming the test message is properly received and responded to<br>
>>>> > (which it will, see Session.Next and Session.NextTestRequest), all should be<br>
>>>> > good. It won't kill the connection until after the test message is sent +<br>
>>>> > heartbt int + "some reasonable transmission time"<br>
>>>> ><br>
>>>> > ---<br>
>>>> > Reply to this email directly or view it on GitHub:<br>
>>>> > <a href="https://github.com/connamara/quickfixn/issues/57#issuecomment-5305992" target="_blank">https://github.com/connamara/quickfixn/issues/57#issuecomment-5305992</a><br>
>>>> _______________________________________________<br>
>>>> Quickfixn mailing list<br>
>>>> <a href="mailto:Quickfixn@lists.quickfixn.com">Quickfixn@lists.quickfixn.com</a><br>
>>>> <a href="http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com" target="_blank">http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> Connamara Systems, LLC<br>
>>> Made-To-Measure Trading Solutions.<br>
>>> Exactly what you need. No more. No less.<br>
>>> <a href="http://www.connamara.com" target="_blank">http://www.connamara.com</a><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Quickfixn mailing list<br>
>>> <a href="mailto:Quickfixn@lists.quickfixn.com">Quickfixn@lists.quickfixn.com</a><br>
>>> <a href="http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com" target="_blank">http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com</a><br>
>>><br>
>><br>
>><br>
>><br>
>> --<br>
>> Chris Busbey<br>
>> Connamara Systems, LLC<br>
>><br>
>> _______________________________________________<br>
>> Quickfixn mailing list<br>
>> <a href="mailto:Quickfixn@lists.quickfixn.com">Quickfixn@lists.quickfixn.com</a><br>
>> <a href="http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com" target="_blank">http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com</a><br>
>><br>
_______________________________________________<br>
Quickfixn mailing list<br>
<a href="mailto:Quickfixn@lists.quickfixn.com">Quickfixn@lists.quickfixn.com</a><br>
<a href="http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com" target="_blank">http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><br><div><div style="font-family:arial,sans-serif;font-size:13px"><b style="background-color:rgb(255,255,255)"><font color="#3333ff">Connamara Systems, LLC</font></b><br>
</div><div><font><b>Made-To-Measure Trading Solutions.</b></font></div><div><font>Exactly what you need. No more. No less.</font><font><b><font color="#3333ff"><br></font></b></font></div><div><font><a href="http://connamara.com/" style="color:rgb(17,85,204)" target="_blank">http://www.connamara.com</a></font></div>
</div><br>
</div>