Re: [jetty-users] Re: [jetty-user] Acceptor thread taking nearly 100% CP

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

The primary recommendation I would give you is to get off of the
7.0.0pre5 release as there is no development on it and it has been
dead ever since we moved to eclipse for jetty7 and jetty8 early this
year

http://www.eclipse.org/jetty/downloads.php

latest version is 7.0.1.v20091125

the latest releases have some solutions for these issues

cheers,
jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx



On Mon, Nov 30, 2009 at 12:08, Doug Daniels <daniels.douglas@xxxxxxxxx> wrote:
> Is there any more information on a workaround for this issue?
>
> I'm using Jetty 7.0.0pre5 and seeing this issue sometimes (I know that's a
> deadend release and we plan on upgrading one of these days), I was wondering
> as a last ditch effort is there any way through JMX to disconnect all
> sockets and kill the thread pool and restart it (I guess you might as well
> restart the whole web server but then you'd lose all session state etc.).
>>
>> Thanks for getting back to me. Serge contacted me before raising that bug
>> to see if I'd got anywhere with it (unfortunately not).
>>
>> Yes, i noticed the loop that was working around a JVM bug in Jetty 6.
>>
>> Jetty 6 has a sleep:
>> http://www.mortbay.org/jetty/jetty-6/xref/org/mortbay/io/nio/SelectorManager.html#425
>>
>> Jetty 7 references a Sun bug *
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6403933*
>> http://www.mortbay.org/jetty/jetty-7/xref/org/mortbay/io/nio/SelectorManager.html#399
>> which is fixed in the JVM I'm using
>>
>> Serge found a different (not-fixed) bug which might give similar symtoms
>> but not be exactly the same. In this case, an exception is thrown from the
>> select call, which I think will bypass the the Jetty 6/7 workaround. He also
>> found a patch for another project that works around this new (unfixed) bug.
>> http://mail-archives.apache.org/mod_mbox/incubator-etch-commits/200902.mbox/%3C20090...@xxxxxxxxxxxxxxx%3E
>>
>> Unfortunately I'll have other problems if I flip back to Java 1.5.
>>
>> On Thu, Mar 5, 2009 at 3:34 PM, Greg Wilkins <gre...@xxxxxxxxxxx> wrote:
>>
>> Chris,
>>
>> sorry your post slipped by with nobody responding to it!
>>
>> I JIRA has been raised which points out your post:
>> http://jira.codehaus.org/browse/JETTY-937
>>
>> I had known about this issue and there is code in Jetty that attempts to
>> detect the loop and "fix" it by cancelling the key. This definitely used to
>> work, so something has changed that so that we no longer detect it, or
>> perhaps the cancelling of the key is not sufficient.
>>
>> Unfortunately we are too deep into the 6.1.15 cycle to try to fix it in
>> this release (hey Sun can do release after release and not fix to root cause
>> so why can't we :)
>>
>> But we'll try to work on a new work around soon.
>>
>> In the meantime, perhaps use 1.5 ?
>>
>> cheers
>>
>> Chris Sewart wrote:
>>
>> I'm seeing a situation on our server where Jetty's acceptor thread is
>> using nearly 100% CPU. As far as I can tell it is just spinning so it is
>> relatively harmless as other threads get time, but makes monitoring actual
>> server loading a bit hard! Looking at the mailing lists and JIRA there seem
>> to have been a few similar issues reported in the past but they look to be
>> resolved. I can see nothing in the change logs between the release we're
>> using and the latest that says to me any relevant fixes and I can't /easily/
>> update Jetty just to see if it works so I thought I'd ask. We're running:
>>
>> Jetty 6.1.11 JDK 1.6.0_11 CentOS 5.2 (2.6.18-92.1.18.el5)
>>
>> We had this on the past on a four core box but it solved itself after a
>> day or so. Since we have switched to an 8 core box the problem is permanent.
>> Happens some time after startup. Jstack for the offending thread:
>>
>> "btpool2-3 - Acceptor0 SelectChannelConnector@0.0.0.0:80 <
>> http://SelectChannelConnector@0.0.0.0:80>" prio=10 tid=0x00002aacb79c0000
>> nid=0x2a8d runnable [0x000000004252c000..0x 000000004252ca10]
>> java.lang.Thread.State: RUNNABLE at java.lang.Object.notify(Native Method)
>> at
>> org.mortbay.thread.QueuedThreadPool$PoolThread.dispatch(QueuedThreadPool.java:583)
>> - locked <0x00002aacafa97670> (a
>> org.mortbay.thread.QueuedThreadPool$PoolThread) at
>> org.mortbay.thread.QueuedThreadPool.dispatch(QueuedThreadPool.java:114) at
>> org.mortbay.jetty.nio.SelectChannelConnector$1.dispatch(SelectChannelConnector.java:86)
>> at
>> org.mortbay.io.nio.SelectChannelEndPoint.dispatch(SelectChannelEndPoint.java:67)
>> at
>> org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:476)
>> at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:167) at
>> org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
>> at
>> org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:707)
>> at
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:488)
>>
>> It's a plan HTTP acceptor (not SSL) but it is using Continuations.
>>
>> Any advice or suggestions appreciated.
>>
>> Thanks,
>>
>> Chris
>>
>> P.S. First post to the mailing list after years of using Jetty. Compact,
>> easy to use, powerful, used it for all sorts of things. Great product! :-)
>>
>> --------------------------------------------------------------------- To
>> unsubscribe from this list, please visit:
>>
>> http://xircles.codehaus.org/manage_email
>
> ~ doug daniels
>
> _______________________________________________
> jetty-users mailing list
> jetty-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/jetty-users
>
>