On 2/16/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]
> wrote:
I don't think so, either.
Why don't you count the calls? If the count of Selector.select() 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.
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.
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.
HTH,
Trustin
-- 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 CPU
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 Selector.select() 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.
HTH,
Trustin
what we call human nature is actually human habit
--
http://gleamynode.net/
PGP Key ID: 0xFE954E7E
