Unresponsive Server alert when .cfr file is called in Cold Fusion 9. The threads were killed by the monitor. Below is the stack trace. Could any experts point out the reason behind this server alert. Help much appreciated!
"Information","scheduler-0","12/04/20","05:43:27",,"Aborting request <path to my cfr> handled by thread jrpp-9 Java stack: java.util.HashMap.get(HashMap.java:303) at net.sf.jasperreports.engine.xml.JRElementFactory.createObject(JRElementFactory.java:100) at org.apache.commons.digester.FactoryCreateRule.begin(FactoryCreateRule.java:391) at org.apache.commons.digester.Digester.startElement(Digester.java:1563) at org.apache.xerces.parsers.AbstractSAXParser.startElement(Unknown Source) at org.apache.xerces.parsers.AbstractXMLDocumentParser.emptyElement(Unknown Source) at org.apache.xerces.impl.dtd.XMLDTDValidator.emptyElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanStartElement(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source) at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source) at org.apache.xerces.parsers.XMLParser.parse(Unknown Source) at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source) at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source) at org.apache.commons.digester.Digester.parse(Digester.java:1863) at net.sf.jasperreports.engine.xml.JRXmlLoader.loadXML(JRXmlLoader.java:240) at net.sf.jasperreports.engine.xml.JRXmlLoader.loadXML(JRXmlLoader.java:227) at net.sf.jasperreports.engine.xml.JRXmlLoader.load(JRXmlLoader.java:215) at coldfusion.runtime.report.Report.compileXml(Report.java:824) at coldfusion.runtime.report.Report.access$200(Report.java:87) at coldfusion.runtime.report.Report$3.fetch(Report.java:854) at coldfusion.util.SoftCache.get_statsOff(SoftCache.java:133) at coldfusion.util.SoftCache.get(SoftCache.java:81) at coldfusion.runtime.report.Report._compileReport(Report.java:273) at coldfusion.runtime.report.Report.compileReport(Report.java:173) at coldfusion.runtime.report.Report.runReport(Report.java:423) at coldfusion.filter.ComponentFilter.invoke(ComponentFilter.java:108) at coldfusion.filter.ApplicationFilter.invoke(ApplicationFilter.java:381) at coldfusion.filter.RequestMonitorFilter.invoke(RequestMonitorFilter.java:48) at coldfusion.filter.MonitoringFilter.invoke(MonitoringFilter.java:40) at coldfusion.filter.PathFilter.invoke(PathFilter.java:94) at coldfusion.filter.ExceptionFilter.invoke(ExceptionFilter.java:70) at coldfusion.filter.ClientScopePersistenceFilter.invoke(ClientScopePersistenceFilter.java:28) at coldfusion.filter.BrowserFilter.invoke(BrowserFilter.java:38) at coldfusion.filter.NoCacheFilter.invoke(NoCacheFilter.java:46) at coldfusion.filter.GlobalsFilter.invoke(GlobalsFilter.java:38) at coldfusion.filter.DatasourceFilter.invoke(DatasourceFilter.java:22) at coldfusion.xml.rpc.CFCServlet.invoke(CFCServlet.java:139) at coldfusion.xml.rpc.CFCServlet.doGet(CFCServlet.java:265) at javax.servlet.http.HttpServlet.service(HttpServlet.java:740) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:853) at coldfusion.bootstrap.BootstrapServlet.service(BootstrapServlet.java:89) at jrun.servlet.FilterChain.doFilter(FilterChain.java:86) at coldfusion.monitor.event.MonitoringServletFilter.doFilter(MonitoringServletFilter.java:42) at coldfusion.bootstrap.BootstrapFilter.doFilter(BootstrapFilter.java:46) at jrun.servlet.FilterChain.doFilter(FilterChain.java:94) at jrun.servlet.FilterChain.service(FilterChain.java:101) at jrun.servlet.ServletInvoker.invoke(ServletInvoker.java:106) at jrun.servlet.JRunInvokerChain.invokeNext(JRunInvokerChain.java:42) at jrun.servlet.JRunRequestDispatcher.invoke(JRunRequestDispatcher.java:286) at jrun.servlet.ServletEngineService.dispatch(ServletEngineService.java:543) at jrun.servlet.jrpp.JRunProxyService.invokeRunnable(JRunProxyService.java:203) at jrunx.scheduler.ThreadPool$ThreadThrottle.invokeRunnable(ThreadPool.java:428) at jrunx.scheduler.WorkerThread.run(WorkerThread.java:66)"
I read your Abuse report and I can't see any Sensitive information in your post above.
If you could make a reply to your original post, Blue Reply button under your original post, and Copy and Paste what you think is sensitive information I would happily remove it from the original post and the reply you make.
"Just Shoot Me", it's not clear who your comment here was to. I gather someone marked some reply of yours to be "abusive". I don't recall seeing it. Do you know who did? You refer to a "you" so perhaps you know who it was. If not, I don't know if we (as users) will ever know.
If you had offered an answer to anithav86922272's question, feel free to offer it again, as it does not appear here. Indeed, until the reply to them that I just offered, your comment here starting "I read your Abuse report" was the ONLY reply appearing in this thread. HTH.
[Removed at author's request]
Ah, so now I understand the earlier comment from "just shoot me". It must have been the post's author who was flagging the post for having what they regarded to be senstive data that they had mistakenly included in their post. They then asked for it to be removed (along with their request to do that. I'm only mentioning it here for context to future readers!).
Copy link to clipboard
anithav86922272, I don't know that we can make much from that stack trace alone. It's a point in time representation of what was going on at the time the request was terminated by the Server Monitor (and someone setting it up to do that, as an option).
As for finding why it had taken so long PRIOR to that point (which could be as much the problem as what was going on AT that point), I'm afraid the server monitor alert email you got doesn't help with that.
Have you not had the problem again since? Or if so, did it start happening in relation to any change? There's always an explanation, and there are ways to use monitoring tools to understand where and how requests are "taking too long".
But that old Server Monitor didn't help with that very well--and it was removed in CF2018, replaced by a new better monitor. I realize you won't be interested in that, being on CF9.
Instead, there is a tool which IS both more modern and capablel and CAN be used with CF9, called FusionReactor. And it offers a nice low-impact profiling feature that would identify exactly what and where within that request it was doing whatever made it run long. There's even a 14-day free trial of it, at fusion-reactor.com. There are still other tools, which instead profile the entire CF engine rather than on a per-request basis, which isn't as helpful.
Hope that helps you now or in the future. And FWIW, there are consultants (like myself) who can help you in solving such problems via direct, remote consulting. If interested, I list such people or companies at cf411.com/cftrouble. But you can ask follow-up questions here, of course, and I or others may chime in with more for you to consider.
Charlie, Thanks for your reply. Greatly appreciate your detailed explanation. The unresponsive server alert has not happened again. We will soon hopefully upgrade to CF2018. If it reoccurs, I will make use of Fusion Rector tool.