Is anyone else suffering from this error? Have you done anything to minimize the occurrences? GE just says "Keep restarting Jboss until it starts working again". It sometimes takes about 5-7 tries until it starts working again. It sometimes occurs during the day, out of the blue, other times it is dead from the problem happening overnight. GE did kind of mention reinstalling Jboss. I haven't done that just yet because it is a known problem and GE support just mentioned that after prodding them about this issue. I don't get the feeling that it will be any better after a Jboss reinstall. I will do it if I am bored sometime after hours
Mike Zavolas
Tallahassee Neurological Clinic
Error below. All clients get this until I restart Jboss multiple times (my record is 7)
HTTP Status 500 -
--------------------------------------------------------------------------------
type Exception report
message
description The server encountered an internal error () that prevented it from fulfilling this request.
exception
org.apache.jasper.JasperException: java.lang.NullPointerException
org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:515)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:411)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
root cause
java.lang.NullPointerException
org.apache.xml.serializer.utils.DOM2Helper.getLocalNameOfNodeFallback(DOM2Helper.java:92)
org.apache.xml.serializer.utils.DOM2Helper.getLocalNameOfNode(DOM2Helper.java:74)
org.apache.xml.serializer.TreeWalker.startNode(TreeWalker.java:359)
org.apache.xml.serializer.TreeWalker.traverse(TreeWalker.java:145)
org.apache.xalan.transformer.TransformerIdentityImpl.transform(TransformerIdentityImpl.java:390)
com.gehcit.cp.client.CPClientConfig.getStringFromDocument(CPClientConfig.java:178)
com.gehcit.cp.client.CPClientConfig.(CPClientConfig.java:50)
org.apache.jsp.default_jsp._jspService(default_jsp.java:257)
org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369)
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:322)
org.apache.jasper.servlet.JspServlet.service(JspServlet.java:249)
javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
note The full stack trace of the root cause is available in the JBoss Web/2.1.10 logs.
--------------------------------------------------------------------------------
JBoss Web/2.1.10
ISSUE: HTTP Status 500 error
ACTION: Right click and Stop JBOSS Application Server Windows Service > Right click and Start JBOSS Service (if you get an error on either of these steps then stop and start again) > Wait about 3-4 minutes > Should now be able to login to Centricity
WORK-AROUND: Setup a Scheduled Task to restart JBOSS Service daily each morning prior to users logging in
It has happened on Monday afternoon after the weekly reboot occurs Monday morning.
I am looking for a more automated process if this is going to be the normal behavior in lieu of a GE fix. Something like a script which constantly queries the Jboss server for a HTTP 500 condition? If it happens the script will stop Jboss, then restart it. Now THAT would be a good solution if GE can't figure out how to fix.
how do you have your network setup? is the jboss on its on box or virtual? is the database together with the jboss? I have not had this issue, but I have both jboss and virtual on their own boxes. But it may sound like jboss might be losing connection to the database.
We had this issue frequently after upgrading to SP11 on CPS. The only reliable work around we found was to disable our CQR channel in Qvera and the subscriptions in CPS. In fact, that's the only way we were able to stabilize the system sufficiently to get any work done. GE support was very little help on this issue. We also had to re-install JBOSS 3 times prior to turning off CQR (twice by GE, once on our own). I realize this may not work for everyone, but it's what's worked for us until GE resolves other issues.
Both virtual/separate jboss and SQL servers. 12.0.11 (but he problem occurred before December when we installed the .11). I have a VMWare cluster and jboss/sql are on separate VMWare hosts
To be honest, most of the time I hear some of my clients have this type of issue is because the JBoss is on a virtual system. Not sure if that is the common denominator or not, but we've never had this issue and we have it running on a physical box.
We are on CPS12.0 SP11 Patch 6a and our servers are all virtualized and we do not experience this issue. We do have our Application and Interop servers separated though.
I have seen Apache Tomcat errors before in other systems and I wonder have you verified that your servers are using the correct version of Java?
Have encountered this twice this year, once in February and once last week. We upgraded to 12.0.11 in December. We're running JBoss on a VM.
I was intending to post this advice as a PSA. Make a backup copy of your JBoss folder. When it crashes with HTTP 500, stop the Jboss service. Rename the current jboss folder to jboss_crashed. Rename the copy to jboss. Make another copy of it just to be safe so you have an untouched backup. Start the JBoss service. That should get you up and running as fast as possible. I've encountered zero issues rolling the JBoss folder back to the earlier version.
Justin
I am going to try this next time it happens
Thanks
Clearing JBOSS Cache: HTTP-500 ERROR
Logon to: JBOSS Server
Stop JBOSS Service.
Navigate to:
C:\Program Files\Centricity Practice Solution\jboss\server\default\work\jboss.web\localhost\<CUSTOMER DB NAME>_cps\org\apache\jsp
Deleted everything in the JSP folder.
Go into Server Setup (SS) and set user defaults and set security.
Restart JBoss service.
Server Setup: On The JBOSS
Double-click the Server Setup icon on your Desktop or navigate to its location and open it.
Select Advanced Setup Options and then click Next.
Select Utilities and then click Next.
Confirm the log file path and click Next. The setup directory path is not required.
On the Server Logon window, select the server name for the server where the Centricity Practice Solution database is located. Leave the
name and password blank to use your Windows administrator credentials. Click Next.
On the Available Databases window, select a database to configure and click Next.
On the Utilities Options window, click Set User Defaults. A message alerts you when the process is complete.
To exit database utilities, do the following:
To close Server Setup, click Exit and then Yes.
We had this issue occurred this morning. After working with GE support, they have a JSP file that resolves the HTTP 500 error. After Stopping and Starting JBOSS, the JSP file must be dropped into the following directory,
c$\Program Files\Centricity Practice solution\jboss\server\default\deploy\yourDBname.war
Launch GE, and in the IE web address field reference the jsp file like: http://servername:9080/databasename/cps/66504.jsp
Close the window and re-launch GE. This worked for us.
I've run into this issue, usually several times a year, but nothing too crazy. It usually occurs overnight and I get an emergency call in the AM with the problem.
A couple of things - I found that to happen randomly, but have also seen a pattern where it happens after Windows Updates and how early the server reboots. We use LabTech to manage the server and install patches, which does reboot, but I found that just scheduling a second reboot during patch day an hour later (in our case around 5:00 AM), it have made the problem all but disappear.
Also something to note - a reboot may not be required. Others here say to wait 5-7 minutes after restarting the JBoss service before trying to open CPS again. This is definitely true. The server restarts rather quickly, but sometimes it takes anywhere from 5 to 8 minutes after the service starts to actually come back up fully. Just saying this so you're not mislead by services.msc saying that the service is "Running", when its really still starting up on the back end.
The 5-7 minutes isn't too crazy it just takes that long for JBOSS to get going though 7 sounds a little high. Ours is 3-5 minutes once JBOSS actually starts remember its normally set to delay so it waits 120 seconds after the server boots to start doing its thing.