I believe I had this problem. Are you placing an order very soon after you get the callback to nextValidId? Wait a couple of seconds.
This thread sort of exemplifies what I hate about IB. The thread started months ago and IB has not fixed anything.. and that indicates that they never will fix things like this.. If you aren't prepared to eat, sleep, and shit IB's API then you aren't prepared to use it iow...
Once again, my first order (market) took an extra 5 seconds to get filled this morning! Yep, this broker is trying my patience! My patience is not limitless.
Firstly, I could not agree more with the frustration others in this thread have expressed regarding IB's glacial response to bugs of this kind. We have criticized them directly on numerous occasions for their fixation with developing still more bells and whistles in their UI rather than addressing serious problems with their system, and this case is no exception. IB have finally updated our trouble ticket - that we raised in early November - and announced that the bug "should be fixed in version 902 of the TWS". This is our reply to them, verbatim: We are awaiting their response, and will post it here.
I encountered the same problem a few months ago on the following platform/software: 1. OS: Linux CentOS 5.4 2. Python 2.6.4 with IbPy 0.7.6-9.51 3. last few versions of TWS 4. java 6 update 14-18 I have a workaround for this problem: After my application connected to TWS, I call reqCurrentTime() once. I have never seen the same problem for a few months. Hope this help.
Hi Folks, I have had a response from IB - again after much pushing - which (as promised) I am publishing here. So what does this tell us? Point #1 pretty much explicitly states that they still think that no functionality has been affected by this problem, which is worrying to say the least for all of us with continually busted first trades. Point #4 is reliably vague. Once we upgrade, I guess I'm hoping to see the API page created when the first connection to TWS via the API is made. I'm not sure what else "when we think it will be needed" could possibly mean. Point #5 is just wrong. Obviously, any operation that creates the API page should act as a workaround, now that we can be sure what the problem is. I'm guessing that requesting the nextValidId (as suggested by promagma) might even do the trick, but failing that some kind of tiny or out-of-market trade would do. And what have we learned? We now know that the problem IS related to the UI and not any internal settings, and that it occurs for all API users on all platforms. Interesting then that TWS Support claimed to us that their developers could not reproduce the bug and that they could not do anything without copious logs from us. And more logs after that. We have learned that IB does no automated testing of the TWS API at all (even though this is pretty much industry standard practice these days), or a problem like this would not even exist. It's also very, very clear that the "it will be right in the next release" philosophy is alive and well at IB - but we all knew that. It's also clear that the earlier responses by IB to this problem were (as is sadly common) just off-the-cuff guesswork. You know, the kind we can do ourselves without the resources of a whole company and team of TWS developers behind us. I have recently been contacted privately about this issue by an IB employee, and I think him for his interest. I have found the customer-facing employees of IB to be uniformly courteous during this process, but largely ineffectual in actually resolving TWS API problems. I suspect there is a cultural problem with the TWS development team, and the poor communications on issues like this are just a symptom of that problem. Just the simple fact that a UI problem can stop an API trade from being performed tells us that they don't know how to architect an application in the first place. Coupled with their unbridled arrogance in (normally) refusing to discuss the causes/solutions of bugs, refusing to attempt to duplicate problems, using customers as beta-testers in their constant upgrade death-spiral, and complete lack of rigor in testing provides testament to that. I'm hoping that this issue really is resolved now - it's only 2 months to the anniversary of this thread! - but I would urge anyone who encounters it again with release 902 onwards to post it here.
Thanks for your initiative, nello. But you're definately not a guy I would want to do discretionary business with. I'm having this sort problem for months now. My first orders of the day are usually getting delayed for about 13 seconds. Today it was extreme though; there was 1 minute delay, and my cancel order was delayed as well as the price moved against me. My kinda workaround is to enter a limit order outside the bid-ask spread which cannot get filled. Once I cancel this dummy-order everthing's working smoothly. Today though I've forgot about this procedure.
Point taken. I've been an IB customer for about 5 years now, and this is the first time I've aired their dirty linen in public. Basically, my frustration levels have reached an all-time high with this one.
It's actually an interesting response. The fact they create UI objects such as tabs not on the swing thread, shown a fundamental lack of understanding of how Swing (the UI engine) works. It's at least a very dangerous thing to do in a threaded environment. Scary ...