[Bug 2955] Resource leak in IPC subsystem

bugzilla-daemon at icedtea.classpath.org bugzilla-daemon at icedtea.classpath.org
Thu May 12 07:26:54 UTC 2016


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

--- Comment #3 from Severin Gehwolf <sgehwolf at redhat.com> ---
(In reply to Elliott Baron from comment #1)
> It seems like every time the test program's sleep method is called and the
> Byteman rule is invoked, a new connection is made to the Unix socket. I
> believe this is due to a new instance of ThermostatHelper being created for
> each rule invocation.

Yes, that's what I've found. ThermostatHelper gets instantiated many times.

> How about we statically create the Transport, and use
> this one open connection for all subsequent invocations of that Byteman
> rule? I attached a short patch that does this, and the resource leak seems
> fixed.
> 
> 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 think I've tried this approach, by using try-with-resources. It didn't seem
to fix it.

> I believe reusing the same connection, as in the first approach, leads to
> less overhead for frequently executed Byteman rules (like the rule for the
> test program).

OK, I like this idea. I'll test it and will let you know. Thanks!

> There might be synchronization issues with this approach
> though, but I'm not familiar enough with Byteman to be sure either way. What
> do you think?

If there are such issues I'd prefer we fix them too ;-)

-- 
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/49755370/attachment-0001.html>


More information about the distro-pkg-dev mailing list