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

[Grant Birchmeier]

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,
>
>
>
>    1. there is a way to disconnect the client with an error? (queue too
>    high)
>       1. 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
>
> _______________________________________________
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20210115/11709ef6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.gif
Type: image/gif
Size: 42 bytes
Desc: not available
URL: <http://lists.quickfixn.com/pipermail/quickfixn-quickfixn.com/attachments/20210115/11709ef6/attachment-0002.gif>