简体   繁体   中英

“Broken Pipe” between Apache and GlassFish when using mod_jk

I am using Apache as the front-end to GlassFish 3.1, using mod_jk as the connector. The connection between the two is very unstable - works about 50% of the time - even when I am the only person on the system. When the problem occurs, the browser gives me an HTTP timeout and the GlassFish server has two types exceptions in its log:

java.io.IOException
at org.apache.jk.common.JkInputStream.receive(JkInputStream.java:249)
at org.apache.jk.common.JkInputStream.refillReadBuffer(JkInputStream.java:309)
at org.apache.jk.common.JkInputStream.doRead(JkInputStream.java:227)
at com.sun.grizzly.tcp.Request.doRead(Request.java:501)
at org.apache.catalina.connector.InputBuffer.realReadBytes(InputBuffer.java:336)
at com.sun.grizzly.util.buf.ByteChunk.substract(ByteChunk.java:431)
at org.apache.catalina.connector.InputBuffer.read(InputBuffer.java:357)
at org.apache.catalina.connector.CoyoteInputStream.read(CoyoteInputStream.java:265)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:264)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:306)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:158)
at java.io.InputStreamReader.read(InputStreamReader.java:167)
at com.ctc.wstx.io.MergedReader.read(MergedReader.java:101)
at com.ctc.wstx.io.ReaderSource.readInto(ReaderSource.java:84)
at com.ctc.wstx.io.BranchingReaderSource.readInto(BranchingReaderSource.java:57)
at com.ctc.wstx.sr.StreamScanner.loadMore(StreamScanner.java:967)
at com.ctc.wstx.sr.StreamScanner.getNext(StreamScanner.java:738)
at com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:1995)
at com.ctc.wstx.sr.BasicStreamReader.nextFromTree(BasicStreamReader.java:2647)
at com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1019)

java.net.SocketException: Broken pipe
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at org.apache.jk.common.ChannelSocket.send(ChannelSocket.java:580)
at org.apache.jk.common.JkInputStream.doWrite(JkInputStream.java:206)
at com.sun.grizzly.tcp.Response.doWrite(Response.java:685)
at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:420)

On the Apache side, the mod_jk log is completely empty. Once I hit this condition, the only way to recover is to restart the Apache server. The funny thing is that after the restart, the requests that timed out are automatically executed - magically. I have no idea who stores them.

Anyway, I am not at all experienced with Apache and mod_jk and was wondering where to start looking for problems. Software versions I am using are as follows:

Apache: version 2.2.17-2, GlassFish: 3.1, mod_jk: 1.2.30-1

Any help would be much appreciated!

Thanks.

Check the mod_jk logs for initialilzation of mod_jk during Apache startup. If no logs are written then something's wrong with the installation/configuration of mod_jk module.

Have you created a Glassfish cluster? If yes then set DjvmRoute and Dcom.sum.web.enterprise.jkenabled jvm options for the cluster and also check the http network listener on DAS host that needs to be created to listen requests from mod_jk (it is initially jk_disabled, so enable it).. If not then check the http network listener for mod_jk on each of the server domains on which you are deploying your application.

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM