connamara / quickfixn

QuickFIX/n implements the FIX protocol on .NET.
http://quickfixn.org
Other
469 stars 557 forks source link

Unable to run multiple instances #33

Closed csswowsers closed 12 years ago

csswowsers commented 12 years ago

Is there a reason I'm unable to run multiple instances of a vb.net program with quickfix? It fails on instantiating the SocketInitiator.

gbirchmeier commented 12 years ago

That's not a lot of info to go on. Can you share what your exception message is?

Could it be that your program is conflicting over a port number or file handle or other resource?

On Tue, Jan 24, 2012 at 9:24 PM, csswowsers < reply@reply.github.com

wrote:

Is there a reason I'm unable to run multiple instances of a vb.netprogram with quickfix? It fails on instantiating the SocketInitiator.


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

csswowsers commented 12 years ago

System.InvalidOperationException was unhandled Message=An error occurred creating the form. See Exception.InnerException for details. The error is: Configuration failed: Could not open body file: C:\Projects\Oak\FIX.4.4-JCH-Oak.body

This is the exception I get when running the program from VS after running the exe from bin/debug folder.

gbirchmeier commented 12 years ago

Running two programs with the same session ID and the same config is a bad idea, for numerous reasons.

Specifically here, you're seeing this: The first process has opened that file for writing. When the second process attempts to do the same (using the same filename because it's the same session identifier), it finds that the file is locked.

If windows didn't lock that file, the two processes would keep writing and overwriting that file's content, and the internal state of those processes would get corrupted as A's write clobber B's state and vice-versa.

And what do you expect your counterparty to do? It can't take two connections with identical IDs. Each connection must have a unique ID.

Start your second instance with a different session or config and it will start up just fine.

-Grant

On Wed, Jan 25, 2012 at 7:41 AM, csswowsers < reply@reply.github.com

wrote:

System.InvalidOperationException was unhandled Message=An error occurred creating the form. See Exception.InnerException for details. The error is: Configuration failed: Could not open body file: C:\Projects\Oak\FIX.4.4-JCH-Oak.body

This is the exception I get when running the program from VS after running the exe from bin/debug folder.


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33#issuecomment-3650634

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

gbirchmeier commented 12 years ago

In the future, please ask these questions on the mailing list rather than directly to me. Thanks!

http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com

On Wed, Jan 25, 2012 at 8:54 AM, Grant Birchmeier <gbirchmeier@connamara.com

wrote:

Running two programs with the same session ID and the same config is a bad idea, for numerous reasons.

Specifically here, you're seeing this: The first process has opened that file for writing. When the second process attempts to do the same (using the same filename because it's the same session identifier), it finds that the file is locked.

If windows didn't lock that file, the two processes would keep writing and overwriting that file's content, and the internal state of those processes would get corrupted as A's write clobber B's state and vice-versa.

And what do you expect your counterparty to do? It can't take two connections with identical IDs. Each connection must have a unique ID.

Start your second instance with a different session or config and it will start up just fine.

-Grant

On Wed, Jan 25, 2012 at 7:41 AM, csswowsers < reply@reply.github.com

wrote:

System.InvalidOperationException was unhandled Message=An error occurred creating the form. See Exception.InnerException for details. The error is: Configuration failed: Could not open body file: C:\Projects\Oak\FIX.4.4-JCH-Oak.body

This is the exception I get when running the program from VS after running the exe from bin/debug folder.


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33#issuecomment-3650634

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

csswowsers commented 12 years ago

Thanks for the information - any easy way to create different session/config files dynamically in code so that this issue doesn't arise?

gbirchmeier commented 12 years ago

What exactly are you trying to do?

In my experience, any QF program I write is for a specific connection, e.g. ICE or CME. The components of a session id (sender id, target id, fix version) are usually assigned to you; you can't simply make them up on a whim.

Even if you are writing both the initiator and the acceptor, they must agree on their IDs or the acceptor will reject the initiator. Your acceptor must be configured with the session IDs that it will accept; any initiator with a different ID will be rejected.

So, yes, you could dynamically change sender id or whatnot, perhaps in response to a command-line argument, but I don't see how that would be useful.

-Grant

On Wed, Jan 25, 2012 at 2:20 PM, csswowsers < reply@reply.github.com

wrote:

Thanks for the information - any easy way to create different session/config files dynamically in code so that this issue doesn't arise?


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33#issuecomment-3658220

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

csswowsers commented 12 years ago

Understood, we are trying to up the number of accounts and systems that are traded so having multiple instances of a program would allow for more accounts. QF allows for multiple sessions but could each session have the same session id components or do they need to be unique?

gbirchmeier commented 12 years ago

Are you writing both sides (Initiator/Acceptor) then?

The limitation of QF Acceptors is that, when the Acceptor is started, it must be preconfigured with every possible session that might connect to it. What that means is that your Acceptor's config will have numerous [Session] sections in it, one for each allowed Initiator. Each of these must have a unique SessionID.

The Acceptor can not accept arbitrary Sessions, e.g. it can't accept all comers. I'm not even sure if you can dynamically create a bunch of sessions internally. The other two QF mail lists (C++/Java) get questions about this from time to time; it's just a limitation in the current design that no one has attempted to tackle.

I might have gotten a little off-topic there. The answer to your basic question is no. Each session must have a unique ID.

There are actually 7 components that make up a session ID. QF/J supports all of them. Our doc page only lists 4, but I think we support all 7 as well (I might need to update the page). http://www.quickfixj.org/quickfixj/usermanual/1.5.1/usage/configuration.html http://quickfixn.org/tutorial/configuration

So your sessions could all have the same SenderID, TargetID, and BeginString, but they'd have to have one other unique sessionID component, such as different SessionQualifiers.

-Grant

On Wed, Jan 25, 2012 at 3:16 PM, csswowsers < reply@reply.github.com

wrote:

Understood, we are trying to up the number of accounts and systems that are traded so having multiple instances of a program would allow for more accounts. QF allows for multiple sessions but could each session have the same session id components or do they need to be unique?


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33#issuecomment-3659193

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

csswowsers commented 12 years ago

I'm just writing the Initiator/Client. Connecting to brokerage who has provided SendCompID,TargetCompID,UserName,Password. My program may just be limited in the number of systems/accounts to trade performance wise which may be a reason for running multiple instances.

gbirchmeier commented 12 years ago

Has your brokerage given you multiple UserNames?

They are probably not using QF in their Acceptor. It's possible that they will allow multiple initiators to use the same session.

If you try running 2 initiators at once, I recommend you run your two instances from two different directories so that they don't clash over filehandles and such. Literally, I think you should copy your entire binary directory to another location, and run that one as your second instance. (I don't think they'll clash over using the same port number... but I kinda suck at networking details, so I could be wrong.)

-Grant

On Wed, Jan 25, 2012 at 3:34 PM, csswowsers < reply@reply.github.com

wrote:

I'm just writing the Initiator/Client. Connecting to brokerage who has provided SendCompID,TargetCompID,UserName,Password. My program may just be limited in the number of systems/accounts to trade performance wise which may be a reason for running multiple instances.


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33#issuecomment-3659526

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

csswowsers commented 12 years ago

Ok, seems like we want to connect to one brokerage with QuickFix with one instance and to another with the other instance which wouldn't even be using the QuickFix references so may be pulling out the QuickFix initializations into a button. Are the settings regarding the QuickFix logs required or is there a way to make those optional?

gbirchmeier commented 12 years ago

No, but I highly highly super crazy recommend that have your app keep fix logs. When something goes wrong, the first thing I always look at is the fix logs.

Why don't you just have two different config files and pass in the config path as a command-line argument? Each config can point to different paths.

Honestly, though, if you're connecting to two different brokerages that each have their own FIX interface, I'm gonna bet you'll have a lot of if(brokerA) / else if(brokerB) stuff in your code, because no two interfaces are ever alike in my experience. I recommend you consider just writing two different apps.

By the way, if you haven't skimmed through your counterparty's specs for their respective FIX interfaces, you should do so ASAP. Don't assume anything about their behaviors, or that the two interfaces will be similar.

On Fri, Jan 27, 2012 at 8:01 AM, csswowsers < reply@reply.github.com

wrote:

Ok, seems like we want to connect to one brokerage with QuickFix with one instance and to another with the other instance which wouldn't even be using the QuickFix references so may be pulling out the QuickFix initializations into a button. Are the settings regarding the QuickFix logs required or is there a way to make those optional?


Reply to this email directly or view it on GitHub: https://github.com/connamara/quickfixn/issues/33#issuecomment-3686974

Grant Birchmeier Connamara Systems, LLC Made-To-Measure Trading Solutions. Exactly what you need. No more. No less. http://connamara.com

gbirchmeier commented 12 years ago

Hey, I didn't realize we were discussing this as an issue in GitHub.

This is clearly not a bug. I'm going to close it.

For future followup, please join and send to the mailing list and I can continue to respond to you there. http://lists.quickfixn.com/listinfo.cgi/quickfixn-quickfixn.com

csswowsers commented 12 years ago

Thanks for the response - the other brokerage isn't using FIX at all, it uses it's own proprietary API so I think pulling out the FIX related code into a button for connecting to the counterparty using FIX should be sufficient as the other instance won't ever need any FIX initialization/code. By the way, this was implemented in vb.net with the old quickfix before quickfix/n - any advantages to switching?

gbirchmeier commented 12 years ago

Probably not, unless you really want to get off vb.net.

csswowsers commented 12 years ago

Sounds good. Main reason for using vb.net instead of c# was since connection to datafeed provider doesn't support c#. Thanks for all the help/suggestions