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

Question

Я запускаю онлайн-приложение на базе 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 дня, пытаясь выяснить это, но все еще застрял. Я не использую продолжение где-либо явно в приложении.

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

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

С уважением,

Михаил Зисковский

Answer 1

Второй DefaultServlet должен иметь еще 1 init-param ...

<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, что более соответствует тому, как ведут себя нормальные сервлеты.