I'm using Apache because the front-finish to GlassFish 3.1, using mod_jk because the connector. The bond between your two is extremely unstable - works about 50% of times - even if I'm alone around the system. Once the problem happens, the browser provides me with an HTTP timeout and also the GlassFish server has two sorts exceptions in the 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)

Around the Apache side, the mod_jk log is totally empty. After I hit this problem, the only method to recover would be to restart the Apache server. The funny factor is the fact that following the restart, the demands that timed out are instantly performed - like magic! I've no clue who stores them.

Anyway, I'm not whatsoever familiar with Apache and mod_jk and wondered how to start searching for problems. Software versions I'm using are the following:

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

Any help could be much appreciated!

Thanks.

Look into the mod_jk logs for initialilzation of mod_jk throughout Apache startup. If no logs are written then something's wrong using the installation/configuration of mod_jk module.

Perhaps you have produced a Glassfish cluster? If so then set DjvmRoute and Dcom.sum.web.enterprise.jkenabled jvm choices for the cluster as well as look into the http network listener on DAS host that should be produced to pay attention demands from mod_jk (it's initially jk_disabled, so enable it).. Otherwise then look into the http network listener for mod_jk on each one of the server domain names which you're implementing the application.