The system sends me emails a couple of times a day with a subject (and body) of...
"Login URL is not accessible. The users are unable to login."
However, our external monitoring system (Nagios) doesn't suggest the URL has become unavailable, when I check with my browser it's available, and I'm not getting any reports from users that they are having problems.
Please can you let me know how I can disable these annoying e-mails, and perhaps investigate how it could come to be generating false positives randomly like it does.
Thanks.
This email is sent when Rollbase checks the status of its components and finds some are unresponsive. Can you see any error in the Rollbase logs?
Can't see a rollbase log anywhere, but the Tomcat log has a shed-load of these...
Nov 30, 2013 7:28:48 AM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load com.sun.org.apache.xerces.internal.impl.dv.dtd.DTDDVFactoryImpl. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1587)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
at com.sun.org.apache.xerces.internal.utils.ObjectFactory.findProviderClass(ObjectFactory.java:324)
at com.sun.org.apache.xerces.internal.utils.ObjectFactory.newInstance(ObjectFactory.java:269)
at com.sun.org.apache.xerces.internal.utils.ObjectFactory.newInstance(ObjectFactory.java:255)
at com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance(DTDDVFactory.java:63)
at com.sun.org.apache.xerces.internal.impl.dv.DTDDVFactory.getInstance(DTDDVFactory.java:49)
at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.<init>(XML11Configuration.java:565)
at com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration.<init>(XIncludeAwareParserConfiguration.java:130)
at com.sun.org.apache.xerces.internal.parsers.XIncludeAwareParserConfiguration.<init>(XIncludeAwareParserConfiguration.java:91)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.<init>(DOMParser.java:138)
at com.sun.org.apache.xerces.internal.parsers.DOMParser.<init>(DOMParser.java:122)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.<init>(DocumentBuilderImpl.java:120)
at com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl.newDocumentBuilder(DocumentBuilderFactoryImpl.java:76)
at p23.a144.getDocumentBuilder(a144.java:30)
at p23.a144.parse(a144.java:49)
at p23.a144.parse(a144.java:57)
at p24.a41.checkStatus(a41.java:281)
at p24.a40.checkStatuses(a40.java:94)
at p25.a49.doJob(a49.java:58)
at com.rb.util.system.a115.run(a115.java:37)
Nov 30, 2013 7:28:48 AM org.apache.catalina.loader.WebappClassLoader findResourceInternal
INFO: Illegal access: this web application instance has been stopped already. Could not load META-INF/services/javax.xml.parsers.DocumentBuilderFactory. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
Nov 30, 2013 7:28:48 AM org.apache.catalina.loader.WebappClassLoader loadClass
INFO: Illegal access: this web application instance has been stopped already. Could not load com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl. The eventual following stack trace is caused by an error thrown for debugging purposes as well as to attempt to terminate the thread which caused the illegal access, and has no functional impact.
java.lang.IllegalStateException
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1587)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1546)
at javax.xml.parsers.FactoryFinder.getProviderClass(FactoryFinder.java:112)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:178)
at javax.xml.parsers.FactoryFinder.newInstance(FactoryFinder.java:147)
at javax.xml.parsers.FactoryFinder.find(FactoryFinder.java:265)
at javax.xml.parsers.DocumentBuilderFactory.newInstance(DocumentBuilderFactory.java:121)
at p23.a144.getDocumentBuilder(a144.java:28)
at p23.a144.parse(a144.java:49)
at p23.a144.parse(a144.java:57)
at p24.a41.checkStatus(a41.java:281)
at p24.a40.checkStatuses(a40.java:94)
at p25.a49.doJob(a49.java:58)
at com.rb.util.system.a115.run(a115.java:37)
This article details how to access the various Rollbase logs: knowledgebase.progress.com/.../000044096
Hello,
Use CleckLoginURL XML attribute in components.xml for ROUTER component to disable such notifications.
Thanks.
Haha. 'CleckLoginURL'. Not often I come across typos in configuration keys for production software :)
Anyway, thanks for the logfile pointer! That's a bit of a revelation.
So, I can now see why it's failing...
[2013-12-03 04:56:22,138] ===> Error in thread StatusChecker at 12/03/2013 04:56 AM: Login URL is not accessible
[2013-12-03 04:56:22,138] javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)
at sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1886)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:276)
at sun.security.ssl.Handshaker.fatalSE(Handshaker.java:270)
at sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1341)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:153)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:868)
at sun.security.ssl.Handshaker.process_record(Handshaker.java:804)
at sun.security.ssl.SSLSocketImpl.readRecord(SSLSocketImpl.java:1016)
at sun.security.ssl.SSLSocketImpl.performInitialHandshake(SSLSocketImpl.java:1312)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1339)
at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:1323)
at sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:515)
at sun.net.www.protocol.https.AbstractDeleg
I guess this means the Java VM doesn't know about or trust DigiCert's public signing certificate. If anyone else is getting this, you will probably need to check/update the certificates your Tomcat service is using with the Java 'keystore' tool, documented elsewhere.
In our case, we have independent servers monitoring our key URLs, so I've simply told it to stop Clecking ;^)
Thanks, guys.