«Разбитая труба» между Apache и GlassFish при использовании mod_jk - PullRequest
0 голосов
/ 28 апреля 2011

Я использую Apache в качестве внешнего интерфейса для GlassFish 3.1, используя mod_jk в качестве соединителя. Связь между ними очень нестабильная - работает около 50% времени - даже когда я единственный человек в системе. Когда возникает проблема, браузер выдает мне тайм-аут HTTP, а сервер GlassFish имеет два типа исключений в своем журнале:

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)

На стороне Apache журнал mod_jk полностью пуст. Как только я столкнулся с этим условием, единственный способ восстановить это перезапустить сервер Apache. Самое смешное, что после перезапуска тайм-ауты автоматически выполняются - волшебным образом! Понятия не имею, кто их хранит.

Во всяком случае, у меня нет опыта работы с Apache и mod_jk, и мне было интересно, с чего начать поиск проблем. Версии программного обеспечения, которые я использую, следующие:

Apache: версия 2.2.17-2, GlassFish: 3.1, mod_jk: 1.2.30-1

Любая помощь будет высоко ценится!

Спасибо.

1 Ответ

1 голос
/ 23 августа 2011

Проверьте журналы mod_jk для инициализации mod_jk во время запуска Apache.Если логи не пишутся, значит что-то не так с установкой / настройкой модуля mod_jk.

Вы создали кластер Glassfish?Если да, то установите параметры DjvmRoute и Dcom.sum.web.enterprise.jkenabled jvm для кластера, а также проверьте прослушиватель сети http на хосте DAS, который необходимо создать для прослушивания запросов от mod_jk (это изначально jk_disabled, поэтому включите его)Если нет, то проверьте http-прослушиватель сети на наличие mod_jk на каждом из доменов сервера, на котором вы развертываете свое приложение.

...