{{Quickfixn}} How you guys handle the case when the initiator is not able to keep up with the load

[Artur Pietrzyk]

Thanks!

Sent from my iPhone

> On 15 Jan 2021, at 17:25, Grant Birchmeier <gbirchmeier at connamara.com> wrote:
> 
> 
> In a decade of supporting QF, I've never heard of a problem quite like this.  It sounds like you are attempting to treat the symptom, and not the cause.
> 
> Is it possible that your app is just subscribing to too much at once?  How can you be receiving such a massive blast of info at a constantly high rate that your worker thread can't keep up?  That sounds like an insane amount of data (or a really underpowered machine).
> 
> It's hard to give helpful suggestions without knowing more about your counterparty's API, but I wonder if there's an opportunity to split your app into multiple programs, each subscribing to a subset of the data.
> 
>> On Fri, Jan 15, 2021 at 10:12 AM Lanfranco Morini <Lanfranco.Morini at cegeka.it> wrote:
>> Hi Artur,
>> 
>>  
>> 
>> there is a way to disconnect the client with an error? (queue too high)
>> You can send a LOGOUT message (35=5 writing in tag 58 the logout motication (e.g. queue too high) and the close the physical connection without waiting for a response
>> (b) there are any other methods of handling that case?
>> 
>>                 b.     if you mean “that case” = “logout with a specific motivation”, I’m going to say no… but you can choose and share an alternative “custom” method with your counterparty…
>> 
>>  
>> 
>> Hope this can helps
>> 
>> Best
>> 
>> Lanfranco
>> 
>>  
>> 
>> From: Quickfixn <quickfixn-bounces at lists.quickfixn.com> On Behalf Of Artur Pietrzyk
>> Sent: venerdì 15 gennaio 2021 13:45
>> To: quickfixn at lists.quickfixn.com
>> Subject: {{Quickfixn}} How you guys handle the case when the initiator is not able to keep up with the load
>> 
>>  
>> 
>> Hi,
>> 
>>  
>> 
>> If someone will share, I would like to know what is the best case to handle a slow initiator that is not able to keep up with the load.
>> 
>>  
>> 
>> We are currently pushing those messages for a session queue, but eventually want to disconnect the client if the queue is too high, this is where we experience issue as it looks like the QuickFix does not have that option to disconnect the client, let me know if I'm wrong.
>> 
>>  
>> 
>> Another option looks like dropping the message for sending and storing for resend request, however, it still will require disconnecting the client at some point when the storage size for the session will be too high.
>> 
>>  
>> 
>> Basically:
>> 
>>  (a) there is a way to disconnect the client with an error? (queue too high)
>> 
>>  (b) there are any other methods of handling that case?
>> 
>>  
>> 
>> I look forward to hearing from the group.
>> 
>>  
>> 
>> Artur Pietrzyk
>> CEO and Founder
>> www.coinapi.io
>> 
>> <image002.gif>
>> 
>> _______________________________________________
>> Quickfixn mailing list
>> Quickfixn at lists.quickfixn.com
>> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
> 
> 
> -- 
> Grant Birchmeier
> Connamara Systems, LLC
> Made-To-Measure Trading Solutions.
> Exactly what you need. No more. No less.
> http://connamara.com
> 
> This email, along with any attachments, is confidential. If you believe you received this message in error, please contact the sender immediately and delete all copies of the message. Thank you from Connamara Systems, LLC._______________________________________________
> Quickfixn mailing list
> Quickfixn at lists.quickfixn.com
> http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20210115/85f0853f/attachment.htm>