Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Message-ID: <1296736002.1122145846428.JavaMail.jira@ajax.apache.org>
Date: Sat, 23 Jul 2005 21:10:46 +0200 (CEST)
From: "Magnus Naeslund (JIRA)" <jira@apache.org>
To: dev@directory.apache.org
Subject: [jira] Commented: (DIRMINA-78) ByteBuffer.wrap((byte[],?) The element
 of least suprise
In-Reply-To: <818874695.1122052798562.JavaMail.jira@ajax.apache.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

    [ http://issues.apache.org/jira/browse/DIRMINA-78?page=comments#action_12316600 ] 

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

Well, the more performant way of doing this would be to have a flag in DefaultByteBuffer that says wether to push the NIO buffer into the stack pool on release().

So when we're using wrap it would still pool the mina bytebuffer container as we do now, but release() would not  shove the NIO buffer back into the pool.

> 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