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.
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
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?
Bookmarks