If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

We had to increase the open files limit on the server to solve the problem.
What's strange is that the number of sessions could somehow reach nearly 44,000.
Seems like when a user opens multiple pages, multiple sessions are created. Is there a good way to bring this number down? Like using only one session for each ip address?

And we have a new problem.

We are now able to start up the LS server, and keep it getting updated for a day or so. But the next morning, the socket connection between the application for supplying data and LS server would mysteriously drop. And we have to manually reconnect it through jmx. This seems to be a different issue all together. And I'm not even sure if this is a LS issue...

We found some error logs right before the connection went down. Does this mean anything to you?

LS_sessi13-Aug-10 09:51:07,322 |ERROR|LightstreamerLogger.connections |NIO WRITE SELECTOR |Failure in HTTP connection on Lightstreamer HTTP Server
com.lightstreamer.h.nb
at com.lightstreamer.f.a.hb.b(hb.java)
at com.lightstreamer.f.a.hb.c(hb.java)
at com.lightstreamer.f.a.i.c(i.java)
at com.lightstreamer.h.hb.g(hb.java)
at com.lightstreamer.a.qc.h(qc.java)
at com.lightstreamer.h.ob.a(ob.java)
at com.lightstreamer.h.ob.a(ob.java)
at com.lightstreamer.h.eb.a(eb.java)
at com.lightstreamer.g.a.y.b(y.java)
at com.lightstreamer.g.a.j.d(j.java)
at com.lightstreamer.g.a.j.a(j.java)
at com.lightstreamer.g.a.c.run(c.java)

If you have multiple pages on the same web application that need to communicate with Lightstreamer Server, you are recommended to use a single session and share it among all pages. See DOCS-SDKs\sdk_client_web\doc\Web Client Dev.pdf, paragraph 2.2, or analyze the code of the various demos.

Turning to the other issue:

By "the application for supplying data" do you mean a Remote Server that communicates with Lightstreamer Server through the ARI protocol?
Which is the role of jmx?

The reported exception is about a session that founds itself closed by an external agent. It is not a normal case, but it seems unrelated with problems that may be occurring in the communication between LS Server and the Remote Server.

We need more details to proceed.
Can you identify the exact moment in which the communication between LS Server and the Remote Server is broken and provide us with a log snippet including the whole period? In case it's too big, could you manage to replicate the issue with only a few active sessions?

From Lightstreamer Server point of view, the connection was closed by the Remote part. Do you feel it's possible? Is the log a full snippet or has it been filtered? Was anything logged just before the first line reported?
Of course, the error is "fatal" only for the underlying Proxy Adapter. The RobustNetworkedDataProvider can overcome the issue by creating a new underlying Proxy Adapter.

About keepalives, if you can enforce them, this can only have positive effects;
they can also prevent any intermediate node from dropping the socket.
Note that the ARI protocol also defines its own keepalives, that can be sent by the Remote Server to the Proxy Adapter (with no timeout checks, though).
I suppose you are not using our .NET Remote Adapter SDK;
otherwise, consider that the Remote Server already sends keepalives every second (keepalives are not sent when data already flows on the connection).