[Quickfix-users] Multiple Sessions In Application , Multple Applications in Service....

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi All;

(This is  a bit of a long question, sorry)
Using QuickFix  1.13.3 Built for Windows x64  on visual studio 2008
I have encountered the following situation:
I created a Service with 2 FIX Sessions configured in one Fix Application to 2 different target IP addresses (say TargetAAAA and TargetBBBB) , and everything  works great, went to production, accolades followed, etc. etc.
Then, I received a new workstation, and the IT guys forgot to add the firewall rule to allow connecting to  TargetBBBB from my computer. The other one, TargetAAAA , was opened.
At this point, what I observed was that QuickFix was unable to connect to *either* session, because of the inability to connect to the blocked IP.

Here's what I see in event_log

2013-12-19 18:28:53.037                FIX.4.4 SENDERBBBB     TARGETBBBB     Connecting to BBB.BB.BBB.BBB on port 563
2013-12-19 18:28:53.030                FIX.4.2 SENDERAAAA    TARGETAAAA    Connecting to AAA.AA.AAA.AAA on port 444
2013-12-19 18:28:14.043                FIX.4.2 SENDERAAAA    TARGETAAAA    Disconnecting
2013-12-19 18:28:14.040                FIX.4.2 SENDERAAAA    TARGETAAAA    Socket Error: An existing connection was forcibly closed by the remote host.
2013-12-19 18:28:14.037                FIX.4.2 SENDERAAAA    TARGETAAAA    Initiated logon request
2013-12-19 18:27:53.017                FIX.4.4 SENDERBBBB     TARGETBBBB     Connecting to BBB.BB.BBB.BBB on port 563
2013-12-19 18:27:53.007                FIX.4.2 SENDERAAAA    TARGETAAAA    Connecting to AAA.AA.AAA.AAA on port 444
2013-12-19 18:27:24.990                FIX.4.2 SENDERAAAA    TARGETAAAA    Disconnecting
2013-12-19 18:27:24.987                FIX.4.2 SENDERAAAA    TARGETAAAA    Timed out waiting for logon response
2013-12-19 18:27:14.997                FIX.4.2 SENDERAAAA    TARGETAAAA    Initiated logon request
2013-12-19 18:26:53.980                FIX.4.4 SENDERBBBB     TARGETBBBB     Connecting to BBB.BB.BBB.BBB on port 563
2013-12-19 18:26:53.967                FIX.4.2 SENDERAAAA    TARGETAAAA    Connecting to AAA.AA.AAA.AAA on port 444
2013-12-19 18:26:14.943                FIX.4.2 SENDERAAAA    TARGETAAAA    Disconnecting
2013-12-19 18:26:14.940                FIX.4.2 SENDERAAAA    TARGETAAAA    Timed out waiting for logon response
2013-12-19 18:25:53.943                FIX.4.4 SENDERBBBB     TARGETBBBB     Connecting to BBB.BB.BBB.BBB on port 563
2013-12-19 18:25:52.973                FIX.4.2 SENDERAAAA    TARGETAAAA    Initiated logon request
2013-12-19 18:25:31.937                FIX.4.4 SENDERBBBB     TARGETBBBB     Connecting to BBB.BB.BBB.BBB on port 563
2013-12-19 18:25:31.927                FIX.4.2 SENDERAAAA    TARGETAAAA    Connecting to AAA.AA.AAA.AAA on port 444
2013-12-19 18:25:31.907                FIX.4.4 SENDERBBBB     TARGETBBBB     Created session
2013-12-19 18:25:31.730                FIX.4.2 SENDERAAAA    TARGETAAAA    Created session

So it seems from this, that the blocked connection to TARGETBBBB is causing interference with TARGETAAAA's connection/login

To prove that this is related, when I remove the TARGETBBBB session from the config , everything is good again.
2013-12-19 18:34:00.027                FIX.4.2 SENDERAAAA    TARGETAAAA    Received logon response
2013-12-19 18:34:00.027                FIX.4.2 SENDERAAAA    TARGETAAAA    Logon contains ResetSeqNumFlag=Y, reseting sequence numbers to 1
2013-12-19 18:33:59.777                FIX.4.2 SENDERAAAA    TARGETAAAA    Initiated logon request
2013-12-19 18:33:59.743                FIX.4.2 SENDERAAAA    TARGETAAAA    Connecting to AAA.AA.AAA.AAA on port 444
2013-12-19 18:33:59.057                FIX.4.2 SENDERAAAA    TARGETAAAA    Logon state is not valid for message
2013-12-19 18:33:59.043                FIX.4.2 SENDERAAAA    TARGETAAAA    Disconnecting
2013-12-19 18:33:59.040                FIX.4.2 SENDERAAAA    TARGETAAAA    MsgSeqNum too low, expecting 5247 but received 1
2013-12-19 18:33:58.357                FIX.4.2 SENDERAAAA    TARGETAAAA    Disconnecting
2013-12-19 18:33:58.357                FIX.4.2 SENDERAAAA    TARGETAAAA    Sending logout response
2013-12-19 18:33:58.340                FIX.4.2 SENDERAAAA    TARGETAAAA    Received logout request
2013-12-19 18:33:58.800                FIX.4.2 SENDERAAAA    TARGETAAAA    Initiated logon request
2013-12-19 18:33:58.747                FIX.4.2 SENDERAAAA    TARGETAAAA    Connecting to AAA.AA.AAA.AAA on port 444
2013-12-19 18:33:58.737                FIX.4.2 SENDERAAAA    TARGETAAAA    Created session

So, question 1 is, Is this behavior expected, or a bug?
And here's my second question, which is shorter, but much more urgent in my case:
Either way (expected or not),  I see that if I have my service create 2 different Fix Applications for the 2 connections, rather than one Application with 2 Sessions, I do not see this behavior.  This leads me to the conclusion that I'm better off changing my service to create a separate FIX application for each Connection , to avoid this possibility.
What are the advantages and drawbacks to configuring every connection as a separate application, rather than separate sessions within one Application? Is there a de facto standard/preferred  way to set this up?

Many thanks to those with the patience to read to the end...
JS

Jonathan Steinberg
Systems Developer
Jefferies LLC

Jefferies archives and monitors outgoing and incoming e-mail. The contents of this email, including any attachments, are confidential to the ordinary user of the email address to which it was addressed. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. This email may be produced at the request of regulators or in connection with civil litigation. Jefferies accepts no liability for any errors or omissions arising as a result of transmission. Use by other than intended recipients is prohibited. In the United Kingdom, Jefferies operates as Jefferies International Limited; registered in England: no. 1978621; registered office: Vintners Place, 68 Upper Thames Street, London EC4V 3BJ. Jefferies International Limited is authorized and regulated by the Financial Conduct Authority.