¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Twsapi
  2. Topics

No or delayed response on placed orders using IB Python API TWS 10.19 on Linux EC2

 

Hello,

I've been using the TWS Python API for almost two years for automatically trading futures. I run my code on an amazon Linux EC2 machine, Python 3.9.5 , ibapi version 9.81.1.post1, TWS version 10.19.
Over the past few weeks I've noticed that some of my orders have been getting "lost". By lost I mean no response in the orderStatus() callback. Normally I get a response almost immediately (my system checks every 2 seconds), sometimes it takes 8-10 seconds, sometimes up to 3-4 minutes, and on one occasion I didn't get a response at all. I checked by the TWS logs, the API logs, and my own system logs, and nothing.

Anyone have any idea what might cause this???

Thank you,
Yonatan
fran
 

¿ªÔÆÌåÓý

Possibly facing disconnection/reconnection? Explore a finite state machine to detect lost orders, resend when logic conditions are met.


El 6 dic. 2023, a la(s) 13:54, yonatan@... escribi¨®:

?Hello,

I've been using the TWS Python API for almost two years for automatically trading futures. I run my code on an amazon Linux EC2 machine, Python 3.9.5 , ibapi version 9.81.1.post1, TWS version 10.19.
Over the past few weeks I've noticed that some of my orders have been getting "lost". By lost I mean no response in the orderStatus() callback. Normally I get a response almost immediately (my system checks every 2 seconds), sometimes it takes 8-10 seconds, sometimes up to 3-4 minutes, and on one occasion I didn't get a response at all. I checked by the TWS logs, the API logs, and my own system logs, and nothing.

Anyone have any idea what might cause this???

Thank you,
Yonatan

 

For me the delay happened on race conditions when unloading the api message queue. Once I found a way to monitor it, I have noticed it could grow to thousands of unprocessed messages, which caused the delay. Make sure it's not get cluttered, I used semaphores etc. to make sure different threads do not race on the same queue. Now it never happens.
 

Hi,
Thanks for the response, race conditions were my initial concern. Mind explaining how would I go about monitoring the api message queue and keep race conditions from happening?
 

If your instance of IBapi() is called app like mine, in every thread I check app.msg_queue.qsize().?
Make sure to use semaphores, as the .qsize() reading itself can create race if a few threads try to do it all at once.
Here is how I do it:
?
with semaphore_apiq:
?
len_var = app.msg_queue.qsize()
?
log_msg = symbol + ' ### length of api msg_queue: ' + str(len_var)
?
logger.info(log_msg)
?
info_dict['api_qsize'] = str(len_var)
?
if len_var > max_len_var:
?
max_len_var = len_var
?
info_dict['max_api_qsize'] = str(max_len_var)
?
if len_var > 100: # delay to sort backlog
?
time.sleep(random())
?
In effect, if the queue grows to over 100 messages, the thread is pause for up to 1 sec letting callbacks work its course.
?
I am sure this is not the smartest solution, and I don't like it, but it works apparently. Maybe you or someone can come up with a better idea, please do share.
 

In which function are you running this bit of code? Inside the EWrapper callbacks (ie tickSize, tickPrice etc)?
If you do time.sleep() on the api thread, wouldn't messages get lost when they are sent to you but not received?

Btw my solution was to not do any handling of the messages received in the callbacks, but instead enqueue them to my own queue, then handle that queue at a later time in a different thread.
 

Definitely not in the api thread.
What do you mean by your own queue? Are you sure this is thread safe? Most probably your problem stems from this. If your queue is not fast enough or prone to race, it will give you the delays that clutter the api queue.

1 - 7 of 7