Re: [Quickfixj-users] Quickfix Java Throttle limit

[Vipin C. <vip...@gm...>]

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...>
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...> 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,
>>
>> 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
>> 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 557...@ma...
>
> MACD GmbH
> Oppenhoffallee 103
> 52066 Aachen, Germanywww.macd.com
>
> Amtsgericht Aachen: HRB 8151
> Ust.-Id: DE 813021663
> Geschäftsführer: George Macdonald
>
>