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'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% ).
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?
It is a fact that with 850-900 sockets things go well, but with 1000 I reach
teh 100% usage in less than an hour, and then all freeze, on my linux.
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?
