Skip to main content
A
Anonymous
December 4, 2020
Question

Unresponsive Server alert when .cfr file is called in Cold Fusion 9

  • December 4, 2020
  • 2 replies
  • 479 views

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)"

 

 

    This topic has been closed for replies.

    2 replies

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    December 10, 2020

    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 (troubleshooter, carehart. org)
    A
    Anonymous
    December 10, 2020

    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.

    Just Shoot Me
    Just Shoot Me
    Legend
    December 7, 2020

    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.

    Charlie Arehart
    Community Expert
    Charlie ArehartCommunity Expert
    Community Expert
    December 10, 2020

    "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.

    /Charlie (troubleshooter, carehart. org)
    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices