[Bug 2955] Resource leak in IPC subsystem

[bugzilla-daemon at icedtea.classpath.org]

http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=2955

--- Comment #8 from Elliott Baron <ebaron at redhat.com> ---
(In reply to Severin Gehwolf from comment #7)
> (In reply to Elliott Baron from comment #1)
> > Alternatively, we could use the approach you mentioned of using a separate
> > connection for each send operation. I don't believe any additional API is
> > needed to make this work. I think the following should be sufficient:
> > > ClientIPCService ipcService = ClientIPCServiceFactory.getIPCService(ipcConfig);
> > > ByteChannel channel = ipcService.connectToServer(socketName);
> > > channel.write(...);
> > > channel.close();
> 
> I believe patch in comment 6 would do this, but it does not fix the resource
> leak. Thoughts?

After investigating, I believe I've figured out the problem. A new instance of
ThermostatHelper is not only created for each send operation, it is created for
every time sleep is called. The Byteman rule we're using invokes send for every
10 times that sleep is called. This means only 1 out of 10 sockets is closed if
we try to close only when send is called. Another small issue with the patch in
comment 6, is that there is an early return statement in the for-loop that
prevents close from being called unless an exception occurs.

Here is another patch that appears to fix the resource leak. The idea is to
create the transport in the send method instead of the constructor. I had to
add some synchronization to the close method, but if we intend to have a
separate connection per send operation, we could remove most (or all) of the
synchronization in Transport.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20160512/bcf74261/attachment-0001.html>