Re: [Quickfix-developers] QuickFIX's threading model and multiplexing other sources of events

[K. F. <kfr...@gm...>]

Hi Mike!

Thanks for the explanation.

On Fri, Feb 1, 2013 at 8:26 AM, Mike Gatny <mg...@co...> wrote:
> If using SocketAcceptor/Initiator, QF will process messages for all Sessions
> on a single thread.  QF starts this thread, and all callbacks (e.g. fromApp)
> occur on it.

Thank you.  That answers my main question.

> Return from callbacks as soon as possible to prevent backing
> up QF's queue of incoming msgs.  Copy messages to your own work/event queue
> if necessary.

Yes, that makes good sense.

> ThreadedSocketAcceptor/Initiator use one thread per Session.  This can
> increase throughput if 1) you have multiple sessions and 2) you don't share
> (much) data between them.

I have a follow-up question:

I've built a little test app (that appears to work) that is based closely
on the ordermatch example.  When I launch it, windows task manager
shows it starting out with three threads, then, after half a minute, going
up to six threads, and then after an additional minute-plus, settling
back down to three threads.

I haven't drilled down into the code to see what is happening, but I
do note the I am using SocketAcceptor, as does ordermatch (rather
than ThreadedSocketAcceptor).  (Both the ordermatch example and
my test app are acceptors.)  I have my test app configured for two
sessions.

So I don't understand the thread count.  If I follow what you are saying,
I would expect two threads: one for the main thread (the while loop
that reads the console) and one for the SocketAcceptor.

I suppose if I were using ThreadedSocketAcceptor, I would expect
three threads: one main thread, and two more, one for each of my
two sessions.

But I certainly don't understand why the thread count goes up and
back down again.

Any further insight would be appreciated.


Best regards.


K. Frank