Archived

This forum has been archived. Please start a new discussion on GitHub.

Consuming threads in case difficulties

How ice runtime consumes threads from thread pool in case difficulties? How many threads from what pool (client/server) it spends on every two-way synchronous connection made from client to server if Ice::ConnectTimeoutException occurs?

Digging through the documentation and forum didn't help me answer these questions. The story: there is a service (master) that makes two-way synchronous connections to other services (slaves) and in case slaves are get blocked master starts consuming threads from server pool.

for example configuration of pool is following
Ice.ThreadPool.Server.Size=2
Ice.ThreadPool.Server.SizeMax=10
Ice.ThreadPool.Server.SizeWarn=5

In case following exception occurs when processing 5 slaves all 10 threads are used, is it possible?
ConnectionI.cpp:148: Ice::ConnectTimeoutException: timeout while establishing a connection

Comments

  • Hi Oleh,

    the client thread pool is only used to process replies for AMI requests. That is, if a client sends an AMI request, the reply to that request is processed by the client thread pool in the client.

    The client thread pool is also used to handle incoming requests on a bidir connection. In other words, if your client opens a connection to a server, and the server uses that same connection to send a request to a callback object provided by the client, the incoming request is processed by a thread in the client thread pool.

    If neither of those two scenarios exists, the client thread pool is unused.

    The server thread pool handles incoming requests from clients. A thread is taken from the pool when a request arrives. That thread reads the request, unmarshals it, and then calls into the application code (the operation implementation). The thread returns to the pool when the operation implementation completes, after the thread has marshaled the reply and written in onto the wire.

    So, the number of threads used from the server thread pool is the number of calls that concurrently executing in the server.

    It's difficult to tell what is happening in your case without more detail. Are the operations in your server long-running, and is it possible that more than 10 operations are being invoked concurrently? If so, it's possible for the server to run out of threads. (However, in that case, you should see warnings logged by the server once 5 threads are in use.)

    I would suggest to track the number of concurrent invocations that are made by your clients and check that there are not more than you expect.

    I can only give very general advice with the information you have provided. But, if you can provide a self-contained example that illustrates the problem, we'd be happy to look at it.

    Cheers,

    Michi.