Re: [Quickfixj-users] Quickfix Java Throttle limit

[Christoph J. <chr...@ma...>]

Hi Vipin,

sorry, did not notice that the method is not public.
Then I guess your best bet is to use reflection to get access to the IoSession in the Responder.

Cheers,
Chris.


On 26.08.21 08:42, Vipin Chaudhary wrote:
> HI Christoph,
>
> getIoSession() method is not public and has a default access identifier. So I am not able to 
> access this method from my own class.
>
> Can we get access to IOSession in any other way? or I need to make this method public and need to 
> compile the code again(which is less preferred).
>
> What's your thoughts?
>
> 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