LS server running out of memory

kpturner

OK thanks - I will ask what they were up to

kpturner

@Mone - I am now on client version Version 6.2.5 build 1669 but I am still seeing the DOM elements building up. Eventually my browser dies as a result.

At the moment the customer has the LS server switched off - so the same thing is happening on their browsers. Eventually they die. So it is quite a bad situation although not connected directly to this issue.

kpturner

I am also looking at my own console tab in chrome while using their system and I am seeing literally hundreds and hundreds of of these failures pouring in every few seconds :Smile_Ac:

Mone

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/Lightstreamer_JavaScript_client_6.1.4build1640.17.zip

http://www.lightstreamer.com/temp/Lightstreamer_JavaScript_client_6.2.6build1670.zip

kpturner

OK I have loaded that thanks - seems OK now on that score :Smile_Ab:

kpturner

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.

kpturner

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.

Giuseppe Corti

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:

"Current delay for tasks scheduled on thread pool TLS/SSL HANDSHAKE is x seconds."

"Handshake error on Lightstreamer HTTPS Server: task timed out on ..."

these messages were a direct result of the huge number of HTTPS connection requests queued in the evening of 21 February.

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

kpturner

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?

kpturner

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

Giuseppe Corti

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?

kpturner

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 ?

Giuseppe Corti

Hi Kevin,

Yes, you are right, indeed we also suggest to disable sslv3, please refer to this blog post .

I confirm you that this library 6.1.4 build 1640.17, is fully compatible with Lighstreamer 5.1.x and contains the fix.

kpturner

....andt he client will negotiate a connection regardless of the fact that SSLv3 is disabled?

Giuseppe Corti

Hi Kevin,

Yes, the client should be able to switch to one of the TLS protocols.

kpturner

I think the answer to my last question is "no" they won't. Clients that insist on SSLv3 will not be able to establish a connection at all.

So, in summary, are we saying that the connection "flooding" was a client-side issue caused by the server being offline for a long period of time, and that this is fixed with the latest client ?

Giuseppe Corti

Hi Kevin,

The client and the server establish a connection if they can agree on a common protocol.

kpturner

Giuseppe Corti Hi Kevin,

The client and the server establish a connection if they can agree on a common protocol.

...but not browsers that don't support TLS (like IE 6 for example). They will just fail?

That aside, are we agreed on my last statement/question:

"So, in summary, are we saying that the connection "flooding" was a client-side issue caused by the server being offline for a long period of time, and that this is fixed with the latest client ?"

kpturner

By the way, if I try to use the latest version of Lightstreamer.js with server 5.1.2 then I get constant alerts saying "License not valid for this client version".

is there something else I need to change? This server is running with a trial licence.

Obviously it all works well with server 6.0

Giuseppe Corti

Hi Kevin,

There are two different patched libraries:
- for Lightstreamer 5.1.2 which is this (6.1.4 build 1640.17);
- for Lightstreamer 6.0 which is this (6.2.6 build 1670).

If you use the first with the server 5.1.2 you should not get the error mentioned.

Yes, I can confirm that we expect that the new library should avoid the "flooding" of connections.

« Previous Page Next Page »