directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Magnus Naeslund (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DIRMINA-78) ByteBuffer.wrap((byte[],?) The element of least suprise
Date Fri, 22 Jul 2005 17:30:46 GMT
    [ http://issues.apache.org/jira/browse/DIRMINA-78?page=comments#action_12316483 ] 

Magnus Naeslund commented on DIRMINA-78:
----------------------------------------

Maybe i should mention that the patch is totally untested :)

> ByteBuffer.wrap((byte[],?) The element of least suprise
> -------------------------------------------------------
>
>          Key: DIRMINA-78
>          URL: http://issues.apache.org/jira/browse/DIRMINA-78
>      Project: Directory MINA
>         Type: New Feature
>     Reporter: Magnus Naeslund
>     Assignee: Trustin Lee
>     Priority: Minor
>  Attachments: mina-bytebuffer-wrap-example.diff
>
> *This is just an discussion, not a bug*
> The problem:
> When mina wraps (buffers or arrays) external data, it keeps push()ing the nio buffer
to the stacks of buffers, but it can't reuse them when wrapping  (since they either already
exist or was created from nio wrap()).
> This could be fixed in two ways: 
> 1)  When wrapping, re-use buffers as usual, con: extra copy
> 2) Have a flag that causes the underlying nio buffer to not be pooled after release
> I would rather see minas bytebuffer to copy the data than cause an memory leak.
> I've just debugged a project that writes byte arrays (old code, needs to write arrays),
and found the memory leak that is (kind of) described in the mina ByteBuffer  documentation.
I ended up with a unbounded leak of nio HeapByteBuffers.
> I know that this is discouraged in the documentation, but I don't like these kind of
suprises that you get from using mina without carefully reading the documentation (note that
the javadoc warning isn't at the method level).
> It's like the close(true) that doesn't flush the buffers before closing the session (I
can't understand why anyone wants it the way it is now).
> I know copy it's slower, but if you're using wrap(), you'll need to do something like
that anyways...
> I implemented the copy for byte arrays as an example, because it is the least modification,
I'll attach it to this issue.
> So after this little rant, what do you think about this suggestion?
> Regards,
> Magnus Naeslund
> Magnus

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message