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
-- 向秦贤
