I noticed this once yesterday but twice today. I suspect it's due to a new rev of TWS that came in yesterday (I'm on 879.4). I did open a ticket after seeing it twice today (so 3 times in all) but wondering if anyone else has seen it. It starts with a pinkout -- which may be due to a network issue (though I immediately test pinging www.interactivebrokers.com afterwards and it pings fine, zero loss after 60secs, 15-20ms response times).... Then the reconnect seems to fail. In the process I see my option trader window flashing on and off. Finally I end up with the state in the attached screen shot. A blank/pinked window.... with lots and lots of tabs... I have to then kill the javaw process as the UI is totally unresponsive. If I re-launch TWS, it works fine.
I am having a similar problem with TWS 878.5 running under Windows 2000. On an average of four times each hour TWS gets pink lines on the page for about 10 seconds, but otherwise looks normal. About once an hour all data fields freeze, go blank, and reload within about 10 seconds. A bit annoying but at least I can place orders most of the time. I have used IB for 8 years and have never had such a long lasting problem with TWS. I am sure IB is making every effort to get TWS back to a stable platform.
As they say, misery loves company. (Well at least company means it's more likely for the problem to be found and fixed if multiple users are experiencing it.) It just happened to me two more times today making it 4 times today and once yesterday. I noticed that I was pushed 879.5 but the most recent craziness hapepned with 879.5 so clearly 879.5 doesn't fix it. Also this time something slightly different happened -- an alert saying something like loading settings from server has been disabled. Wondering if it's related to Store settings on server, which I have unchecked for my latest logon.
I have had IB since before they had a desktop app. I have seen it all. I have even figured out stuff that the tech people couldn't. My suggestion is to unintall IB, delete directory and start completely over with a fresh install. Also check your log and see if you can see anything in there that happens right at the disconnect. You can even post the log here if you like and we can look at it. Go to C:\jts and look for the day's log that you are interested in. John
Thx. Well, why it disconnected is less the concern as I can believe a glitch -- or in any case, network glitches WILL occur. The going crazy thereafter and inability to reestablish connection is the more troubling issue. This is definitely new TWS behavior with more recent versions. I've seen TWS survive through cab rides w/wireless card (very unreliable) successfully in the past. I am hoping the store settings on server is the culprit bec that's easy to work around (I now have it unchecked).
Network problems are very very very rare. Its just what customer service likes to tell you. Your disconnecting and glitches are rooted in the same problem. Find out why you are disconnecting and you can properly find your problem John
You are right!!!! It is unlikely to be a network error. After looking through the log, it appears that the problems start with the following --- an SSL MAC error. With network, I would assume a lost connection or truncated data, but a MAC error sounds like the server calculated the wrong MAC!!!! (unlikely to be client side -- unless Sun's SSL stack is bad but I haven't upgraded JREs recently so that's not likely.) VD 13:19:01:647 JTS-CCPListener-5: Anticipated error: SSL Error reading from socket gw1.ibllc.com:4001 VD 13:19:01:647 AWT-EventQueue-0: Error sending msg - javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac VD javax.net.ssl.SSLException: Received fatal alert: bad_record_mac at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source)s 1 at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source) at jconnection.ab.run(ab.java:61) VD 13:19:01:648 AWT-EventQueue-0: NextConnectTime: 13:19:09:554 base=5000 range = 10000 random: 4821 And then no successful reconnect happens bec the server drops me: VD 13:19:16:001 JTS-CCPListener-3374: Socket for connection gw1.ibllc.com:4001 was closed by peer It then cycles through restoring the tab pages from hibernation but each restore failed bec we're not connected. The next occurrence started with the similar SSL exception (same for the rest): VN 13:56:46:387 JTS-CCPDispatcher-14: Checking market data VN 13:56:46:387 JTS-CCPListener-5: Anticipated error: SSL Error reading from socket gw1.ibllc.com:4001 VN 13:56:46:388 AWT-EventQueue-0: Error sending msg - javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: Received fatal alert: bad_record_mac VN 13:56:46:388 AWT-EventQueue-0: Disconnecting gw1.ibllc.com:4001 with status 1 VN javax.net.ssl.SSLException: Received fatal alert: bad_record_macVN 13:56:46:388 AWT-EventQueue-0: NextConnectTime: 13:56:53:458 base=5000 range = 10000 random: 3667 VN 13:56:46:388 JTS-CCPPing-9: Terminating at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.recvAlert(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readDataRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.AppInputStream.read(Unknown Source) at jconnection.ab.run(ab.java:61)
Done -- and coincidentally it just happened again a bit after I sent the requested files, though this time w/o an SSL Mac exception. So I sent a follow-up with the tail of the log that should make it easy to isolate the most recent incident. This time I do not have store settings on server, so that isn't material. I am wondering if it has to do with using SSL. Tomorrow I am going to connect w/o SSL. Not preferred but stability with a limited security risk (man in middle -- the token protects against an outright heist of credentials) beats multiple hiccups per day.