Re: [Quickfixj-users] Issues with Heartbeat When Connecting via HTTP Proxy

[Andrew M. <mar...@gm...>]

I am pleased to report that one of our software engineers tried something
today and that made it work. We were told that the ECN side speaks
FIX-5.0(SP2) so we used those classes from QFJ. They also supplied us with
a FIX5.0SP2 Data Dictionary. However, it turns out that in order to
establish the session properly we have to speak 4.4 but still use the
0.5SP2 DD. Now that we do this, it works. And yes it works without having
to login. The system engages in heartbeats, quite frequently (lots of SSL
noise when full debug is turned on).

Once again, as a relative newcomer to FIX, I am disappointed that there
isn't some sort of protocol negotiation like there is with SSL/TLS. I know
that in theory this is supposed to be un-necessary because both sides
should be talking to each other to sort these things out but theory and
practise differ. With the trade feeds that connect to ECNs that I have been
involved in recently there is little or no communication and connectivity
details cannot be relied on to be accurate. Why, in the last feed I worked
on a few weeks back we found that the UTC datetime values were coming over
the wire with a spurious "Z" on the end, causing the messages to fail DD
validation. We had to write code to munge those fields. Gah! We also find
that the DD is changed without notice such that message validation fails. I
know these things are not supposed to happen but they do. It's a shame that
FIX cannot do anything about it in its current form.

On Wed, 2 Dec 2020 at 14:30, Christoph John via Quickfixj-users <
qui...@li...> wrote:

> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J <http://www.quickfixj.org/documentation/QuickFIX/J> Support:
> http://www.quickfixj.org/support/
>
>
> Hi,
>
> can you share some message and event logs?
> Are you saying that the connection only breaks when a Heartbeat *needs* to
> be sent, i.e. when there is always traffic the connection works, but in
> quiet times the connection will break?
>
> Cheers,
> Chris.
>
>
> On 24.11.20 09:57, Florian Leu wrote:
>
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
> Hi everyone
>
> I have a weird issue that my quickfix initiator works fine when connecting
> directly to the message supplier, but as soon as we connect via an HTTP
> proxy, it works for the first n seconds and then the messages stop
> arriving.
>
> I've now managed to trace the problem to the fact that those n seconds are
> exactly what is configured for the heartbeat interval, i.e. if I set this
> heartbeat interval higher, then it works longer and if I set it e.g. to 5,
> then it already stops after 5 seconds.
>
> At first I assumed the counter-party just closes the connection if they
> don't receive the heartbeat on time, but then I learned that after a
> missing heartbeat message first a test request is sent out and only after
> that a connection would be closed. So it seems to me that actually the
> sending out of the heartbeat from the Quickfix/j library (version 2.2.0)
> via proxy somehow seems to block the incoming traffic, as though the proxy
> was a one way street. Since the logon message exchange works, I know that
> communicating both ways actually works, but it seems that sending out a
> heartbeat while simultaneously processing an incoming stream of messages
> seems to somehow cut of this incoming stream for good. I can literally see
> in my logs that the incoming messages are processed via the fromApp method
> exactly up to the point that my first heartbeat is sent out, so logging
> this heartbeat via the toAdmin method is always the last thing logged
> before the communication stops altogether....no new incoming or outgoing
> messages are logged until the software is restarted.
>
> Has anyone come across a similar issue? And is there a solution for it?
> For the moment we think about just disabling the heartbeat messages
> altogether (that seems to work for now), but that it more of a hack
> workaround in my opinion and not an actual solution.
>
> Thanks for your support and regards,
> Florian
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>
>
> --
> Christoph John
> Software Engineering
> T +49 241 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users
>


-- 
Regards,

Andrew Marlow
http://www.andrewpetermarlow.co.uk