Multiple Sessions In Application , Multple Applications in Service....

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Multiple Sessions In Application , Multple Applications in Service....

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


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.

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
Quickfix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-users
Reply | Threaded
Open this post in threaded view
|

Re: Multiple Sessions In Application , Multple Applications in Service....

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


In the past, I've seen the exact behavior you describe.  I.e., one unreachable address screws up every other connection.  Feels like a bug to me, but never investigated further.

Regarding one app for all sessions vs one app per session -- this bug aside -- it really comes down to what makes sense in your app.  For example, if you want to do different logic based on which session it is, separate apps makes sense -- no need for an 'if (sessionId == ...)' statement in each onMessage callback.


------------------------------------------------------------------------------
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
_______________________________________________
Quickfix-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quickfix-users