I totally agree with Asankha to take a similar approach like JMS
connection pools. Even FIX transport does the same to create the
***Initiator*** session(s) by starting the FIX engine inside
'startListerningForServices' method in the FIX transport listener. So
if we start the ***Acceptor** *FIX Engine by providing the session(s)
info at the same level we will solving our problem. when message
transports it will check the availability of the session and if exists
use the session and dispatch the message else create a new session (as
it is now) .
Asanka A.
Asankha C. Perera wrote:
Asanka
Primary reason is that and I can add few more use cases
1. Acceptor can send messages for a specific session before sending
messages from the initiator (fills, corrections and acknowledgments
for the previously posted transactions).
2. FIX recovery happens with the session creation, so with the
current implementation recovery has to wait till the first message
sends.
Around how many of these "sessions" will a typical usecase have? in
the order of services deployed, or a small fixed number - like the JMS
connection factories? If this is a small fixed number, you could
define this similarly to the way the JMS sender defines connection pools
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
