Pete,
Thanks for the reply.
>
> 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?
I am also not very sure that it is Protocol Encoding/Decosing, My
stack trace shows conistently the Encoder Write ops. I will test my
fix today and let you know more.
> * 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.
If you want real high-speed messaging, developing your own
ProtocolCodecFactory will certainly lead to higher performance.
I do have plan for doing a customized ProtocolCodecFactory after my
prototype. But I wanted to query is it safe in MINA-framework todo the
ObjectOutputStream.close in a low priority thread (apart from a
callee-thread).
