Ref: IB Gateway Build 972.1r, Feb 12, 2019 11:03:55 AM I noticed that, after some Internet disconnections, the Gateway while reconnects fine by itself, it is NOT able to respond to the API requests of restoring the flow of data (2103 "Market data farm connection is broken:usfuture"). The relevant line on the user interface becomes yellow and data restarts ONLY IF the Gateway is manually shut down and restarted. Note this is an issue with the Gateway and no matter what you do in your application (like fully reinstantiating and restarting all the API messaging or whatever data request) it will NOT resume the flow of data. There must be some parameter or reference which is not fully reset by the Gateway on reconnection and that prevents the data to restart coming on request. Instead, if the Gateway is restarted MANUALLY, the flow restarts normally. I have also found several references to this problem on the Internet of people pointing out this important bug. This, of course, breaks any possibility of serious automation. Please, kindly, fix this behavior. Thank you!
You need to restart Gateway after the nightly resets. This has been an issue for some time now and I doubt will be fixed completely anytime soon. I agree that it's unnerving and obnoxious as it happens seemingly randomly.
Hi d08, I hope you are joking! Well, the fact that on manual restart it works fine, clearly indicates that on simple automatic reconnection there is "something" that still needs to be reset/restarted or fixed (like a dead thread to be restarted, or some reference/variable which needs to be refreshed or reset or whatever). In any case, it does not seem anything too difficult, that a decently capable programmer can identify and fix in a short time. (In the meantime, in total ignorance or laziness, one could just restart all systems, like when the application is just starting up, while the culprit is identified).
Why would I be, it's the only practical solution as of now. Your systems should re-establish properly after reconnection. You'd lose 2 minutes of trading, sure.
I've been having various issues related to the "resetting cycle" for a while. Every time one of these seemingly random issues appears, I create a ticket with IB, instead of solving my issue they just tell me I need to upgrade to the latest version of gateway and respond back if the problem still occurs. Then when I upgrade, the original problem may or may not be fixed but there is usually something else that has broken or regressed. In the latest one for example they have started forcing daily resets (weekly was bad enough) and there is a race condition where if you connect to the API while gateway is in the middle of reconnecting to IB, then the API will be in an inconsistent state where commands can return incorrect results. The workaround is you wait 30 seconds after connecting to the API before sending any commands. I don't know what they are doing over there lately but it reeks of technical incompetence. No offense to anyone in particular, I'm sure they have some good people there, but all this daily/weekly restarting is all bullshit. If they coded it properly it should run uninterrupted forever (years) unless there is some critical update needed.
I am sure the great chief at IB has not been properly informed. I doubt he would allow something like this to go on, and kill all possibilities of proper and serious automation with IB.
I hope you are joking . Seriously, I think the only way to keep your sanity with IB is to accept it for what it is and find work arounds.
Well, I would sign for the 2 minutes ;-) . Problem is with the Gateway itself, not the client application. If not completely restarted, the Gateway will not resume the data flow (no matter what you do in your application). It will connect fine and whatever, but on request, it will not send any mkt data (even if you restart your application, recreate the messaging system or whatever). It's clearly something "broken" inside the gateway.
That's what I was talking about, exiting/killing the gateway after the reset period (restarting). Obviously it has nothing to do with the client as the client only makes requests to TWS/GW. I also gave 15 minutes extra after the reset window closed as server reset times are not always so precise. I had the same exact issue and that's what I did as a workaround. It's been working thus far.