Unable to run multiple instances about quickfixn HOT 16 CLOSED

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 <
[email protected]

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:
#33

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

from quickfixn.

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.

from quickfixn.

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 <
[email protected]

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:
#33 (comment)

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

from quickfixn.

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 <[email protected]

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 <
[email protected]

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:
#33 (comment)

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

from quickfixn.

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

from quickfixn.

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 <
[email protected]

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:
#33 (comment)

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

from quickfixn.

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?

from quickfixn.

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 <
[email protected]

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:
#33 (comment)

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

from quickfixn.

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.

from quickfixn.

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 <
[email protected]

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:
#33 (comment)

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

from quickfixn.

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?

from quickfixn.

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 <
[email protected]

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:
#33 (comment)

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

from quickfixn.

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

from quickfixn.

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?

from quickfixn.

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

from quickfixn.

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

from quickfixn.