You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2013/01/22 01:02:14 UTC
[jira] [Commented] (HTTPCORE-332) CPU spin in epollWait
[ 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:
--------------------------------------------
Dan,
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?
Oleg
> 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: https://github.com/netty/netty/pull/565
> 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