[jetty-discuss] [jira] Commented: (JETTY-380) SelectChannelConnector blocks for maxIdleTime ms

[Christian d'H. (JIRA) <ji...@co...>]

    [ http://jira.codehaus.org/browse/JETTY-380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100760 ] 

Christian d'Heureuse commented on JETTY-380:
--------------------------------------------

I can confirm that the error is fixed with this code modification.
Thank you very much for the quick solution.

> SelectChannelConnector blocks for maxIdleTime ms
> ------------------------------------------------
>
>                 Key: JETTY-380
>                 URL: http://jira.codehaus.org/browse/JETTY-380
>             Project: Jetty
>          Issue Type: Bug
>          Components: NIO
>    Affects Versions: 6.1.4
>         Environment: Windows XP, Java 1.6.0_01-b06
>            Reporter: Christian d'Heureuse
>            Assignee: Greg Wilkins
>            Priority: Critical
>
> When I press the Refresh button in Firefox, the browser sends 18 HTTP GET requests to my servlet application (for alls the GIFs, Stylesheets and Scripts that are references by the page). Firefox seems to use two TCP connections, because some requests are processed in parallel. (The Jetty server and the Firefox browser run on the same Windows-XP machine).
> Often, but not always, Jetty blocks for SelectChannelConnector.maxIdleTime milliseconds during these requests.
> I tried different Jetty versions.
> The effect does not occur for: 6.0.0 and 6.0.1.
> It occurs for 6.0.2, 6.1.0, 6.1.1 and 6.1.4.
> When I use SocketConnector instead of SelectChannelConnector, the effect does not occur.
> While the connection is blocked (until the timeout occurs after maxIdleTime ms), other parallel requests are possible, but it has strange effects on the i/o operations of other threads. Sometimes it blocks console i/o and even loading Java class code from disk seems to be affected.
> When I press Ctrl-Break during the blocking, the following stack trace is displayed for the SelectChannelConnector thread:
> "btpool0-9 - Acceptor0 SelectChannelConnector@0.0.0.0:8080" prio=6 tid=0x0e38ac00 nid=0x1b0 runnable [0x0e7cf000..0x0e7cfa14]
> java.lang.Thread.State: RUNNABLE
>  at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll0(Native Method)
>  at sun.nio.ch.WindowsSelectorImpl$SubSelector.poll(WindowsSelectorImpl.java:274)
>  at sun.nio.ch.WindowsSelectorImpl$SubSelector.access$400(WindowsSelectorImpl.java:256)
>  at sun.nio.ch.WindowsSelectorImpl.doSelect(WindowsSelectorImpl.java:137)
>  at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
>  - locked <0x045c5568> (a sun.nio.ch.Util$1)
>  - locked <0x045c5578> (a java.util.Collections$UnmodifiableSet)
>  - locked <0x045c54f0> (a sun.nio.ch.WindowsSelectorImpl)
>  at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
>  at org.mortbay.io.nio.SelectorManager$SelectSet.doSelect(SelectorManager.java:432)
>  at org.mortbay.io.nio.SelectorManager.doSelect(SelectorManager.java:169)
>  at org.mortbay.jetty.nio.SelectChannelConnector.accept(SelectChannelConnector.java:124)
>  at org.mortbay.jetty.AbstractConnector$Acceptor.run(AbstractConnector.java:516)
>  at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)
> Jetty does not print any error messages (even with -DDEBUG=1) and after the timeout everything continues normal.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira