Re: [Quickfixj-users] How to quickly terminate FIX event loop

[Colin D. <co...@ma...>]

The way we handle such things are that we have a definitive way to 
indicate that a particular message has been processed. For example, if a 
row in table x exists, then the message with seq num y was processed. On 
start, we look for the row in table x that has the highest sequence 
number. That's the most recent message that we're sure we've processed. 
We set the session sequence numbers to match this row, after the session 
is created and before it is started. You must have the means to handle 
duplicate messages, though, since the process must allow for the fact 
that a particular message might have been processed all the way until 
the final step, create the row in table x. Also, if you process some 
messages in parallel, you must consider that there may be gaps in the 
sequence numbers in table x.

As for stopping processing, we would just end the session with 
Session.disconnect. Given that we restart the session where we want it 
to start, compelling the counter to resend some messages, we don't 
really worry about ending a session immediately. Use your flag to 
determine whether you should process messages or not. That way, the 
session can continue for a few seconds after you want it to end and 
you'll just drop those messages, knowing you'll get them back on restart.

This approach doesn't require and config changes. On restart, the system 
will automatically orient itself and restart where it's supposed to.

On 3/26/21 6:36 AM, Andrew Marlow wrote:
> QuickFIX/J Documentation: http://www.quickfixj.org/documentation/
> QuickFIX/J Support: http://www.quickfixj.org/support/
>
>
>
> Hello everyone,
>
> Please excuse my ignorance regarding FIX programming. I know that when 
> a FIX session is initiated a thread runs asynchronously, dispatching 
> callbacks until the main application terminates. But I need a way to 
> shutdown that thread as soon as I detect a particular error. My 
> message handler which contains the callbacks has a state variable that 
> can be queried by the main app. The main app has a polling loop rather 
> than sleeping forever. That loop enables it to periodically check the 
> state of the message handler. If it has got into a bad state then the 
> main app shuts down. The trouble with this is that there is a window 
> during which any number of FIX messages may be received. This is 
> causing trouble. Those messages do not get replayed when the app is 
> restarted because the remote FIX end thinks that because they were 
> picked up they do not need to be replayed.
>
> I am able to jig things such that old messages can be seen again. I 
> have a config parameter datetime for subscription. On restart I can 
> set this back in time. There also the sequence numbers, another aspect 
> controlled by configuration. While this worked fine during development 
> it is no good for production. This is because any config change in 
> production requires people to jump through hoops of fire. So I need to 
> find a better way, that causes the FIX processing to cease as soon as 
> the error is detected. Any ideas? Other than calling sys.exit(1) of 
> course. That would be a bit like stopping your car by driving it 
> straight into a brick wall, rather than taking your foot off the gas 
> and applying the brake in the traditional way. :-)
>
> -- 
> Regards,
>
> Andrew Marlow
> http://www.andrewpetermarlow.co.uk <http://www.andrewpetermarlow.co.uk>
>
>
>
> _______________________________________________
> Quickfixj-users mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfixj-users

-- 
Colin DuPlantis
Chief Architect, Marketcetera
Download, Run, Trade
888.868.4884
https://www.marketcetera.com