Archived
This forum has been archived. Please start a new discussion on GitHub.
Very, very strange problem with Ice-based applications!
Hi,
I am developing couple of programs which use Ice C++(2.1.0) to communicate with each other. The architecture is like this:
Many clients (let it be called "C") communicate in SSL to a server-side program (let it be called "S") periodically about once per 120s. This server-side program responds to clients' request and notify other server-side programs (let them be called "X"). According to Ice's manual, 120s is long enough to force client-side Ice communicator to release the tcp connection automatically. In fact, we depends on this feature to support more than 1024 client. As we all know, 1024 is a hard limit of select call on Win32 platform.
I've specified a fairly big thread-pool-size ( more than 40) to gain higher concurrency, so in TaskManager I could see the threads number of S, for example, 50.
After running for a long time ( about 6 days ), all client couldn't connect to S, and most X couldn't communicate to each other.
I did some diagnosis on server side. Telnet the listenning port of S, it responded with WSAECONNRESET. Telnet the listenning port of some Xs, the connection could be established but no "IceP" character printed in the screen as normal Ice server program does, some Xs responded with WSAECONNRESET too. And the strangest thing is the thread nubmer of S or Xs then is much smaller than those when they just started for a while. And the thread number then is so small that I doubt if the Ice's internal threads ( objects, communicator, adapters ) are all dead.
If Ice's internal threads are all dead, of course my program couldn't provide service any more. But the problem is, how could this happen? What can I do?
I am developing couple of programs which use Ice C++(2.1.0) to communicate with each other. The architecture is like this:
Many clients (let it be called "C") communicate in SSL to a server-side program (let it be called "S") periodically about once per 120s. This server-side program responds to clients' request and notify other server-side programs (let them be called "X"). According to Ice's manual, 120s is long enough to force client-side Ice communicator to release the tcp connection automatically. In fact, we depends on this feature to support more than 1024 client. As we all know, 1024 is a hard limit of select call on Win32 platform.
I've specified a fairly big thread-pool-size ( more than 40) to gain higher concurrency, so in TaskManager I could see the threads number of S, for example, 50.
After running for a long time ( about 6 days ), all client couldn't connect to S, and most X couldn't communicate to each other.
I did some diagnosis on server side. Telnet the listenning port of S, it responded with WSAECONNRESET. Telnet the listenning port of some Xs, the connection could be established but no "IceP" character printed in the screen as normal Ice server program does, some Xs responded with WSAECONNRESET too. And the strangest thing is the thread nubmer of S or Xs then is much smaller than those when they just started for a while. And the thread number then is so small that I doubt if the Ice's internal threads ( objects, communicator, adapters ) are all dead.
If Ice's internal threads are all dead, of course my program couldn't provide service any more. But the problem is, how could this happen? What can I do?
0
Comments
-
Hi,
Could you please set your signature? See [thread=1697]this thread[/thread] for information on our support policy on the forums.
Cheers,
Benoit.0
