Hi,
sporadically GF instance is throwing "java.io.IOException: Broken
pipe" exception and stops accept incoming http requests.
Don’t know how to reproduce it in test env. Within last four months
this problem occurred twice - once with Grizzly 1.0.33 and once with
1.0.34_SNAPSHOT.
Glassfish was pretty busy when the problem has happend (it is a prod
system; serving > 20.000 SOAP requests/hour/jvm).
Workaround:
- Grizzly has to be re-deployed (for example by changing number of
processing threads via admin console) – after that GF will start to
accept new requests.
My configuration:
Linux 2.6.20, x86_64
Java HotSpot(TM) 64-Bit Server VM;1.5.0_22
GlassFish Enterprise Server v2.1.1 ((v2.1 Patch06)(9.1_02 Patch12))
(build b31g-fcs)
Grizzly 1.0.34-SNAPSHOT running on Linux-2.6.20 under JDK version:
1.5.0_22-Sun Microsystems Inc.
maxThreads: 150
ByteBuffer size: 4096
useDirectByteBuffer: 8192
maxKeepAliveRequests: 250
keepAliveTimeoutInSeconds: 30
Static File Cache enabled: true
Pipeline : com.sun.enterprise.web.portunif.PortUnificationPipeline
Round Robin Selector Algorithm enabled: true
Round Robin Selector pool size: 4
Asynchronous Request Processing enabled: false
Exception:
[#||SEVERE|sun-appserver2.1|javax.enterprise.system.container.web|
_ThreadID=27;_ThreadName=Selecto
rThread-50001;_RequestID=0a95fc27-6f2e-408f-aaa1-165a38cb2201;|
WEB0756: Caught exception during HTTP processing.
java.io.IOException: Broken pipe
at sun.nio.ch.PollArrayWrapper.interrupt(Native Method)
at
sun.nio.ch.PollArrayWrapper.interrupt(PollArrayWrapper.java:105)
at sun.nio.ch.PollSelectorImpl.wakeup(PollSelectorImpl.java:84)
at com.sun.enterprise.web.connector.grizzly.SelectorReadThread.addChannel
(SelectorReadThread.java:75)
at com.sun.enterprise.web.connector.grizzly.SelectorThread.handleAccept
(SelectorThread.java:1561)
at com.sun.enterprise.web.connector.grizzly.SelectorThread.handleConnection
(SelectorThread.java:1530)
at com.sun.enterprise.web.connector.grizzly.SelectorThread.doSelect
(SelectorThread.java:1434)
at com.sun.enterprise.web.connector.grizzly.SelectorThread.startListener
(SelectorThread.java:1325)
at com.sun.enterprise.web.connector.grizzly.SelectorThread.startEndpoint
(SelectorThread.java:1288)
at
com
.sun
.enterprise
.web.connector.grizzly.SelectorThread.run(SelectorThread.java:1264)
|#]
Judging from the thread dumps, all the selector-Threads were free,
Example:
Thread "SelectorReaderThread-50001" thread-id 12,288 thread-
stateRUNNABLERunning in native
at: sun.nio.ch.PollArrayWrapper.poll0(Native Method)
at: sun.nio.ch.PollArrayWrapper.poll(PollArrayWrapper.java:
100)
at:
sun.nio.ch.PollSelectorImpl.doSelect(PollSelectorImpl.java:56)
at:
sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
at: sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at: com.sun.enterprise.web.connector.grizzly.SelectorThread.doSelect
(SelectorThread.java:1410)
at: com.sun.enterprise.web.connector.grizzly.SelectorReadThread.startEndpoint
(SelectorReadThread.java:121)
at: com.sun.enterprise.web.connector.grizzly.SelectorThread.run
(SelectorThread.java:1264)
All the "worker" threads were imo also free (waiting on lock:
com.sun.enterprise.web.portunif.PortUnificationPipeline)
Example:
Thread "httpSSLWorkerThread-50001-16" thread-id 12,253 thread-
stateWAITINGWaiting on lock:
com.sun.enterprise.web.portunif.PortUnificationPipeline_at_8312c9d
at: java.lang.Object.wait(Native Method)
at: java.lang.Object.wait(Object.java:474)
at: com.sun.enterprise.web.connector.grizzly.LinkedListPipeline.getTask
(LinkedListPipeline.java:294)
at: com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run
(SSLWorkerThread.java:104)
Has anyone already run into this problem?
Do you have an idea, how to nail it down?
thanks for any hints,
makiey