Closed csswowsers closed 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
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.
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
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
Thanks for the information - any easy way to create different session/config files dynamically in code so that this issue doesn't arise?
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
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?
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
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.
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
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?
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
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
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?
Probably not, unless you really want to get off vb.net.
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
Is there a reason I'm unable to run multiple instances of a vb.net program with quickfix? It fails on instantiating the SocketInitiator.