mina-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "向秦贤" <fya...@gmail.com>
Subject Re: Out Of Memory Problem Again
Date Sat, 21 Jul 2007 05:50:19 GMT
Not sure your jdk version.
http://issues.apache.org/jira/browse/DIRMINA-320 not running in jdk6.
Try run in jdk6 to check it out whether happen again.
There a sure thing, some direct buffer reference hold by application. vm
cannot clean it.

2007/7/21, mat <forum.maillist@gmail.com>:
>
> http://issues.apache.org/jira/browse/DIRMINA-320
>
> Please check this out. It seems that i am not the only one who faces this
> problem and it happens in mina core. I quote something written by Trustin.
> "Other session might have allocated huge memory block and other session
> might be being affected by its side-effect. " However, I only had one
> client
> connecting to my server when OOM occurs.
>
> On 7/21/07, 向秦贤 <fyaoxy@gmail.com> wrote:
> >
> > Maybe Direct buffer not released.
> > Direct buffer must explicit release.
> > so somewhere may check if direct buffer and set to null.
> >
> > 2007/7/21, mat <forum.maillist@gmail.com>:
> > >
> > > I captured the exception message.
> > >
> > > org.apache.mina.common.support.DefaultExceptionMonitor exceptionCaught
> > > Unexpected exception.
> > > java.lang.OutOfMemoryError: Direct buffer memory
> > > at java.nio.Bits.reserveMemory
> > > at java.nio.DirectByteBuffer.<init>
> > > at java.nio.ByteBuffer.allocateDirect
> > > at sun.nio.ch.Util.getTemporaryDirectBuffer
> > > at sun.nio.ch.IOUtil.write
> > > at sun.nio.ch.SocketChannelImpl.write
> > > at org.apache.mina.transport.socket.nio.SocketIOProcessor.doFlush<
> > > SocketIoProcessor.java:428>
> > > at org.apache.mina.transport.socket.nio.SocketIOProcessor.doFlush<
> > > SocketIoProcessor.java:366>
> > > at org.apache.mina.transport.socket.nio.SocketIOProcessor.access$600<
> > > SocketIoProcessor.java:44>
> > > at org.apache.mina.transport.socket.nio.SocketIoProcessor$Worker.run<
> > > SocketIoProcessor.java:509>
> > > at org.apache.mina.util.NamePreservingRunnable.run<
> > > NamePreservingRunnable.java:43>
> > > at java.util.concurrent.ThreadPoolExecutor$Worker.runTask
> > > at java.util.concurrect.ThreadPoolExecutor$Worker.run
> > > at java.lang.Thread.run
> > >
> > >
> > > On 7/20/07, Luis Neves <luis.neves@co.sapo.pt> wrote:
> > > >
> > > > Hi,
> > > >
> > > > mat wrote:
> > > > > My server sometimes faced "OOM" problem. (I couldn't profile it
> > since
> > > > TPTP
> > > > > crashed my server before OOM occured). I didn't see major memory
> > leak
> > > > when
> > > > > profiling. Therefore, I believe OOM happens when READ or WRITE
> > > operation
> > > > > can't handle the incoming messages or outgoing messages. (However
> my
> > > > > incoming messages normally 20 * 512bytes/sec, NOT too fast,
> right?).
> > > > Last
> > > > > time i saw my server memory usage is over 600MB in windows XP.
> > > >
> > > > Your code is broken ... the question is where. Mina can handle that
> > > amount
> > > > of
> > > > messages without breaking a sweat.
> > > > Do you have some kind of heavy processing in the receiving end that
> > > delays
> > > > the
> > > > acceptance of messages?
> > > >
> > > > Did you try to use the ReadThrottleFilter?
> > > > How are you doing you writes?
> > > > A simple "iosession.write()" ?
> > > > Did you try something like:
> > > > WriteFuture wf = iosession.write();
> > > > wf.join();
> > > >
> > > > Can we see the code of your Encoder/Decoder?
> > > >
> > > >
> > > > --
> > > > Luis Neves
> > > >
> > >
> >
> >
> >
> > --
> > 向秦贤
> >
>



-- 
向秦贤
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message