Обработчик 404 Висит на ColdFusion 10, отлично работает на ColdFusion 8

Question

У меня странная проблема с 404 страницами обработчика на нашем сервере ColdFusion 10. Вот предыстория:

1. Мы без проблем эксплуатируем 2 сервера ColdFusion 8 с балансировкой нагрузки.

2. Мы обновили один из этих двух серверов до ColdFusion 10, чтобы запустить обновление ColdFusion 10.

3. Я установил обновление 8 на сервере CF10, а также удалил и заново добавил разъемы.

4. Оба сервера работают под управлением Windows 2008 R2.

Я прочитал несколько сообщений на форуме, в которых сообщалось о проблемах людей, получающих проблемы с сбросом соединения со своими 404 страницами, но я не вижу этой конкретной проблемы. То, что я вижу, это зависшая тема в FusionReactor для файла 404.cfm. Вот пример трассировки стека, взятой из одного из этих зависших потоков:

Thread Stack Trace
Trace Time:   07:02:14.638 04-Mar-2013
Request ID:   179934
Script Name:  http://example.com/404.cfm?404;http://example.com:80/somemissingfile
Started:      06:07:17.581 04-Mar-2013
Exec Time:    3297057ms
Memory Used:  (32%)1,669,600KB
Memory Free:  3,539,295KB
Thread ID:    0x53de (21470)
Thread Name:  ajp-bio-8012-exec-86
Priority:     5
Hashcode:     1636847260
State:        RUNNABLE

"ajp-bio-8012-exec-86" daemon prio=5 runnable

java.net.SocketInputStream.socketRead0(SocketInputStream.java:???)[Native Method]
java.net.SocketInputStream.read(SocketInputStream.java:129)
org.apache.coyote.ajp.AjpProcessor.read(AjpProcessor.java:319)
org.apache.coyote.ajp.AjpProcessor.readMessage(AjpProcessor.java:445)
org.apache.coyote.ajp.AjpProcessor.receive(AjpProcessor.java:341)
org.apache.coyote.ajp.AbstractAjpProcessor.finish(AbstractAjpProcessor.java:1032)
org.apache.coyote.ajp.AbstractAjpProcessor.action(AbstractAjpProcessor.java:386)
org.apache.coyote.Response.action(Response.java:170)
org.apache.coyote.Response.finish(Response.java:276)
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:288)
org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:108)
com.intergral.fusionreactor.plugin.amf.InterposerOutputStream.close(InterposerOutputStream.java:104)
com.intergral.fusionreactor.trackedstream.TrackedStream.close(TrackedStream.java:113)
com.intergral.fusionreactor.filter.softkill.SoftKillResponseStream.close(SoftKillResponseStream.java:146)
com.intergral.fusionreactor.filter.FusionReactorResponseWrapper.finish(FusionReactorResponseWrapper.java:192)
com.intergral.fusionreactor.core.FusionReactor.finish(FusionReactor.java:683)
com.intergral.fusionreactor.filter.FusionReactorCoreFilter.doHttpServletRequest(FusionReactorCoreFilter.java:575)
com.intergral.fusionreactor.filter.FusionReactorCoreFilter.doFusionRequest(FusionReactorCoreFilter.java:337)
com.intergral.fusionreactor.filter.FusionReactorCoreFilter.doFilter(FusionReactorCoreFilter.java:246)
com.intergral.fusionreactor.filter.FusionReactorFilter.doFilter(FusionReactorFilter.java:121)
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169)
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168)
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98)
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:928)
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:414)
org.apache.coyote.ajp.AjpProcessor.process(AjpProcessor.java:204)
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:539)
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:298)
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:895)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:918)
java.lang.Thread.run(Thread.java:662)

Я пытался вручную убить эти темы с помощью FusionReactor, но они не умрут. Единственный способ очистить зависшие потоки - это перезапустить службу ColdFusion (что мне приходилось делать не реже одного раза в день с момента перехода на ColdFusion 10).

404 не делает ничего особенного, кроме запуска нашего стандартного пользовательского тега макета и отображения уведомления о том, что страница не найдена.

Глядя на дамп потока, выясняется, что ColdFusion завершил обработку и завершил заполнение буфера выводом, но не завершает отправку в браузер?

org.apache.coyote.ajp.AbstractAjpProcessor.finish(AbstractAjpProcessor.java:1032)
org.apache.coyote.ajp.AbstractAjpProcessor.action(AbstractAjpProcessor.java:386)
org.apache.coyote.Response.action(Response.java:170)
org.apache.coyote.Response.finish(Response.java:276)
org.apache.catalina.connector.OutputBuffer.close(OutputBuffer.java:288)
org.apache.catalina.connector.CoyoteOutputStream.close(CoyoteOutputStream.java:108)

Там есть много вещей о закрытии и завершении, но следующие шаги имеют больше чтения и ответов. Поэтому я не уверен, что может происходить здесь, но это определенно останавливает завершение нашей миграции на ColdFusion 10. Мне нужно выяснить, что именно вызывает эти зависшие темы.

Answer 1

Вы испытываете ту же ошибку, с которой я столкнулся в январе. Я зарегистрировал ошибку в базе ошибок Adobe:

https://bugbase.adobe.com/index.cfm?event=bug&id=3494728

Их команда инженеров признала проблему, но ETA не было исправлено. Коннектор Adobe для IIS в CF10 доставил нам немало хлопот. Вы можете установить тайм-аут для уничтожения этих зависших потоков, как указано в моем временном решении, которое по крайней мере избавит вас от необходимости ежедневно перезагружать сервер. Удачи!