As stated on the Listening to Session Events page, session event handling/listening is synchronous operation. For this reason, it is recommended not to perform time-consuming tasks inside event handlers. If your event handler processing time more than 0.5-1 second and you cannot decrease it by a code optimization, then it makes sense to move the processing to a separate thread. Otherwise, long processing can block the receiving thread of the session, decrease the responsiveness of the session and whole application and lead to other negative side effects. The general solution for the asynchronous processing of incoming messages is to create a separate processing thread with a thread-safe queue. In this case, the incoming message event handler only copies the incoming message and puts it to the thread-safe queue. And the processing thread gets messages from the thread-safe queue and performs all required time-consuming actions. Additionally, in such a scenario, it makes sense to use a thread-safe pool of messages objects to avoid additional memory allocations during incoming messages copying. Therefore, the workflow of an application can be the following:
And finally, we recommend taking a look at the Async Processing Sample, from the FIX Engine distribution package. It demonstrates how the asynchronous processing of incoming messages can be designed. It uses our simple threading components (thread-safe queue, thread-safe pool, etc.). Please note that these threading components serve for demonstrating and are not designed for all real cases, so please feel free to use your threading components.
