QuickFIX处理修复消息的线程数

Question

I notice in the code fragment below that in QuickFIX, the threadID is always always the same in that whatever thread id fromApp outputs equals the thread id of MarketDataIncrementalRefresh . But I also notice that the threads from invocation of fromApp to another fromApp can vary, meaning that QuickFIX is throwing the message onto a different (threadpool?) thread.

My questions are, (all more or less related)

1. If I don't get off the thread, am I blocking QF from grabbing another message?
2. Is there a parameter that allows me to control how many threads QF uses to manage incoming messages?
3. It seems that if this "number of threads to use" value is high enough, then there is no reason to handle (parse etc) the message received in one the virtual methods, eg, MarketDataIncrementalRefresh in yet another thread?

---

void MyApplication::fromApp( const FIX::Message& message, const` FIX::SessionID& sessionID )
    throw( /*FIX::FieldNotFound,*/ FIX::IncorrectDataFormat, FIX::IncorrectTagValue, FIX::UnsupportedMessageType )
    {
        //std::cout << std::endl << "IN: " << message << "\n";

        try
        {
            std::cout << "fromApp " << std::this_thread::get_id() << '\n';
            crack( message, sessionID );
        }
        catch(std::exception& ex)
        {
            std::cout << "crack exception: " << ex.what() << "\n";
        }
    }

void MyApplication::onMessage
    (const FIX44::MarketDataIncrementalRefresh& message, const FIX::SessionID& fsid)
    {
        std::cout << "MarketDataIncrementalRefresh " << std::this_thread::get_id() << '\n';
    }

Answer 1

It appears that there are two ways to instantiate an Initiator:

FIX::SocketInitiator initiator( application, storeFactory, settings);

or

FIX::ThreadedSocketInitiator initiator( application, storeFactory, settings);

But this appears to handle the case where one thread handles multiple sessions or several threads handle different sessions. My question has to do with if the thread that cracks the message and the thread that handles the communications/receiving of the message are the same in these QF threading models. So not quite the same thing I think. In other words, once the message has traveled further into the application.

I have also seen code like this:

new SocketAcceptor(3, new ThreadPoolExecutor(3, 3, 1000, TimeUnit.SECONDS, new ArrayBlockingQueue<Runnable>(1000)));