Mailing-List: contact dev-help@directory.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Apache Directory Developers List" <dev@directory.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of trustin@gmail.com designates
 64.233.182.207 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=M5QoGOGav1zXWuhatwkxzL7uljUpmYaHA8vvaxjQ5WEDs3kPBOCFKlWygTibZJ1Wls/lbfI6z5UdzTeesAm2110IDuZH/BTJshqv23hqFqqzzP8BlqBAWTX8CHhNlTwcNNBYFeuW+fm/2gpCwd1qiJ7P1wd49LIrjg+1xEAVCeQ=
Message-ID: <768dcb2e0602151542g5e74902aw58f94ac33cbe0dd3@mail.gmail.com>
Date: Thu, 16 Feb 2006 08:42:18 +0900
From: Trustin Lee <trustin@gmail.com>
To: Apache Directory Developers List <dev@directory.apache.org>
Subject: Re: [mina] Socket IO processor, thread problem.
In-Reply-To: <000501c63287$a7e5b220$0300a8c0@fedechiccowinxp>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_9404_28409290.1140046938086"
References: <510E6791-0FD2-49CB-9736-39261BBB367C@stain.org>
	 <001901c6326d$0d252500$0300a8c0@fedechiccowinxp>
	 <43F3A16E.7030203@trillian.se>
	 <000501c63287$a7e5b220$0300a8c0@fedechiccowinxp>

------=_Part_9404_28409290.1140046938086
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Fedechicco,

On 2/16/06, fedechicco@gmail.com <fedechicco@gmail.com> 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
> 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

------=_Part_9404_28409290.1140046938086
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Hi Fedechicco,<br><br><div><span class=3D"gmail_quote">On 2/16/06, <b class=
=3D"gmail_sendername"><a href=3D"mailto:fedechicco@gmail.com">fedechicco@gm=
ail.com</a></b> &lt;<a href=3D"mailto:fedechicco@gmail.com">fedechicco@gmai=
l.com
</a>&gt; wrote:</span><blockquote class=3D"gmail_quote" style=3D"border-lef=
t: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1=
ex;">I tried to change mina.socket.processor property to a polite value of =
10 (on
<br>a mono processor, for an average of 1000 sockets), and it was like I ho=
ped.<br>Actually it is useless to increase the mina.socket.processor, on my=
 mono CPU<br>obviously.<br>Now I tried to set false the&nbsp;&nbsp;SO_KEEP_=
ALIVE, I thought that on 1000 sockets
<br>it can be an enormouse series of little useless packets that make the<b=
r>selector work.<br>But I don't think that this can be the right solution.<=
/blockquote><div><br>I don't think so, either. <br></div><br><blockquote cl=
ass=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); mar=
gin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I'm not sure that the selector is the cause of the CPU leak, I only see on<=
br>the profiler that the poll() method of selector take the 99% of the time=
,<br>but I think that my profiler do not analyze the time spent waiting for=
 data
<br>from the time spent in other activities.<br>Said that I'm not sure that=
 the fault is of selector, but all the other<br>classes take a ridiculus pa=
rt of the cpu time ( less than 1% ).</blockquote><div><br>Why don't you cou=
nt the calls?&nbsp; If the count of=20
Selector.select() calls is exceptionally high, it means that the selector i=
s behaving wrong.<br><br>Can you reproduce this problem easily?&nbsp; I exp=
erienced this problem only in Windows very rarely.&nbsp; I found that Selec=
tor.selector
() returns immediately returning '0' even though I didn't call any Selector=
.wakeup(); it was an apparent JDK bug.<br><br>Please use the profiler to co=
und the number of calls.&nbsp; It will help us to debug the problem.&nbsp; =
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.
<br></div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I'd=
 like having a profiler that can distinguish between wait() and used<br>tim=
e, I'm using M10 integrated in NetBeans, somebody can advice me a better
<br>profiler?</blockquote><div><br>YourKit profiler is the best profiler I =
have ever used, but I think it also cannot distinguish it because the Selec=
tor implementation doesn't use Object.wait() at all.&nbsp; You have to coun=
t the calls anyway.
<br></div><br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px s=
olid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Fin=
ally, I must to send many ( the usual number of 1000 ) little<br>pre-prepar=
ed bytebuffers, and I initially wrote them one-by-one, but my
<br>tests went better (not good, but better) since I have done my own cicle=
 that<br>put all the little buffers in one big buffer, and then write() onl=
y the big<br>bytebuffer.<br>So, the non-written bytebuffers are no more rec=
ollected in a single big
<br>bytebuffer before to send them to the SocketChannel?</blockquote><div><=
br>What do you mean by 'recollected'?&nbsp; Does it mean 'pooled'?&nbsp; Th=
ey (small buffers) are pooled if you call ByteBuffer.release() explicitly i=
n case you didn't pass (write) them to MINA.
<br><br>HTH,<br>Trustin<br></div></div>-- <br>what we call human nature is =
actually human habit<br>--<br><a href=3D"http://gleamynode.net/">http://gle=
amynode.net/</a><br>PGP Key ID: 0xFE954E7E

------=_Part_9404_28409290.1140046938086--