Как решить проблему взаимоблокировки в ColdFusion 9: coldfusion.util.AbstractCache$Lock ⇐ JAVA

[Anonymous]

Я пытался решить проблему, из-за которой выполнение определенных сценариев приводило к взаимоблокировке, переводя все последующие запросы в подвешенное состояние, используя 99,9 % ресурсов ЦП и, в конечном итоге, приводя к сбою сервера.

Вот пример трассировки стека для одного из запросов, который был помещен в подвешенное состояние (вечное ожидание):

Код: Выделить всё

Thread Stack Trace
Trace Time: 21:00:44.463 06-Jun-2012
Request ID: 6131
Script Name: http://www.example.com/allreviews.cfm
Started: 21:00:21.225 06-Jun-2012
Exec Time: 23238ms
Memory Used: (24%)230,667KB
Memory Free: 701,428KB
Thread ID: 0x191e (6430)
Thread Name: jrpp-494
Priority: 5
Hashcode: 1081611879
State: WAITING

"jrpp-494" prio=5 in Object.wait()

java.lang.Object.wait(Object.java:???)[Native Method]
- waiting on  (a coldfusion.util.AbstractCache$Lock)
java.lang.Object.wait(Object.java:485)
coldfusion.util.AbstractCache.fetch(AbstractCache.java:46)
coldfusion.util.SoftCache.get_statsOff(SoftCache.java:133)
coldfusion.util.SoftCache.get(SoftCache.java:81)
coldfusion.runtime.TemplateClassLoader.findClass(TemplateClassLoader.java:609)
coldfusion.runtime.RuntimeServiceImpl.getFile(RuntimeServiceImpl.java:785)
coldfusion.runtime.RuntimeServiceImpl.resolveTemplatePath(RuntimeServiceImpl.java:766)
coldfusion.tagext.lang.CustomTag.setName(CustomTag.java:21)
cfApplication2ecfm456206189._factor0(/srv/www/htdocs/www.example.com/www/Application.cfm:28)
cfApplication2ecfm456206189.runPage(/srv/www/htdocs/www.example.com/www/Application.cfm:1)
coldfusion.runtime.CfJspPage.invoke(CfJspPage.java:231)
coldfusion.tagext.lang.IncludeTag.doStartTag(IncludeTag.java:416)
coldfusion.filter.CfincludeFilter.invoke(CfincludeFilter.java:65)
coldfusion.filter.CfincludeFilter.include(CfincludeFilter.java:33)
coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:279)
coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48)
coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40)
coldfusion.filter.PathFilter.invoke(PathFilter.java:94)
coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70)
coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28)
coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38)
coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46)
coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38)
coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22)
coldfusion.filter.CachingFilter.invoke(CachingFilter.java:62)
coldfusion.CfmServlet.service(CfmServlet.java:200)
coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89)
jrun.servlet.FilterChain.doFilter(FilterChain.java:86)
com.intergral.fusionreactor.filter.FusionReactorCoreFilter.doHttpServletRequest(FusionReactorCoreFilter.java:503)
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)
jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42)
coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46)
jrun.servlet.FilterChain.doFilter(FilterChain.java:94)
jrun.servlet.FilterChain.service(FilterChain.java:101)
jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106)
jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42)
jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286)
jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543)
jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203)
jrunx.scheduler.ThreadPool$DownstreamMetrics.invokeRunnable(ThreadPool.java:320)
jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428)
jrunx.scheduler.ThreadPool$UpstreamMetrics.invokeRunnable(ThreadPool.java:266)
jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)

Если вам интересно, вы можете увидеть полную трассировку стека с тем, что я назову «скриптом блокировки» вверху, и всеми остальными, ожидающими его.

Когда я впервые столкнулся с этой проблемой, у меня не было трассировки стека. Я разместил вопрос: «Когда ColdFusion максимально нагружает процессор, как мне узнать, что он жует/дыхает?». Я получил много полезных ответов и, просмотрев трассировки стека, смог определить, что это были одни и те же три сценария, которые снова и снова вызывали эту проблему взаимоблокировки.

В каждом случае верхняя строка «скрипта блокировки» гласит:

Код: Выделить всё

coldfusion.compiler.ClassReader.skipFully(ClassReader.java:79)

И все другие запросы, забитые за ним, имеют следующую строку в соответствующих трассировках стека:

Код: Выделить всё

- waiting on  (a coldfusion.util.AbstractCache$Lock)

Меня беспокоило то, почему не соблюдался тайм-аут моего запроса; эти сценарии просто будут висеть вечно и никогда не умрут. ВТФ, да? Поэтому мне пришлось сделать это самому. Итак, когда я уничтожу «сценарий блокировки», остальные высвободятся из подвешенного состояния. В этот момент, если время ожидания запроса истекло, они завершают обработку, а если оно превышено (что обычно происходит у большинства из них), то они просто переходят к тайм-ауту. Но они не истекают по тайм-ауту сами по себе, и запросы просто накапливаются до тех пор, пока активные потоки не будут использованы, очередь потоков не заполнится и все не зависнет.

Уничтожать их вручную каждый раз, когда они запрашиваются, очевидно, не является решением, поэтому, как всегда напоминает мне моя жена: «отладка, отладка, отладка». Используя условный , я прошел через него и обнаружил, что он прошел весь путь через Application.cfm, через мой header.cfm и вплоть до проблемы. сценарий. Если я помещу внутри проблемного сценария (даже на самом верху), он не прервется и произойдет взаимоблокировка. Если я поставлю его непосредственно перед включением, запрос прервется и проблема взаимоблокировки будет решена. Странно.

Между этими двумя местами нет никакого кода, верно? Непосредственно перед включением и внутри него должно быть функционально эквивалентно, не так ли? Вероятно, нет, потому что там явно что-то происходит.

Я не использую теги . Происходящая блокировка, по-видимому, происходит на уровне кэша шаблонов. Такое же поведение наблюдается независимо от того, отмечены ли параметры «Надежный кеш», «Шаблон кэша в запросе» или «Кэш компонента» в администраторе (в любой комбинации отмеченных/снятых флажков). Я очистил кеш шаблона и кэш компонента каждый более одного раза. Я перезапускал сервер CF снова и снова... все безрезультатно.

Во время устранения неполадок я прочитал эту статью, описывающую аналогичную проблему с блокировка кеша компилятора в CF8 (8.0.1) вместе с инструкциями по применению патча для ее исправления. Но это не CF9... поэтому, очевидно, я не могу применить их патч.
Что делать? Кто-нибудь еще сталкивался с этой проблемой...И есть ли решение?

Подробнее здесь: https://stackoverflow.com/questions/109 ... ctcacheloc