There is a FAQ in the latest connections regarding memory management under XP that will help answer your memory question. I suspect the problem you are running into with the bidir demo and 2000 connected client is related to running out of handles, not running out of sockets.

My colleague pointed that its most likely actually the size of all of the thread stacks that is causing the memory to run out. 2000 connected clients with thread per connection means 2000 threads. 2000 threads each with the default amount of stack space probably exceeds the 32 bit address space. You should lower the default stack space per thread (Ice.ThreadPerConnection.StackSize) and it may resolve this issue -- temporarily at least.

Thanks Matthew for your prompt reply.
I do not mean to use thread per connection anyway.
My primary purpose is to verify the concurrent connection limit of bidir.
Orignially I use Ice.ThreadPool.Server.Size=10. But I noticed that when the number of clients increased, the server will run low of thread pool.
that's why I use thread per connection instead.

Thanks Matthew for your prompt reply.
I do not mean to use thread per connection anyway.
My primary purpose is to verify the concurrent connection limit of bidir.
Orignially I use Ice.ThreadPool.Server.Size=10. But I noticed that when the number of clients increased, the server will run low of thread pool.
that's why I use thread per connection instead.

Kan

Does it really matter for your application if the thread pool runs low on threads? The only situation where it does matter is if you use nested callbacks, because then it is possible that a call blocks indefinitely if not enough threads are available to service the nested callback.

If you don't have such nested callbacks, I recommend to simply disable this warning, or to set Ice.ThreadPool.Server.SizeMax to the same value as Ice.ThreadPool.Server.Size. See the user manual for further information.