LS server running out of memory

[kpturner]

The number of connections compared to the number of sessions is concerning me though. At a different customer where the current number of connections and the number of sessions are roughly the same.

[giuseppe.corti]

Hi Kevin,

Generally, the number of connections is greater than or equal to the number of the sessions, in fact, for each session we have a permanent connection dedicated to streaming, and a control connection, temporary, used to send control commands that manage the contents of the stream channel.
In normal situations you should expect a number of connections equal to or slightly higher than the number of sessions. However, in some cases, connections may become much more numerous, for example in phases in which many clients are trying to connect, or if many clients are connected in polling mode.

In particular, in case of a session in polling mode, that is not leveraging the reuse of connections, and frequent updates the number of open connections to the server can significantly grow. However numbers like yours are quite unusual.
50 connections with only a client using the Monitor is something unexpected. In order to investigate further the issue it would be necessary set these logger levels:

<logger name="LightstreamerLogger.requests" level="INFO"/><br /> <logger name="LightstreamerLogger.connections" level="DEBUG"/>

since, with hundreds of connections per second the size of the log file can grow quickly you can keep these settings for a few seconds (up to a minute) and then collect the log.
With these levels we should have some more information on connections and why they can not create a session.

In order to prevent the "out of memory" and also to saturate the handshake threads pool you can use this parameter:
<br /> <!--<br /> Optional. Maximum number of tasks allowed to be queued to enter the<br /> "TLS-SSL HANDSHAKE" thread pool while accepting new incoming TLS/SSL<br /> connection requests.<br /> The setting only affects the listening sockets specified through<br /> "https_server" that are not configured to request the client<br /> certificate; as long as the number is exceeded, the accept loops of<br /> these sockets will be kept waiting.<br /> A negative value disables the check.<br /> Default: -1.<br /> --><br /> <!--<br /> <handshake_pool_max_queue>100</handshake_pool_max_queue><br /> -->