[
https://issues.apache.org/jira/browse/DIRMINA-78?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Emmanuel Lecharny closed DIRMINA-78.
------------------------------------
> ByteBuffer.wrap((byte[],?) The element of least suprise
> -------------------------------------------------------
>
> Key: DIRMINA-78
> URL: https://issues.apache.org/jira/browse/DIRMINA-78
> Project: MINA
> Issue Type: New Feature
> Affects Versions: 0.7.0, 0.7.1, 0.7.2, 0.7.3
> Reporter: Magnus Naeslund
> Assignee: Trustin Lee
> Priority: Minor
> Fix For: 0.7.4
>
> Attachments: mina-bytebuffer-wrap-example.diff,
> mina-bytebuffer-wrap-fix-1.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.
-
You can reply to this email to add a comment to the issue online.
