Also interested. By the way, I like the case that on one single machine, I can monitor real-time streaming for multiple symbols ( for example, 10 symbols) at the same time.
(a) I understand that one account (for example, paper trading or real account), one can monitor one real-time data.
(b)
?It is possible to have multiple TWS instances running on the same computer if each is configured with a different API socket port number. Also, each TWS session can receive up to?32 different client applications?simultaneously

?

------
seems the only way I can do this is: every time, I disconnect one real-time live stream of one symbol, then go to next symbol.
Best and thanks,

The precise TWS API requirement is that order IDs for new orders shall be "greater than all previous order IDs returned to the client application in openOrder or orderStatus callbacks".

Your nextOrderId method does seem to generate a sequence of increasing numbers, but here a few thoughts:

• I would remove all strategy related aspects from nextOrderId and make it a simple thread-safe incrementing function. And since thread locks are expensive, I'd look for the equivalent in Python to the Java lock-free AtomicInteger. I am not a Python practitioner, but the "atomics" package seems to provides that.
• You need to make sure that the sequence of orderIds is still "Strictly Monotonically Increasing" when your strategies call placeOrder(). What I mean is that you need to avoid situations where a first strategy gets an orderId but does not get to call placeOrder() for a while. In the mean time a second strategy gets a higher nextOrderId and calls placeOrder() before the first strategy can. So you need a lock around the entire sequence of code from where the strategies make Order objects, call nextOrderId() and until all placeOrder() calls are done.

That should suffice to avoid the duplicate orderId issue in multi-threaded order placement scenarios.

But to be absolutely sure, you also want to monitor the orderIds you receive from openOrder() and orderStatus() callbacks and make sure to nudge the counter in nextOrderId() in case you receive orderIds that are higher than the counter in nextOrderId(). That can happen in cases where your client application gets exposed to orders that where placed by other clients or from within TWS or other tools,

闯ü谤驳别苍

?

?

On Sat, Mar 15, 2025 at 12:32 PM, Marco wrote:

Hi All,

I have an issue with orderId assignment. I have a python code where the client is a class and assign orderId to different strategies running in parallel (each strategy implemented in a separate class). When a strategy has to generate an order, it request?the order id calling client member function nextOrderId(). In order to avoid assigning the same id do different strategies I implemented this function as below:

?

?# return next available order id

? ? def nextOrderId(self,stratId):

?

? ? ? ? #locking the assignment and increase of order id to avoid same order id assigned to different strategies

? ? ? ? with self.lockOrderIdIncrease:

? ? ? ? ? ? self.strategyList[stratId].validOrderId = self.order_id

? ? ? ? ? ? self.order_id += 1

? ? ? ? return self.strategyList[stratId].validOrderId

?

where self.lockOrderIdIncrease is a threading Lock object, initialized in the constructor class:

?

self.lockOrderIdIncrease = Lock()

?

and self.strategyList is a list that for each strategy stores the current used order id, while self.order_id contains the last available order id

?

iI have a couple of strategies that can be activated in the same instant and in paper trading in past days I observed 2 times the error “Error 103: Duplicate order id”. Can someone help me? I do not understand why this is happening as the fragment accessing to the current order Id seems to me allowing access to one thread per time, blocking the others

?

thank you in advance

Marco

?

?

Hard to say what is going on, Renato.

While IBGW does not implement fancy forms and complex media content (compared to TWS), it still needs a complete and pretty sophisticated graphics subsystem for JavaFX 2.0 to work properly. And mot likely a window manager as well. I have been using Xtigervnc with Xfce4 on Ubuntu for years and it works great. But I don't use Docker containers.

And you might want to get this working manually before you start IBGW with IBC since IBC will not be able to help you if the root cause relates to the graphics subsystem or X11 window management.

闯ü谤驳别苍

On Sat, Mar 15, 2025 at 12:07 PM, Renato Votto wrote:

..

Thank you for your help, much appreciated.

If I cannot come up with a solution shortly, I'll give up and just go with IBC. Though I liked the portable container implementation, the minimal settings and the only need to delegate to a cron task for the weekly re-authentication.

By the way, here's the container source, if anyone wants to play with it (originally forked by Ryan Clouser similar concept):

?

Renato

Ok, here's a (hopefully) good development: I just casually let a container displaying on the X server run on my local machine, went away, the machine went in standby and:

?

Excatly the same log messages and apparently the same window popping up!

So it all seems due to a lost internet connection and having to confirm a re-login request..

I wonder what's the equivalent of the standby causing the disconnection on my local machine is on the remote server, but that can easily be found out,a nd I have a problem to solve now.

If this is now sorted, I hope it'll be useful for someone ending up in the same trap.

Thank you 闯ü谤驳别苍 for the quick help.

?

Renato

Hi All,

I have an issue with orderId assignment. I have a python code where the client is a class and assign orderId to different strategies running in parallel (each strategy implemented in a separate class). When a strategy has to generate an order, it request?the order id calling client member function nextOrderId(). In order to avoid assigning the same id do different strategies I implemented this function as below:

?

?# return next available order id

? ? def nextOrderId(self,stratId):

?

? ? ? ? #locking the assignment and increase of order id to avoid same order id assigned to different strategies

? ? ? ? with self.lockOrderIdIncrease:

? ? ? ? ? ? self.strategyList[stratId].validOrderId = self.order_id

? ? ? ? ? ? self.order_id += 1

? ? ? ? return self.strategyList[stratId].validOrderId

?

where self.lockOrderIdIncrease is a threading Lock object, initialized in the constructor class:

?

self.lockOrderIdIncrease = Lock()

?

and self.strategyList is a list that for each strategy stores the current used order id, while self.order_id contains the last available order id

?

iI have a couple of strategies that can be activated in the same instant and in paper trading in past days I observed 2 times the error “Error 103: Duplicate order id”. Can someone help me? I do not understand why this is happening as the fragment accessing to the current order Id seems to me allowing access to one thread per time, blocking the others

?

thank you in advance

Marco

?

?

..

Hi,

My first post here and I hope I'm posting in the right way and place.

Context:
- I have a Docker container running an instance of the Interactive Brokers Gateway, paper trading account, on a remote Linux server
- The IB Gateway is set to auto-restart every day at 8:30 AM GMT

- I use Xvfb, a virtual display, so I have no physical graphic interface whilst running

- I am currently solely testing the daily auto-restart, thus the app has no clients connected and no requests whatsoever submitted

My problem is that so far, it never made it to a second restart: I may start the container today, that will successfully (reading the logs and experiencing the "another session is running..." warnings both on my phone or local instance of IB Gateway/TWS) launch and run IB Gateway, it will make it to the following day restart and succede (judging again from logs and trying to login from somewhere else); however, the second day auto-restart always fails. Worth to clarify that the failing restart is not on a Saturday/Sunday, which I'm aware is expected to require authentication again.

What I can see in the launcher.log of a succesfull restart as opposed to the one of the failing restart is that the latter, at some point after the message

?

"SPLASH Authenticating"

?

reads

?

"COMPETE: session kicked out"

?

and few milliseconds after

?

"Disconnect all farms due to competing session [control=false,context=]."

?

and then after a few (just number after SPLASH ending differently)

"SPLASH 20001 step 2 AuthDispatcher.processDataItr"

"Received NS_TEST_REQUEST"

....

?

i get a

?

"Socket for connection cdc1.ibllc.com:4001 (SSL) was closed by peer."

"Listener thread terminating [sessionID=2] [seen=399,totalShifted=399,moreAvailable=0]"

"Disconnecting cdc1.ibllc.com:4001 (SSL) [disconnectDetails=DisconnectDetails[sessionID=2,endPoint=cdc1.ibllc.com:4001 (SSL),reason=DISCONNECT_ON_BROKEN_SOCKET,cause=null,systemMessage=recv: EOF,keepSocketOpen=false]]..."

"Socket closed."

then

?

"SPLASH Attempt 1: server error, will retry in seconds"

?

And after this the whole log, for hours will repeat everything again and again with just increasing the attempt number in the following message

?

"SPLASH Attempt 2: connecting to server"

In a successful restart log, right after the first message listed above, things would have taken a different fold, the authentication would succede, and some routing tasks before rotating to the operational log would be printed.

To be frank, I do have a X server option when for when I test locally on my machine where I built the Doicker image, but I never tested?for days the behaviour to see what might pop up. I did test few restarts in a row by just changing the restart time on the go, and they all succeded, but I understand many things change between the two setups, so this might be of little help.

Anyone care to help with what's going on here?
I surely can provide the logs if needed.

Thank you,

Renato?

?