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

Potential unclosed connections?

Hi Zeroc, I think I'm seeing an issue with unclosed connections when using per object adapter thread pools. I've attached a file zip of server.cpp which is a modification of demo/Ice/Hello/server.cpp. The file has been modified to create a number of object adapters each with their own thread pool. as follows:

adapterName = IceUtil::generateUUID();
property = adapterName + ".Endpoints";

communicator->getProperties()->setProperty(property, "tcp -p 0");

// Set the client thread pool.
// property = adapterName + ".ThreadPool.Client.Size";
// communicator->getProperties()->setProperty(property, "1");

// Set the server thread pool.
// property = adapterName + ".ThreadPool.Server.Size";
// communicator->getProperties()->setProperty(property, "1");

// Set the thread pool.
property = adapterName + ".ThreadPool.Size";
communicator->getProperties()->setProperty(property, "1");

// Create an object adapter.
adapter = communicator->createObjectAdapter(adapterName);

There are a few lines commented out right now, but with the lines

property = adapterName + ".ThreadPool.Size";
communicator->getProperties()->setProperty(property, "1");

left uncommented as it is right now, with each new object adapter there are socekts/connections still left established and listening with each iteration through the loop. Commenting out these lines and uncommenting the lines above that set the properties "adapterName.ThreadPool.Client.Size" and "adapterName.ThreadPoolServerSize" instead seems to create the threads (looking at thread counts), but the connections are closed with each iteration through the loop.

Not sure if this is an issue, but I felt I should report it and let you decide.

Regards --Roland


  • marc
    marc Florida
    The correct property to set is <adapter>.ThreadPool.Size. There are no properties <adapter>.ThreadPool.Client.Size or <adapter>.ThreadPool.Server.Size.

    Your code looks correct, we will look into why sockets are not closed. Which operating system / compiler did you use?
  • I am using Windows. I haven't verified Linux or any other OS. If you replace the server.cpp file in the hello directory with my attached one and rebuild setting a breakpoint at the top of the loop you should be able to re-create what I'm seeing. My code doesn't really do anything so it won't work with the hello client anymore. I just wrote this to demonstrate the condition what I was seeing in my application .

    I've been using the free utility fomr called "tcpview" and "process explorer" to look at connections and thread pool sizes. I'm also using netstat.

    Since my commented code is not that explains why the behaviour was the same. However, I thought that when I was looking at the number of threads being created that they were the same using the incorrect code or correct code. I'll go back and verify that.

    Thanks --Roland
  • Forgot to mention that I'm als using Ice ver 2.1.0. --Roland
  • mes
    mes California
    Hi Roland,

    Each Ice thread pool creates a pipe for internal purposes, and these are the sockets being reported by netstat. In src/Ice/ThreadPool.cpp, line 132, you'll see that Ice is not closing the file descriptors associated with the pipe, but only on Windows. In the past we encountered problems when closing these file descriptors on Windows, but I've just tried it with the code enabled and it appears to work fine. It's possible that the strange behavior we were seeing at the time we disabled this code on Windows was being caused by a different problem.

    Note that this resource leak would only pose a real problem if a server was creating many object adapters with their own thread pools.

    To fix the code, remove the #ifndef block at the location I mentioned above. The next release will include a similar change, assuming we don't encounter any problems during testing.

    - Mark
  • Hi Marc, Thanks for the update. It turns out that with my latest code changes I end up creating many object adapters dynamically, each with their own thread pool. We end up creating a separate connection (object adapter) for each "media"stream (graphics, audio, usb, input,...) and I wanted/needed to process each stream in parallel. Audio was the main reason. This object adapter strategy is working out very well! Which reminds me of a future request, which I should proabbly mention, regarding being able to control the thread priorities/scheduling of internal ice runtime threads.

    The way I read your response is I should re-build the Ice for Windows (only for Windows) with your #ifdef modification and hope that I don't run into the file descriptor issue. I'll try this out tomorrow and let you know how I make out.

    Again, thanks for the quick response.

    Regards --Roland
  • Hi Mark, I've re-built Ice with your suggested changes to ThreadPool.cpp and everything appears to work well. Connections are all closed when the object adapter is deactivated and I see no more resource leaks. I have not seen any issues so far, but my testing up to this point has been limited. Thanks again.

    Regards --Roland