Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 6.1.4
-
Fix Version/s: None
-
Component/s: NIO
-
Labels:None
-
Environment:Windows XP, Java 1.6.0_01-b06
-
Number of attachments :
Description
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.
Christian,
that stack trace is totally normal and that is where I would expect the acceptor thread to be.
the blocking on the other hand, is not normal.
Can you capture one of these events with tcpdump or wireshark or similar.
Can you also reproduce in a simply small webapp that you can attach to this issue?
finally, can you go to the about:config page of your firefox and report the value of
network.http.pipelining. You can try switching that value and see if that changes anything.
regards