I agree with @fordfrog. The stop-limit order is probably the best fit for what you want to do. If you have not done so yet, you can read up on a lot of the fine print at or browse details of all order types and algos at

There are other options as well, such as the a conditional order as @John suggested. When we design order constructs for an instrument, we take into consideration where the order is held until execution and when exactly it is submitted to the exchange:

• Some order types are submitted right from your client through TWS/IBGW and IBKR's systems to the exchanges (native order types)
• Other order types and pretty much all algos are simulated within IBKR's systems (simulated order types)
• Some may be within TWS/IBGW for a while
• And others may be actively controlled by your client application (say you client monitors some market situation and places orders accordingly)

Obviously, speed of execution (with possibly better prices), resilience and tolerance against a long list of failures increases the closer your order is held to the exchange. The order types that execute directly at the exchange are a little different from exchange to exchange, but you can quickly find that out from the "Order Types" tab for each exchange listed at

In most of our cases, for example, we prefer bracket orders over OCA orders (assuming we can achieve the same goal) since brackets are generally native and OCAs are generally simulated. In your case, the stop-limit order is native on many exchanges while conditional orders are simulated by IBKR.

There is nothing wrong with simulated order types or strategies where your client application does all the heavy lifting (we do that a;ll the time), but you probably want to make sure you are aware of possibly failure modes when you make design and trade-off decisions.

Hope that helps,

闯ü谤驳别苍

I have another update (my problem is fixed, but I am worried about how it was fixed), I was hoping someone else can confirm this about OCA orders.

I am using twsapi 10.19 (Stable). NOT 10.20(latest) for my code base.

I have tried the following on ubuntu, windows and mac ventura (apple silicon) (both gateway and tws).

I have been using 10.19 all this time, and the only platform that worked was mac. I realised that I accidentally clicked latest on my mac and that's what it was working.

This is the behaviour I experienced after I tried the same version on all the platforms.

So, on tws/gateway 10.19 with the 10.19api on all platforms ubuntu, mac and windows.:
OCA (stoploss + close at time) orders fill immediately after they are posted.

So after I switched all my platforms to latest gateway and tws (i think its 10.22), my twsapi 10.19 which is stable, works properly!:
OCA (stoploss + close at time) orders stay in the system and do not do anything until they are supposed to

Is this how it's supposed to work? Should I be using the latest gateway/tws with the stable code?

I am worried that if they have another update it is going to break my code again.

On Wed, Apr 5, 2023 at 10:56 PM, Richard L King wrote:

By the way, it’s not necessary to treat me as if I’m a junior programmer that knows nothing about debugging, race conditions, etc. Look up the expression ‘teach your grandmother to suck eggs’ – I’m your grandmother!…

I'm just trying to help, and get help, working through a tricky problem. Sorry to have made you feel slighted.

开云体育

On Wed, Apr 5, 2023 at 02:02 PM, J G wrote:

not allowed to use two different numbers clientId1 and clientId2

Well, IDK if "not allowed" is the right term but yes... there appears to be a race condition problem introduced in some of the 10.x branch's clean-up code that complicates this.

Off the top of my head I have two recommendations:

• Start a number of different threads/processes with unique IDs as a pool (32 max) and never exit them until you're ready to restart the TWS/IBGW. Let them stay idle when/if there's nothing to do. This way the race condition never gets a chance to deadlock and cause problems.
• Modern CPU clock speeds are probably fast enough, at this scale, to do all your data collection in a single thread. Therefore you can rely on cooperative, rather than preemptive, multi-processing.

If there are some long running computations that are necessary, off-load them to separate processes or threads and manage the IPC on your own. If you don't rely on shared data and keep things on the stack... thread-safety should be easy to guarantee.

The later option of keeping all data collection on a single thread is my personal preference. And, I've previously mentioned that using makes this pretty easy. But, it's been a long time since I've used Java and so, although there may be an analogue, you'll have to research that solution yourself. Perhaps someone else can help there.

I'm sure there are other solutions that achieve a more fine-grained, perhaps higher-throughput, solution but IMHO it likely won't be worth the trouble.

-Good luck

On Tue, Apr 4, 2023 at 05:38 PM, Richard L King wrote:

without first cancelling the market data stream

Richard, I hate to harp on this but I think your understanding of the bug is coming along and so I would like to point out, again, that cancelling the market data stream does not prevent the eventual deadlock.

In fact it is very easy to refute that it does... just apply the proposed fix to the example and then run the example in a loop.

In other words, apply this:

--- example.py.~1~      2023-04-05 12:26:11.886098467 -0400
+++ example.py  2023-04-05 12:40:22.023094581 -0400
@@ -1,4 +1,4 @@
-import os
+import os, time
 from ibapi.client import *
 from ibapi.wrapper import *
 
@@ -31,6 +31,8 @@
             attrib: TickAttrib,
     ):
         print( "Got a price tick, exiting." )
+        self.cancelMktData(os.getpid())
+        time.sleep(1)
         self.disconnect()
     def error(self, reqId: TickerId, errorCode: int,
               errorString: str, advancedOrderRejectJson = ""):

to the example and then run in a forever loop, e.g:

#!/usr/bin/env bash

ii=1
while [[ $ii -gt 0 ]]; do
    echo -n ">>>>>>>>>>  $ii "; date
    ((ii+=1))
    python3 ./example.py
done

The deadlock may not occur immediately but will happen in somewhat short order. When I tried this the loop would hang by the 12th iteration with a very high likelihood; usually earlier. This behavior is certainly indicative of a race condition; be it in a destructor or reference counter as you suggest.

This is why I was encouraging you to forego "issuing API commands discretely" and test the example programmatically and thoroughly. Race conditions often disappear in a debugger or when you "step" through code because the code timing is affected. Additionally, in a real-world application, attempting to "fix" the race condition by introducing an artificial delay wouldn't help since the program would be running in parallel at random overlapping times and therefore any artificial delay would be canceled out by the start times.

Anyway, I'm glad you're feeling better.

On Sat, Apr 1, 2023 at 10:14 PM, 闯ü谤驳别苍 Reinold wrote:

The post took a bit of a "left turn" and became an entirely different post

闯ü谤驳别苍, I'll be the first to admit that the bug I've been droning on about is a corner case. However... it is a very good example of why serious consideration should be given to the decision of implementing a multi-threading/processing design. Multi-threading/processing can sometimes be difficult to implement and often creates very tricky problems that even experienced folks have problems troubleshooting and understanding. And, even if the application design is solid, sometimes the cause is poor vendor support which can be out of the developers control.

I contacted IB support and pressed the number to talk to the "API helpdesk". They asked me to send them the code so they can test it on the different platforms. I also tried running the code in amazon cloud on another apple silicon mac, I can confirm the code works as it should on another apple silicon mac but it doesn't work on linux and windows.