I wouldn't dismiss Gordon's comments outright, though. Granted, orderIds and requestIds serve very different purposes, and it is entirely legitimate if you have a market data subscription with requestId=10 as well as an order with orderId=10, but orderIds and requestIds are only independent until something goes wrong.
In that example, where would you route an ( id=10, .... ) callback? To the order manager that handles orderId=10 or the market data manager that handles requestId=10?
We follow the lead of the ApiController class that ships within the Java API and are very happy with this approach. We take the orderId value returned by
This approach assures that requestIds and orderIds are unique within each client session, that requestIds and orderIds never collide, and that all error callbacks can be associated with the request or order placement it relates to.
´³¨¹°ù²µ±ð²Ô
On Fri, Aug 4, 2023 at 02:30 PM, ds-avatar wrote:
To be precise, the TWS is designed to shut down some time (24h?) after being launched. It can auto-restart after the shutdown but only if it's specially configured to do so.
The NextValidId variable you are referring to needs not be incremented for __every__ request, as you seem to believe, it only needs to be incremented to define the Order Id when placing orders. Request Ids used for querying statuses and getting market data, news and whatnot have nothing to do with that and can be any numbers at the user's discretion. Surely it's sensible to use different request ids for different requests, but it's no problem reusing retired request ids. The same is not the case with Order Ids as they always need to be greater than any previously used order id, until the sequence is manually reset back to 0 in the TWS. Contrary to what Gordon pondered, I think it's not just some naughty "bad practice" to recycle order ids, it's completely useless since it will strictly result in an error and the order placement will be aborted; to make matters even worse, I used to get some cryptic and seemingly unrelated error messages from TWS when learning, and failing, to synchronize the order id sequence in a highly concurrent system, making the issue somewhat hard to debug. But I concur that the amount of orders needed to be placed to run out of order ids is so huge it's not worth a bother. To get some peace of mind it would seem adequate simply to reset the sequence once a year.?
--
Best,
DS
