Return-Path: Delivered-To: apmail-directory-dev-archive@www.apache.org Received: (qmail 53338 invoked from network); 19 Jul 2005 00:51:26 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 19 Jul 2005 00:51:25 -0000 Received: (qmail 65387 invoked by uid 500); 19 Jul 2005 00:51:23 -0000 Delivered-To: apmail-directory-dev-archive@directory.apache.org Received: (qmail 65280 invoked by uid 500); 19 Jul 2005 00:51:23 -0000 Mailing-List: contact dev-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Apache Directory Developers List" Delivered-To: mailing list dev@directory.apache.org Received: (qmail 65197 invoked by uid 99); 19 Jul 2005 00:51:23 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2005 17:51:23 -0700 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=HTML_40_50,HTML_MESSAGE,RCVD_BY_IP,SPF_HELO_PASS,SPF_PASS,URIBL_SBL X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates 64.233.184.194 as permitted sender) Received: from [64.233.184.194] (HELO wproxy.gmail.com) (64.233.184.194) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 18 Jul 2005 17:51:19 -0700 Received: by wproxy.gmail.com with SMTP id i25so1096685wra for ; Mon, 18 Jul 2005 17:51:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=TRZq74R9gIcu2zryZe6p+NKeSaipqK3iizGVJ78snvfDx+ZFasfLiWUT0+yZG5UrmvJcMczHU2yCEt+UTeMcYQ17Z8YXLASWkuM7MBJ2SlmONqzIcfeeXgnE2kVbDgzBlREGLgePczGKsKcnAwwrC1L1lS3CNJaL3MUAm4LEswo= Received: by 10.54.24.49 with SMTP id 49mr555898wrx; Mon, 18 Jul 2005 17:49:49 -0700 (PDT) Received: by 10.54.72.4 with HTTP; Mon, 18 Jul 2005 17:49:49 -0700 (PDT) Message-ID: <768dcb2e05071817491a19ba77@mail.gmail.com> Date: Tue, 19 Jul 2005 09:49:49 +0900 From: Trustin Lee Reply-To: Trustin Lee To: Apache Directory Developers List Subject: Re: [mina] ByteBuffer allocation memory leak Cc: Donovan Du Plessis In-Reply-To: <768dcb2e05071406321834b1eb@mail.gmail.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2847_26415753.1121734189745" References: <8DE3B7F7701E624B95DFA90DCB930D8707CD50@mailsrv.transwitch.co.za> <768dcb2e05071406321834b1eb@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_2847_26415753.1121734189745 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Any news on this issue? 2005/7/14, Trustin Lee : >=20 > Hi Donovan, >=20 > 2005/7/14, Donovan Du Plessis : > >=20 > > e.g. ByteBuffer buffer_ =3D ByteBuffer.allocate(lengthOfPacket); > >=20 >=20 > Do you call ByteBuffer.wrap() to wrap existing NIO buffer or byte array?= =20 > If so, it can cause memory leak. (Please see MINA ByteBuffer JavaDoc. You= 'll=20 > have to call buffer_.acquire() once to prevent the leak.) >=20 > If not, all newly allocated ByteBuffers are released to internal MINA=20 > ByteBufferPool. But it is not actually released, but hold by the pool=20 > forever. So in the short term, it can be look like a memory leak, but the= =20 > usage of memory will not increase after sufficient amount of buffers are= =20 > pooled by the MINA. If OutOfMemoryError occurs, please try to increase=20 > direct memory size of your VM like this: >=20 > java -XX:MaxDirectMemorySize=3D262144K ... >=20 > Please let me know the memory usage increases without limit even after=20 > following the instruction above. And it would be nice if which type of=20 > object is leaking. >=20 > Trustin > --=20 > what we call human nature is actually human habit > -- > http://gleamynode.net/=20 Trustin --=20 what we call human nature is actually human habit -- http://gleamynode.net/ ------=_Part_2847_26415753.1121734189745 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Any news on this issue?

2005/7/14, = Trustin Lee <trustin@gmail.com&= gt;:
Hi Donovan,

2005/7/14, Donovan Du Plessis <donovand@prism.co.za>:

e.= g. ByteBuffer buffer_ =3D ByteBuffer.allocate(lengthOfPacket);


Do you call ByteBuffer.wrap() to wrap existing NIO buffer or byte array?  If so, it can cause memory leak. (Please see MINA ByteBuffer JavaDoc.  You'll have to call buffer_.acquire() once to prevent the leak.)

If not, all newly allocated ByteBuffers are released to internal MINA ByteBufferPool.  But it is not actually released, but hold by the pool forever.  So in the short term, it can be look like a memory leak, but the usage of memory will not increase after sufficient amount of buffers are pooled by the MINA.  If OutOfMemoryError occurs, please try to increase direct memory size of your VM like this:

java -XX:MaxDirectMemorySize=3D262144K ...

Please let me know the memory usage increases without limit even after following the instruction above.  And it would be nice if which type of object is leaking.

Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.n= et/


Trustin
--
what we call human natu= re is actually human habit
--
http= ://gleamynode.net/ ------=_Part_2847_26415753.1121734189745--