Menu
▾
▴
Re: [Quickfixj-users] Issues with Heartbeat When Connecting via HTTP Proxy
|
From: Christoph J. <chr...@ma...> - 2020-12-03 11:26:29
|
I would be interested in message logs from the connection establishment. Sounds a little strange to me, but I am learning something new every day. :) Cheers, Chris. On 02.12.20 19:28, Andrew Marlow wrote: > 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... <mailto: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/ <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/ >> <http://www.quickfixj.org/documentation/> >> QuickFIX/J Support: http://www.quickfixj.org/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... <mailto:Qui...@li...> >> https://lists.sourceforge.net/lists/listinfo/quickfixj-users >> <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> > > -- > Christoph John > Software Engineering > T +49 241 557080-28 > chr...@ma... <mailto:chr...@ma...> > > MACD GmbH > Oppenhoffallee 103 > 52066 Aachen, Germany > www.macd.com <http://www.macd.com> > > Amtsgericht Aachen: HRB 8151 > Ust.-Id: DE 813021663 > Geschäftsführer: George Macdonald > > _______________________________________________ > Quickfixj-users mailing list > Qui...@li... <mailto:Qui...@li...> > https://lists.sourceforge.net/lists/listinfo/quickfixj-users > <https://lists.sourceforge.net/lists/listinfo/quickfixj-users> > > > > -- > Regards, > > Andrew Marlow > http://www.andrewpetermarlow.co.uk <http://www.andrewpetermarlow.co.uk> > -- Christoph John Software Engineering T +49 241 557080-28 chr...@ma... MACD GmbH Oppenhoffallee 103 52066 Aachen, Germany www.macd.com Amtsgericht Aachen: HRB 8151 Ust.-Id: DE 813021663 Geschäftsführer: George Macdonald |
