hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCORE-332) CPU spin in epollWait
Date Tue, 22 Jan 2013 00:02:14 GMT

    [ https://issues.apache.org/jira/browse/HTTPCORE-332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13559225#comment-13559225

Oleg Kalnichevski commented on HTTPCORE-332:


This is not the first time a epoll spinning issue has discovered in Java NIO. There has already
been one occasion when I had to put together a patch that worked around a similar epoll spinning
problem in earlier 1.6 JREs. That patch has never been committed to the official code line
due to a great deal of ugliness and extra complexity it would have introduced to the I/O reactor
code (as the I/O selector was no longer final which made more synchronization necessary).
I would _really_, _really_ hate having to put such a workaround to HttpCore. It will make
it slower and more error prone, especially under load. 

The last comment on the Netty issue #327 suggests that upgrade to the latest JRE 1.7 should
fix the problem ("... The good news is that after upgrading our softwares to jdk 1.7.0_11
the 100% cpu bug has disappeared..."). Could you please verify that?

> CPU spin in epollWait
> ---------------------
>                 Key: HTTPCORE-332
>                 URL: https://issues.apache.org/jira/browse/HTTPCORE-332
>             Project: HttpComponents HttpCore
>          Issue Type: Bug
>          Components: HttpCore NIO
>    Affects Versions: 4.2.3
>         Environment: jjdk 1.7.0_u10 
>            Reporter: dan jatnieks
> After applying the fix suggested in HTTPCORE-331, we encountered another instance of
a thread with CPU spin. The stack trace is:
> "Agent-005" prio=10 tid=0x00007f555c034800 nid=0xa54 runnable [0x00007f554848d000]
>    java.lang.Thread.State: RUNNABLE
>         at sun.nio.ch.EPollArrayWrapper.epollWait(Native Method)
>         at sun.nio.ch.EPollArrayWrapper.poll(EPollArrayWrapper.java:228)
>         at sun.nio.ch.EPollSelectorImpl.doSelect(EPollSelectorImpl.java:81)
>         at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:87)
>         - locked <0x000000073a32d220> (a sun.nio.ch.Util$2)
>         - locked <0x000000074e332670> (a java.util.Collections$UnmodifiableSet)
>         - locked <0x00000007426f4b58> (a sun.nio.ch.EPollSelectorImpl)
>         at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:98)
>         at org.apache.http.impl.nio.reactor.AbstractIOReactor.execute(AbstractIOReactor.java:259)
>         at org.apache.http.impl.nio.reactor.BaseIOReactor.execute(BaseIOReactor.java:106)
>         at org.apache.http.impl.nio.reactor.AbstractMultiworkerIOReactor$Worker.run(AbstractMultiworkerIOReactor.java:604)
>         at java.lang.Thread.run(Thread.java:722)
>         at com.electriccloud.util.EcThread.run(EcThread.java:84)
>    Locked ownable synchronizers:
>         - None
> Google led us to a report of a bug in java 6/7 in the epoll implementation on linux:
> Is it possible for HttCore to apply a similar approach to avoid this issue?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message