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 <[EMAIL PROTECTED]> wrote:
Have you searched for a bug report in http://bugs.sun.com/bugdatabase/index.jsp ? Maarten On 7/19/07, 向秦贤 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > 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, 向秦贤 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>: > > > > > > > > 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
