开云体育

• should not directly perform very time consuming processing tasks
• should not directly perform tasks such as file or database operations that might block the callback for extended or unbounded periods of time

• and your client shall never call a sleep function.

Callbacks alert you about the arrival of new data and trigger processing (possibly at a later time). Simple and fast tasks can be performed right away, but anything more serious needs to be handled by a thread other than the callback thread. Every programming language has built-in or library add-ons that provide the tools you need for an event-driven client structure.

• it could drop certain messages by performing no task in the callback function (say you drop Bid/Ask or account value updates at peak times)
• or it could buffer lower priority data in a queue for later processing
• but it would always be ready to process important messages such as order updates, execDetails, and error messages or the most critical data your trading logic needs to be aware of immediately

We have never seen any backup issues and process in excess of 20,000 messages per second in peak situations.

闯ü谤驳别苍

This is not manual. Of course, pre-submitted and submitted statuses are also coming when relevant.
What happened is a failed price modification attempt. PlaceOrder is sent with a new price and the same id for modification, it happens to be just executed, hence the rejection. But there should not be a cancellation as the original orderId is executed, but the 'new' duplicate one is rejected. This is my understanding it should be submitted first before it can be cancelled. And if we assume the order was somehow considered 'new' by IB there should be a duplicate id error instead.

You mean error 103 ?
I recommend that you have to live with the reported 'error' "Cancelled",? The reported error-ed situation from IB seems sound and usable.

Interesting case!
What you try to do is requiring a very complex analysis to decide that it is a 103 and at pretty fast pace considering all the thing that happens during resolution of the execution.

I am not surprised and I won't expect better. Here you dealt within less than 150 ms to: transmit/receive, reroute, choose BBO with a reservation process, execute and clear the order, with delay including exchange servers, while in the middle of that you call for a reprocessing of the same order.
Way faster is feasible but it's way more expensive.

Programmatically sound and easy (and this is even IB recommendation) would be that you cancel your order then do a new one with new pricing.
Consider that, it that may fit your need. And look at the flexibility IB offer to modify an existing as a way to improve performance (Update is cheaper than Delete+Insert), but with the risk that it create complex situation for IB like what you do which is a modification sent while execution is probably in the clearing phase.
Hence an error message as a rejection that I can understand as reflecting exactly what IB experienced, and not a clear cut 103.
BTW can even be more perilous with some order kind that require slack, look at error 440 or 129 (never tried an order that may generate it)

I does experienced similar things.
While being very difficult to frame it, I would say that it seems more hectic when you call explicitly for last bar.
It does behave like if IB take a long time to build the final 1min bar (If I have to guess, I would say that VWAP is the part that are difficult to gather to make it accurate enough)
Also seems stock specific. Some are harder to get.

I get the feeling that regularity seems better when either:
1- I call for bar, and set the keepUpToDate=true
or
2- I make my call at least 5 second after the end of the minute I specify trough enddate (5 sec or more using the time shifted as IB reqCurrentTime will suggest it),
otherwise said not trying to ask too early for the latest 1min bar (Which should be available straightaway I agree)
or
3- (decommissioned) If not answered within 1 sec I cancel the request and wait 5 sec then initiate a new request,
It behave like if you miss the opportunity to be serviced right-away, IB does put your request in limbo and service it as part of a 'garbage collection'.

Some answers are so slow that I can open a TWS chart and generally does experience the same sloppy display, so I guess that IB is struggling for IO or DB.

Note:
#3 above is pretty complex just to grab bars,
I discarded the code and switch to aggregation of data from a couple of other feeds to get bars in a timely manner, keeping IB requests running and overwriting result with the IB one when they deliver it.
I trust more IB data and they have their own VWAP formula, I am not sure they are right because I guess they only account full lot, but for sake of consistency I better keep the same data kind

I maybe wrong and miss something, but didn't have time to do further experiments.

And yes, I always get openOrder with Filled status after execDetails, even if with a few ms delay.