|
From: Christoph J. <chr...@ma...> - 2021-08-02 12:08:27
|
Hi Vipin, messages are sent on the thread that calls Session.sendToTarget() or sendRaw() respectively, i.e. this will probably be a thread from your application. Received messages are pushed by the EventHandlingStrategy (either single threaded or thread-per-Session) into a queue where it is either picked up by a single thread or a thread per Session. So I cannot see where incoming Heartbeats should be affected by outgoing messages. But you even said that you could not see Heartbeats in the log when the timeout occured. So the most probable reason is that there really were no Heartbeats received. Probably the underlying connection timed out. Cheers, Chris. On 01.08.21 10:13, Vipin Chaudhary wrote: > Hi Christoph, > > We don't see any heartbeat in incoming log. > My confusion is, do the same thread read and write the messages? Like if the same thread is used > for reading and writing messages then how quickfixj behaves when the thread is waiting for writing. > > Thanks > Vipin > > On Sun, Aug 1, 2021 at 3:42 AM Christoph John <chr...@ma... > <mailto:chr...@ma...>> wrote: > > Hi Vipin, > > you can track the number of scheduled write requests by getting the Responder of a Session via > Session.getResponder(). Then you can do: > ((IoSessionResponder)responder).getIoSession().getScheduledWriteMessages() > > In theory you could monitor that and throttle something in your application. I've never tried > it but it could work. > > W.r.t. point 3: two minutes sounds like a long timeout to me. However, the sending should be > decoupled from the receiving side. Do you have a log where you can see heartbeats coming in > and get a timeout anyway? > > Cheers, > Chris. > > > On 30.07.21 10:27, Vipin Chaudhary wrote: >> Hi Team, >> >> I have three specific questions regarding throttling QuickFIxj. >> >> 1. Is there a way so that if we use the "MaxScheduledWriteRequests" option and if that value >> is reached then instead of disconnecting, Quickfixj will wait for clearing the Queue. >> 2. Is there any hook where we can track the size of WriteRequestQueue ? >> 3. If I use "SocketSynchronousWrite" with "ThreadedSocketAcceptor" and 2 minute timeout, >> Lets say my writing thread is waiting for write to complete. So during write time would I >> will be able to receive heartbeat/message from my counter party ? I have seen >> "Disconnecting: Timed out waiting for heartbeat " . Is is because my thread is waiting >> for write to complete and not able to receive heartbeat message ? >> >> >> Thanks >> Vipin >> >> On Tue, Jul 27, 2021 at 4:20 AM 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, >> >> please always reply to the group. Other users might have the same problem/question now or >> in the future. >> >> For incoming messages you can pass a high and a low watermark queue limit when >> constructing your >> connector. >> If the high limit is reached the reads from the socket will be suspended and if the low >> limit is >> reached, reads from the socket will be resumed. Of course if the socket buffer will >> overflow the >> connection could be terminated. >> >> Example: >> ThreadedSocketAcceptor.newBuilder() >> .withApplication( acceptorApplication ) >> .withMessageStoreFactory( messageStoreFactory ) >> .withSettings( settings ) >> .withLogFactory( fileLog ) >> .withMessageFactory( messageFactory ) >> .withQueueWatermarks( LOW_WATERMARK, HIGH_WATERMARK ).build(); >> >> For outgoing messages there is the setting MaxScheduledWriteRequests. >> https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html >> <https://www.quickfixj.org/usermanual/2.3.0/usage/configuration.html> >> If there are more than the configured write requests, the session is disconnected. So >> this is no >> real throttling per se but does the trick in most cases. >> >> Cheers, >> Chris. >> > > -- > 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 > -- 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 |