As stated on the Subscribing to Session Events page, session event handling is a 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:

• Prepare a pool of Message object in advance during an application initialization (perform all necessary memory allocations).
• When an inbound event is invoked take an object from the pool (no memory allocation).
• Copy the incoming Message object to the Message object taken from the pool (no memory allocation just copying).
• Enqueue the copied Message object to a shared queue.
• In the processing thread, get the Message object from the shared queue.
• Process the Message object and return the processed object to the pool.

And finally, we recommend taking a look at the AsyncProcessing sample, from the FIX Engine distribution package. It demonstrates how the asynchronous processing of incoming messages can be designed.