You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by yueyu lin <po...@gmail.com> on 2007/07/19 13:28:58 UTC
About the Selector.select(int timeOut) issue
Have you ever meet this thing?
When the application server use Selector.select(int timeOut) instead of
Selector.select() and when the server has low burden, suddenly it will cause
the CPU to 100% usage. The highest part is I/O wait while there is no
connection connected with the server.
I noticed that will happen randomly. Sometimes it will recover and sometimes
it will recover until there is new connection incoming.
When I'm using Selector.select(), it never happens again.
How about your experience?
--
--
Yueyu Lin
Re: About the Selector.select(int timeOut) issue
Posted by Trustin Lee <tr...@gmail.com>.
Hi Yueyu,
On 7/20/07, yueyu lin <po...@gmail.com> wrote:
> In that post, I felt some confused.
> According Alan's description, it is caused because the sudden connection
> reset while the underlying file descriptor had no interested events
> registered for the selector. But in all NIO based applications(at least what
> I saw), only one thread may handle the register operation. Even in one loop
> a channel cancel its registers, it will at least hold one interest (OP_READ)
> or it will recover the (OP_READ) in the next loop(unregister OP_READ to
> prevent the duplicated events fire). So it will in fact eliminate the
> problem.
> Another difference is that in my test, the loop is still hang but the CPU
> usage in increasing and the status show it's in "i/o wait". The trigger to
> the problem is the same: the client connection is suddenly closed. But this
> scenario will recover soon. What's your opinions? I can then post some
> example codes.
Any example code is appreciated. Please create a JIRA issue so I can
run it by myself. I feel like I'd rather not put the workaround into
MINA for now though.
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: About the Selector.select(int timeOut) issue
Posted by yueyu lin <po...@gmail.com>.
In that post, I felt some confused.
According Alan's description, it is caused because the sudden connection
reset while the underlying file descriptor had no interested events
registered for the selector. But in all NIO based applications(at least what
I saw), only one thread may handle the register operation. Even in one loop
a channel cancel its registers, it will at least hold one interest (OP_READ)
or it will recover the (OP_READ) in the next loop(unregister OP_READ to
prevent the duplicated events fire). So it will in fact eliminate the
problem.
Another difference is that in my test, the loop is still hang but the CPU
usage in increasing and the status show it's in "i/o wait". The trigger to
the problem is the same: the client connection is suddenly closed. But this
scenario will recover soon. What's your opinions? I can then post some
example codes.
On 7/20/07, Trustin Lee <tr...@gmail.com> wrote:
>
> On 7/20/07, yueyu lin <po...@gmail.com> wrote:
> > You are so right.
> > I found it in the bug database here
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6525190
> > and
> > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
>
> It seems like the bug has been fixed and the fix will be included in
> Java 6 update 3, and probably Java 5 update 13.
>
> Workaround is described in detail here:
>
> http://forum.java.sun.com/thread.jspa?threadID=5135128
>
> It's easy to apply the workaround, but what would be performance
> impact when applying the workaround? Should we just wait for the next
> Java release or not?
>
> Trustin
> --
> what we call human nature is actually human habit
> --
> http://gleamynode.net/
> --
> PGP Key ID: 0x0255ECA6
>
--
--
Yueyu Lin
Re: About the Selector.select(int timeOut) issue
Posted by Trustin Lee <tr...@gmail.com>.
On 7/20/07, yueyu lin <po...@gmail.com> wrote:
> You are so right.
> I found it in the bug database here
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6525190
> and
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
It seems like the bug has been fixed and the fix will be included in
Java 6 update 3, and probably Java 5 update 13.
Workaround is described in detail here:
http://forum.java.sun.com/thread.jspa?threadID=5135128
It's easy to apply the workaround, but what would be performance
impact when applying the workaround? Should we just wait for the next
Java release or not?
Trustin
--
what we call human nature is actually human habit
--
http://gleamynode.net/
--
PGP Key ID: 0x0255ECA6
Re: About the Selector.select(int timeOut) issue
Posted by yueyu lin <po...@gmail.com>.
You are so right.
I found it in the bug database here
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6525190
and
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933
On 7/19/07, Maarten Bosteels <mb...@gmail.com> wrote:
>
> Have you searched for a bug report in
> http://bugs.sun.com/bugdatabase/index.jsp ?
>
> Maarten
>
> On 7/19/07, 向秦贤 <fy...@gmail.com> wrote:
> >
> > Right, maybe you can try it with a simple select style server with a
> > blocking client,
> > to check out if that case can repeat.
> >
> >
> > 2007/7/19, yueyu lin <po...@gmail.com>:
> > >
> > > Yes, I know about the internal codes. But it does happen.
> > > The most strange thing is that it was in "i/o wait" status. This may
> be
> > > caused by the "poll" system call, I guess so.
> > > I didn't try the JDK1.6 that is using "epoll" system call.
> > >
> > > On 7/19/07, 向秦贤 <fy...@gmail.com> wrote:
> > > >
> > > > Hi,
> > > > Selector.select() = Selector.internalSelect(-1)
> > > > Selector.select(int>-1) = Selector.internalSelect(int>-1)
> > > > If just from code view, no big difference.
> > > > os related?
> > > > And you sure that cause by select()?
> > > >
> > > > Regards,
> > > >
> > > > 2007/7/19, yueyu lin <po...@gmail.com>:
> > > > >
> > > > > Have you ever meet this thing?
> > > > > When the application server use Selector.select(int timeOut)
> instead
> > > of
> > > > > Selector.select() and when the server has low burden, suddenly it
> > will
> > > > > cause
> > > > > the CPU to 100% usage. The highest part is I/O wait while there is
> > no
> > > > > connection connected with the server.
> > > > > I noticed that will happen randomly. Sometimes it will recover and
> > > > > sometimes
> > > > > it will recover until there is new connection incoming.
> > > > > When I'm using Selector.select(), it never happens again.
> > > > > How about your experience?
> > > > >
> > > > > --
> > > > > --
> > > > > Yueyu Lin
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > 向秦贤
> > > >
> > >
> > >
> > >
> > > --
> > > --
> > > Yueyu Lin
> > >
> >
> >
> >
> > --
> > 向秦贤
> >
>
--
--
Yueyu Lin
Re: About the Selector.select(int timeOut) issue
Posted by Maarten Bosteels <mb...@gmail.com>.
Have you searched for a bug report in
http://bugs.sun.com/bugdatabase/index.jsp ?
Maarten
On 7/19/07, 向秦贤 <fy...@gmail.com> wrote:
>
> Right, maybe you can try it with a simple select style server with a
> blocking client,
> to check out if that case can repeat.
>
>
> 2007/7/19, yueyu lin <po...@gmail.com>:
> >
> > Yes, I know about the internal codes. But it does happen.
> > The most strange thing is that it was in "i/o wait" status. This may be
> > caused by the "poll" system call, I guess so.
> > I didn't try the JDK1.6 that is using "epoll" system call.
> >
> > On 7/19/07, 向秦贤 <fy...@gmail.com> wrote:
> > >
> > > Hi,
> > > Selector.select() = Selector.internalSelect(-1)
> > > Selector.select(int>-1) = Selector.internalSelect(int>-1)
> > > If just from code view, no big difference.
> > > os related?
> > > And you sure that cause by select()?
> > >
> > > Regards,
> > >
> > > 2007/7/19, yueyu lin <po...@gmail.com>:
> > > >
> > > > Have you ever meet this thing?
> > > > When the application server use Selector.select(int timeOut) instead
> > of
> > > > Selector.select() and when the server has low burden, suddenly it
> will
> > > > cause
> > > > the CPU to 100% usage. The highest part is I/O wait while there is
> no
> > > > connection connected with the server.
> > > > I noticed that will happen randomly. Sometimes it will recover and
> > > > sometimes
> > > > it will recover until there is new connection incoming.
> > > > When I'm using Selector.select(), it never happens again.
> > > > How about your experience?
> > > >
> > > > --
> > > > --
> > > > Yueyu Lin
> > > >
> > >
> > >
> > >
> > > --
> > > 向秦贤
> > >
> >
> >
> >
> > --
> > --
> > Yueyu Lin
> >
>
>
>
> --
> 向秦贤
>
Re: About the Selector.select(int timeOut) issue
Posted by 向秦贤 <fy...@gmail.com>.
Right, maybe you can try it with a simple select style server with a
blocking client,
to check out if that case can repeat.
2007/7/19, yueyu lin <po...@gmail.com>:
>
> Yes, I know about the internal codes. But it does happen.
> The most strange thing is that it was in "i/o wait" status. This may be
> caused by the "poll" system call, I guess so.
> I didn't try the JDK1.6 that is using "epoll" system call.
>
> On 7/19/07, 向秦贤 <fy...@gmail.com> wrote:
> >
> > Hi,
> > Selector.select() = Selector.internalSelect(-1)
> > Selector.select(int>-1) = Selector.internalSelect(int>-1)
> > If just from code view, no big difference.
> > os related?
> > And you sure that cause by select()?
> >
> > Regards,
> >
> > 2007/7/19, yueyu lin <po...@gmail.com>:
> > >
> > > Have you ever meet this thing?
> > > When the application server use Selector.select(int timeOut) instead
> of
> > > Selector.select() and when the server has low burden, suddenly it will
> > > cause
> > > the CPU to 100% usage. The highest part is I/O wait while there is no
> > > connection connected with the server.
> > > I noticed that will happen randomly. Sometimes it will recover and
> > > sometimes
> > > it will recover until there is new connection incoming.
> > > When I'm using Selector.select(), it never happens again.
> > > How about your experience?
> > >
> > > --
> > > --
> > > Yueyu Lin
> > >
> >
> >
> >
> > --
> > 向秦贤
> >
>
>
>
> --
> --
> Yueyu Lin
>
--
向秦贤
Re: About the Selector.select(int timeOut) issue
Posted by yueyu lin <po...@gmail.com>.
Yes, I know about the internal codes. But it does happen.
The most strange thing is that it was in "i/o wait" status. This may be
caused by the "poll" system call, I guess so.
I didn't try the JDK1.6 that is using "epoll" system call.
On 7/19/07, 向秦贤 <fy...@gmail.com> wrote:
>
> Hi,
> Selector.select() = Selector.internalSelect(-1)
> Selector.select(int>-1) = Selector.internalSelect(int>-1)
> If just from code view, no big difference.
> os related?
> And you sure that cause by select()?
>
> Regards,
>
> 2007/7/19, yueyu lin <po...@gmail.com>:
> >
> > Have you ever meet this thing?
> > When the application server use Selector.select(int timeOut) instead of
> > Selector.select() and when the server has low burden, suddenly it will
> > cause
> > the CPU to 100% usage. The highest part is I/O wait while there is no
> > connection connected with the server.
> > I noticed that will happen randomly. Sometimes it will recover and
> > sometimes
> > it will recover until there is new connection incoming.
> > When I'm using Selector.select(), it never happens again.
> > How about your experience?
> >
> > --
> > --
> > Yueyu Lin
> >
>
>
>
> --
> 向秦贤
>
--
--
Yueyu Lin
Re: About the Selector.select(int timeOut) issue
Posted by 向秦贤 <fy...@gmail.com>.
Hi,
Selector.select() = Selector.internalSelect(-1)
Selector.select(int>-1) = Selector.internalSelect(int>-1)
If just from code view, no big difference.
os related?
And you sure that cause by select()?
Regards,
2007/7/19, yueyu lin <po...@gmail.com>:
>
> Have you ever meet this thing?
> When the application server use Selector.select(int timeOut) instead of
> Selector.select() and when the server has low burden, suddenly it will
> cause
> the CPU to 100% usage. The highest part is I/O wait while there is no
> connection connected with the server.
> I noticed that will happen randomly. Sometimes it will recover and
> sometimes
> it will recover until there is new connection incoming.
> When I'm using Selector.select(), it never happens again.
> How about your experience?
>
> --
> --
> Yueyu Lin
>
--
向秦贤