directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Trustin Lee <>
Subject Re: [mina] Socket IO processor, thread problem.
Date Wed, 15 Feb 2006 23:42:18 GMT
Hi Fedechicco,

On 2/16/06, <> wrote:
> I tried to change mina.socket.processor property to a polite value of 10
> (on
> a mono processor, for an average of 1000 sockets), and it was like I
> hoped.
> Actually it is useless to increase the mina.socket.processor, on my mono
> obviously.
> Now I tried to set false the  SO_KEEP_ALIVE, I thought that on 1000
> sockets
> it can be an enormouse series of little useless packets that make the
> selector work.
> But I don't think that this can be the right solution.

I don't think so, either.

I'm not sure that the selector is the cause of the CPU leak, I only see on
> the profiler that the poll() method of selector take the 99% of the time,
> but I think that my profiler do not analyze the time spent waiting for
> data
> from the time spent in other activities.
> Said that I'm not sure that the fault is of selector, but all the other
> classes take a ridiculus part of the cpu time ( less than 1% ).

Why don't you count the calls?  If the count of calls is
exceptionally high, it means that the selector is behaving wrong.

Can you reproduce this problem easily?  I experienced this problem only in
Windows very rarely.  I found that Selector.selector() returns immediately
returning '0' even though I didn't call any Selector.wakeup(); it was an
apparent JDK bug.

Please use the profiler to cound the number of calls.  It will help us to
debug the problem.  If it's easy to reproduce it by myself with one or two
commodity PCs, I can test it by myself and track down the problem.

I'd like having a profiler that can distinguish between wait() and used
> time, I'm using M10 integrated in NetBeans, somebody can advice me a
> better
> profiler?

YourKit profiler is the best profiler I have ever used, but I think it also
cannot distinguish it because the Selector implementation doesn't use
Object.wait() at all.  You have to count the calls anyway.

Finally, I must to send many ( the usual number of 1000 ) little
> pre-prepared bytebuffers, and I initially wrote them one-by-one, but my
> tests went better (not good, but better) since I have done my own cicle
> that
> put all the little buffers in one big buffer, and then write() only the
> big
> bytebuffer.
> So, the non-written bytebuffers are no more recollected in a single big
> bytebuffer before to send them to the SocketChannel?

What do you mean by 'recollected'?  Does it mean 'pooled'?  They (small
buffers) are pooled if you call ByteBuffer.release() explicitly in case you
didn't pass (write) them to MINA.

what we call human nature is actually human habit
PGP Key ID: 0xFE954E7E

View raw message