[ts-gen] cross session orders, client ids

[Nils Gebhardt]

-------- Forwarded Message --------
From: Nils Gebhardt <mail at ngebhardt.de>
To: pippin at owlriver.net
Subject: Re: cross session orders, client ids
Date: Sat, 06 Dec 2008 17:19:24 +0100


Bill, 


On Thu, 2008-12-04 at 14:10 -0500, pippin at owlriver.net wrote:

>[...] 
> 

Thanks for your explanations. 

> 
> ...  The kill.rb script runs with the "once" option, to ensure that
> both connections to the tws run with a predictable clientid, here the
> starting value of 8.  


ok - 'once' confines shim to id 8? Probably it is fine in most cases to
work with id 8, just for completeness: is it possible to specify the
client id before tws handshake in a more general way?

There seem to be problems with client id 8: after submitting an order, using id 8, 
I get the following strange behavior: 


[20:47:47][~/T/TEST/shim-081121]
n at gb07:$ ./shim --data

          The trading shim has connected to the database server
          and loaded 51649 products; connected to the IB tws as
          client id  1; and queried for the account code, which
          seems to be DU33186.  Program initialization has been
          completed.



[20:48:05][~/T/TEST/shim-081121]
n at gb07:$ ./shim --risk

          The trading shim has connected to the database server
          and loaded 51649 products; connected to the IB tws as
          client id  8; 
Problem: 524 could not obtain IB account info at startup
Exiting

-------%------

so any further actions in risk mode are broken. If I can collect any further informations on the circumstances, 
I will post it. 

[...]
> Now, preliminaries done, the essence of your question about concurrent
> order management:

> 
> If you have some application in mind that involves concurrent order
> processing of shared orders by distinct processes, please feel free
> to describe it to the list.  I suspect that, given such a use case,
> it would make sense to merge the heavyweight processes to threads in
> a single ruby script with a single shim subprocess, where each ruby
> thread shared access to the shim via locks on a containing class for
> the shim stdin.

I don't see any need for concurrent order processing. If consecutive
access works, that is great. 


Thanks

Nils