Проблемы с Jetty, DefaultServlet, BlockingCallback и TimeoutException

Я запускаю онлайн-приложение на базе Jetty 9.1.0.RC1 (автономный дистрибутив).

Мой файл журнала заполняется следующими проблемами, возникающими случайным образом при обслуживании статического контента (файлы .js, .css, .png и т. д.):

2013-11-25 07:43:37.351:WARN:oejs.ServletHandler:qtp1207851091-422: /scripts/shared/channel/channel.public.js
java.io.IOException: java.util.concurrent.TimeoutException: Idle timeout expired: 75000/75000 ms
    at org.eclipse.jetty.util.BlockingCallback.block(BlockingCallback.java:101)
    at org.eclipse.jetty.server.HttpOutput.sendContent(HttpOutput.java:490)
    at org.eclipse.jetty.servlet.DefaultServlet.sendData(DefaultServlet.java:893)
    at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:499)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:696)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1566)
    at org.eclipse.jetty.websocket.server.WebSocketUpgradeFilter.doFilter(WebSocketUpgradeFilter.java:164)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1537)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:524)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:568)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:221)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1110)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:453)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1044)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:200)
    at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
    at org.eclipse.jetty.server.Server.handle(Server.java:442)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:279)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:213)
    at org.eclipse.jetty.io.AbstractConnection$1.run(AbstractConnection.java:505)
    at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:601)
    at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:532)
    at java.lang.Thread.run(Thread.java:722)
Caused by: 
java.util.concurrent.TimeoutException: Idle timeout expired: 75000/75000 ms
    at org.eclipse.jetty.io.IdleTimeout.checkIdleTimeout(IdleTimeout.java:153)
    at org.eclipse.jetty.io.IdleTimeout$1.run(IdleTimeout.java:50)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
    at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
    at java.util.concurrent.FutureTask.run(FutureTask.java:166)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178)
    at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
    at java.lang.Thread.run(Thread.java:722)

То же самое относится и к таким ресурсам, как:

2013-11-26 15:09:01.219:WARN:oejs.ServletHandler:qtp1207851091-629: /Resources/Audio/IncomingMessage.wav

2013-11-25 03:02:44.904:WARN:oejs.ServletHandler:qtp1207851091-408: /Resources/Website/Users/f3c68328-d739-4680-8144-a0db598dff6b/1384157586003.png

Я использую сервлет 3.0. Существует два экземпляра DefaultServlet, один из webdefault.xml, а другой из web.xml для обслуживания пользовательских изображений (которые не связаны с файлом .war).

Конфиг для первого DefaultServlet не изменен, последний выглядит следующим образом:

<servlet>
    <servlet-name>DefaultImagesServlet</servlet-name>
    <servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
    <init-param>
        <param-name>resourceBase</param-name>
        <param-value>/echat/static/</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>DefaultImagesServlet</servlet-name>
    <url-pattern>/Resources/*</url-pattern>
</servlet-mapping>

Я провел последние 3 дня, пытаясь понять это, но все еще застрял. Я не использую Продолжение нигде явно в приложении.

Проблема возникает только через несколько дней после (повторного) запуска причала.

Есть подсказка, где искать ответ? Кажется, я исчерпал все возможные варианты.

С уважением,

Майкл Жисковски


person Michael Zyskowski    schedule 27.11.2013    source источник


Ответы (1)


Второй DefaultServlet должен иметь еще 1 параметр инициализации...

<servlet>
    <servlet-name>DefaultImagesServlet</servlet-name>
    <servlet-class>org.eclipse.jetty.servlet.DefaultServlet</servlet-class>
    <init-param>
        <param-name>resourceBase</param-name>
        <param-value>/echat/static/</param-value>
    </init-param>
    <init-param>
        <param-name>pathInfoOnly</param-name> <!-- this should be set -->
        <param-value>true</param-value>
    </init-param>
</servlet>
<servlet-mapping>
    <servlet-name>DefaultImagesServlet</servlet-name>
    <url-pattern>/Resources/*</url-pattern>
</servlet-mapping>

Тайм-аут простоя, который вы видите, связан с активным (незакрытым) соединением, где в течение определенного периода времени ничего не происходит.

Кроме того, вы должны захватить HTTP-трафик, вероятно, что-то не так с запросами и тем, что возвращается. Особенно важно знать, относятся ли заголовки запроса/ответа к состоянию HTTP/1.0 и keep-alive или к состоянию HTTP/1.1 и плохому состоянию Connection.

Еще одна вещь, которую нужно сделать, это включить следующее ведение журнала на уровне отладки при тестировании (при использовании резервного ведения журнала StdErrLog в самой Jetty).

System.setProperty("org.eclipse.jetty.servlet.LEVEL","DEBUG");

Это покажет запрашиваемый ресурс и то, что пытается найти на диске.

Пример. Предположим, что исходная конфигурация DefaultImagesServlet у вас есть в вашем вопросе.

Запрос /Resources/scripts/main.js будет искать файл в вашей файловой системе как /echat/static/Resources/scripts/main.js. Это поведение согласуется с особыми требованиями к поведению сервлета спецификации "default" (именованного), отображенному в спецификации пути "/".

С настройкой pathInfoOnly запрос на /Resources/scripts/main.js будет извлекаться из файловой системы по адресу /echat/static/scripts/main.js, что больше соответствует тому, как ведут себя обычные сервлеты.

person Joakim Erdfelt    schedule 27.11.2013