Hi Kevin,
Sorry, the fix is related to xhr.html requests, not to the iframe themselves (that currently remain sitting there, empty).
The fact that you see the failed requests every few seconds is ok and should not be an issue, the bug I fixed made the client going on requesting the same xhr.html even after the server came back up and even after the download of said file was successful.
Both bugs are fixed in these versions:
http://www.lightstreamer.com/temp/Li...ild1640.17.zip
http://www.lightstreamer.com/temp/Li...6build1670.zip
OK I have loaded that thanks - seems OK now on that score
Is there any feedback on the numerous warnings and errors:
Current delay for tasks scheduled on thread pool TLS/SSL HANDSHAKE is 19 seconds.
Handshake error on Lightstreamer HTTPS Server: task timed out on 217.118.110.123:56732.
I have transferred the log file from today (with the debug information) for analysis. Thanks.
It seems there was a LPAR update applied when the issues started occurring on Saturday.
Hi Kevin,
The log confirms that the xhr.html requests are in charge of the difference between the number of connections and sessions.
However in this case the situation does not collapses and we have no messages "Current delay ..." as in recent days.
About the messages like these:
these messages were a direct result of the huge number of HTTPS connection requests queued in the evening of 21 February.Code:"Current delay for tasks scheduled on thread pool TLS/SSL HANDSHAKE is x seconds." "Handshake error on Lightstreamer HTTPS Server: task timed out on ..."
The TLS/SSL handshake is a quite demanding operation that can subtract many resources to the rest of the server.
For this reason, the factory configuration for the <handshake_pool_size> is 1.
If peaks of HTTP connection requests are expected you could raise this number to better cope with the requests. But I do not think it's your case, since it was an abnormal episode that should not be repeated.
Regards,
Giuseppe
OK thanks for that information. The question really remains however: is there any way that I can explain the abnormally high number of connection requests? Presumably there is only one source of such a request, and that is from the clients (browsers) running the application and attempting to connect via lightstreamer.js ?
Is there anything that my own JS code could do to (a bug) that would generate an unexpectedly high number of connections? I know that the browser itself has limits, but if you have a lot of users, all exhibiting the same bug, it could have this sort of impact. If my code created multiple duplicate LightStreamerClient's for example - or created just one but run a connect() method on it multiple times even when it is already either connected or in a connecting/disconnect-will-retry cycle?
Also, could you please help me explain these errors:
13:44:11 Handshake error on Lightstreamer HTTPS Server: Client requested protocol SSLv3 not enabled or not supported on 46.31.180.132:57106.
TLS/SSL HANDSHAKE POOLED THREAD 1
Hi Kevin,
For the list of enryption protocols enabled you must verify those supported by your JVM and any exclusions from configuration.
For Lightstreamer 5.x you should check for any parameters <allow_protocol> in <https_server> section. If any, only the protocols mentioned are enabled
Please could you confirm that the number of connections remains very high even using the library with the last fix?
OK I see. So I misunderstood the message. We have clients requesting SSLv3 and the server is saying that it does not support it. We currently have not <allow_protocol> settings configured at this customer, so I gather from what you are saying is that this means the IBMi JVM does not support SSLv3. I have no idea why it isn't supported but possibly because of this: http://www-01.ibm.com/support/docview.wss?uid=swg21687173
but can we safely ignore this error anyway? If the client requests SSLv3 and it isn't supported, will it negotiate a lower level and connect anway? Is this just a slight impact on connection times?
With regard to your last question, I am unable to verify this at the customers site because I am not able to implement changes without going through a full delivery phase. Can I safely deploy the latest to change provided by Mone even though the customer has not yet upgraded to LS Server version 6 ?
Bookmarks