Re: Possible Memory leak with ByteBuffer.putObject

[peter royal]

On May 24, 2006, at 2:00 PM, G.S.S. Mahadevan wrote:

The problem with ObjectOutputStream is well documented in web. One

good link is: http://www.javaspecialists.co.za/archive/ newsletter.do?issue=088&locale=en_US

In ByteBuffer.putObject, the ObjectOutputStream anyhow is going to be
garbage collected. But it seems for longer operations/large number of
calls, one needs to call reset/close on ObjectOutputStream to avoid a

memory leak. (http://bugs.sun.com/bugdatabase/view_bug.do? bug_id=4363937)

My question are:
* Am I missing something ?

I think so? Every call to putObject uses a new OOS, so I'm not sure what effect the small change you had made? Have you use a profiler, such as http://yourkit.com/ , to see where the memory is actually being retained?

* Is this problem is  faced by any body earlier ?
* If I donot want to call ObjectOutputStream.close in finally
block(to avoid latency on the ByteBuffer.putObject callee), can  I
call it in separate Thread/pool ?  Calling ObjectOutputStream.close in
separate thread later will  cause any problems with ByteBuffer bytes.

-pete

--
[EMAIL PROTECTED] - http://fotap.org/~osi

If you want real high-speed messaging, developing your own ProtocolCodecFactory will certainly lead to higher performance.

smime.p7s
Description: S/MIME cryptographic signature