RE: [Quickfix-developers] ThreadedSocketInitiator vs SocketInitiator

[Ajay K. <Aja...@tr...>]

One useful property of QuickFIX's current processing of outbound
messages is that the application can rely upon the knowledge that the
message has been written written to the message store to the socket and
by the time send() returns. This makes it relatively simple to make sure
all messages that the application thinks it has sent successfully will
get to the counterparty.

If an intermediate queue is introduced between the application and the
processing of the message within the FIX engine, then depending upon
whether the queue is introduced before QF writes to the message store or
after, there might be a need to invent additional mechanisms to allow
the application to be informed when a message gets persisted so that it
can track the message's progress through the engine. Otherwise messages
that the application thought it had sent might still be waiting to be
processed by a worker thread in an in-memory queue and might be lost in
case of an engine failover.

- Ajay

-----Original Message-----
From: Sean Kirkpatrick [mailto:sea...@pi...]=20
Sent: Tuesday, May 30, 2006 8:58 AM
To: Steve Bate
Cc: quickfix-developers
Subject: RE: [Quickfix-developers] ThreadedSocketInitiator vs
SocketInitiator


QuickFIX Documentation:
http://www.quickfixengine.org/quickfix/doc/html/index.html
QuickFIX Support: http://www.quickfixengine.org/services.html

Hi Steve,

I understand your concerns.  Guaranteeing message sequencing for a
session becomes more complicated with a thread pool and message queue.
Each session would need some kind of locking mechanism (a mutex would do
the trick), that could be locked when a worker thread is processing the
session's message queue.  My thoughts were that it would be useful to
have a set of incoming worker threads and outgoing worker threads.  Each
session could then have both an incoming and outgoing queue for messages
that would be processed the same way.  That way, any outgoing messages
(even those sent from callback functions) would be written to the
outgoing queue and picked up by a worker thread when all prior outgoing
messages have been sent.  This would hopefully eliminate the possibility
of deadlocks.  It's just very important not to starve any of the
sessions while processing a queue for a very busy connection...

Anyone have additional thoughts / comments / concerns?

--Sean

-------------------------------------------------------------------------=
--

The information in this email is confidential and may be legally =
privileged.
It is intended solely for the addressee. Access to this email by anyone =
else
is unauthorized. If you are not the intended recipient, any disclosure, =
copying,
distribution or any action taken or omitted to be taken in reliance on =
it, is
prohibited and may be unlawful.

TradeWeb reserves the right to monitor and review the content of all =
messages sent
to or from this e-mail address. Messages sent to or from this e-mail =
address may
be stored on the TradeWeb e-mail system.