I just sent this to Dario as a private message, but thought I'd ask here as well.
We have been experiencing the same problems as another user from this thread
http://www.lightstreamer.com/vb/showthread.php?t=967
The symptoms are the same as he was describing. Some connections are successful, others not.
Our application is an html client making ~5 new tables on startup and un/subscribing to different groups while running. On the affected machines one or more tables do not load on startup and we get the connection errors. However, after some time (10s to >1min) those tables will be loaded. Other subscriptions intermittently fail to start, some are immediately successful.
Here's an example section of the log
04-Aug-11 10:33:38,141|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 4 |Serving request: /lightstreamer/create_session.js --> LS_phase=1801&LS_domain=marketspreads.ie&LS_polling=true&LS_polling_millis=0&LS_idle_millis=0&LS_client_version=5.0&LS_adapter_set=TradingPlatformAdapterSet&LS_user=ALBIRO&LS_password=[...]& from [my ip]:60433
04-Aug-11 10:33:38,141|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 4 |Starting new session: S144c98bfd9fe7d26T3338141 from [my ip]:60433
04-Aug-11 10:33:38,173|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 13 |Serving request: /lightstreamer/bind_session.js --> LS_session=S144c98bfd9fe7d26T3338141&LS_phase=1803&LS_domain=marketspreads.ie& from [my ip]:60433
04-Aug-11 10:33:38,173|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 13 |Attaching session: S144c98bfd9fe7d26T3338141 from [my ip]:60433
04-Aug-11 10:33:38,687|DEBUG|ghtstreamerLogger.connections.ssl|O SSL HANDSHAKE SELECTOR 10|Handshake completed on socket Lightstreamer HTTPS Server; selected cipher suite TLS_DHE_RSA_WITH_AES_128_CBC_SHA
04-Aug-11 10:33:38,687|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 10 |Serving request: /lightstreamer/control.js --> LS_session=S144c98bfd9fe7d26T3338141&LS_table=1&LS_win_phase=69&LS_req_phase=148&LS_op=add&LS_mode=COMMAND&LS_id=MKN1&LS_schema=key%20command%20n%20c%20p%20s%20l%20w&LS_data_adapter=MarketNavigation&LS_snapshot=true&LS_requested_max_frequency=1&LS_unique=1& from [my ip]:60434
04-Aug-11 10:33:38,687|INFO |LightstreamerLogger.requests |SERVER POOLED THREAD 10 |Controlling session: S144c98bfd9fe7d26T3338141 from [my ip]:60434
04-Aug-11 10:33:38,765|WARN |ghtstreamerLogger.connections.ssl|NIO READ SELECTOR 4 |SSL read error: Input SSL/TLS record too big: max = 33049 len = 38523
04-Aug-11 10:33:38,765|DEBUG|ghtstreamerLogger.connections.ssl|NIO READ SELECTOR 4 |SSL read error
javax.net.ssl.SSLProtocolException: Input SSL/TLS record too big: max = 33049 len = 38523
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.readNetRecord(SSLEngineImpl.java:803) ~[na:1.6]
at com.sun.net.ssl.internal.ssl.SSLEngineImpl.unwrap(SSLEngineImpl.java:713) ~[na:1.6]
at javax.net.ssl.SSLEngine.unwrap(SSLEngine.java:607) ~[na:1.6]
at com.lightstreamer.f.a.s.a(s.java) ~[lightstreamer.jar:na]
at com.lightstreamer.f.a.gb.a(gb.java) ~[lightstreamer.jar:na]
at com.lightstreamer.f.a.gb.a(gb.java) ~[lightstreamer.jar:na]
at com.lightstreamer.f.a.p.a(p.java) [lightstreamer.jar:na]
at com.lightstreamer.f.a.o.a(o.java) [lightstreamer.jar:na]
at com.lightstreamer.f.a.nb.b(nb.java) [lightstreamer.jar:na]
at com.lightstreamer.f.a.a.x.a(x.java) [lightstreamer.jar:na]
at com.lightstreamer.f.a.a.p.c(p.java) [lightstreamer.jar:na]
at com.lightstreamer.f.a.a.n.run(n.java) [lightstreamer.jar:na]
It sounds to us like a problem with java's ssl libraries, perhaps due to client machines sending too large a chunk of data, but I can't find anything conclusive.
I can reproduce this behaviour on a windows xp virtual machine here with several browsers, while our office desktops on win7 have no problems. Some external machines also exhibit this behaviour on win2008 and win7. The server is not on our office network. The only difference we can think of is greater network latency from the affected machines than our office ones.
If there's any more info I can give please let me know. I can host the full log somewhere.
