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: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…
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.
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.