Thread count on server-side using async server and channels

When using Delphi for client and server with the SuperTCP channels, is it normal that every connection results in a new thread being created on the server? In my apps (note: using an older version of RO, not the latest), each connection results in an increase by one of the thread count as shown in task manager and IDE debugger. Disconnecting does decrement the count. I assume this is by design since the client is able to respond to events in real-time, however, if this is the case, what is the thread pool of the server component used for? Thanks in advance for any help!

Ryan

It depends on the used ClassFactory see here: http://wiki.remobjects.com/wiki/TROClassFactory_Class. The default ClassFactory uses one thread per connection.

Yes, but it seems that if I use SuperTCP, the number of threads increases with each client, while using the regular TCP client does NOT increase the thread count (except for the tiny amount of time that the client is making a server call). What I’m asking is - is this correct? Does SuperTCP use a thread on the server side for as long as it is connected? Right now, that is what it appears to be doing, and this is not good for me because it is causing a large number of threads due to the large number of clients. I am using a pooled class factory with a count of 5, but the thread count did not change from when it was set to the default…

Yes, this is how the Super channels work. The plain channels just connect for a request and then disconnect after receiving the result. The Super channels create a permanent connection (in its thread) to be able to deliver events from the server to the client, and you can invoke remote services/methods with a long processing time asynchronously without waiting for the result. In both cases you do not have to poll the server e.g. using a timer. If you do not need these features and you are concerned about ressources/threads, the more lightweight plain (non-super) channels are the right choice.

Thanks - that’s what I needed to know! I will rewrite this portion to utilize regular TCP then since it is high load and I don’t have a need for events in this particular case…