A couple days ago, GE posted a document with a JBOSS configuration change to address a specific crash. The document can be found here: https://engage.gehealthcare.com/docs/DOC-151626.
We applied this and it had a very negative impact on the PM side of the application. I didn't get any complaints about the chart, but it's possible that is affected as well. Lots of pages loaded part way and HTTP_Unknown errors, etc after applying this "fix." We'll be rolling it back over the weekend and I submitted a case to GE to let them know. Just wanted to advise people here or our experience as well.
We had GE apply what we think these configs are last friday, before the release and it's been odd since. I'm not the guy that deals with this but I do know it's been running at 100% when doing its nightly processes and yesterday the JBOSS decide dto reboot itself at 3pm, so you could imagine how that went over.
Thanks for the heads up....
GE does not believe the issues we experienced are related to the JBOSS configuration change (supposedly they've rolled this out to hundreds of clients), however, since it was the only change made at the time, I am not sure where else to look. I've given them the modified server.xml file as well as a couple of screenshots of the behavior. Maybe there is something else in our configuration or environment that did not play well with this change. We'll see what they come up with, but all I can say is we did not have positive results when we made this change and when we rolled it back, everything returned to normal. I'm curious to get the feedback of anyone else that has applied this JBOSS configuration change on CPS 12.
Also, adaniel - are you sure this was the change made for you or was it maybe something related to CQR? Our JBOSS servers are also slammed nightly at 8PM when the CQR jobs run. The more visits that happened during the day, the longer it takes. When we do not see patients on the weekend, we don't see the huge lengthy CPU spike each night. Don't ask me what it's doing that is so demanding or why it can't be throttled or run throughout the day to avoid the huge spike, but I've been told that this behavior is pretty normal.
mdoak - It is the CQR piece it's just before the changes that never happened. Of course GE has told us we need to up our ram to at least 40gb I believe my manage is bumping it to 64gb so we will see how that handles. The maxed CPU crushes our doctors trying to do nightly work, which is how we discovered it being maxed out now after the changes.
Let us know what happens when you add the RAM, but my personal experience tells me that you could add RAM to the JBoss server until you are blue in the face and it's not going make much difference. I started off with 24 gig as they recommended, but I honestly have seen no benefit in anything more than about 8 gig on the JBoss server. Talking with Virtual Officeware about what they allocate for their customers, they said the same thing. JBoss is typically using about 5.5 gig at steady state for us on our largest customer (~200+ concurrent users) and less than that (3-4 gig) on smaller customers. I've messed around with GE's sizing spreadsheet and tried plugging in their values for various JBoss configuration files (max threads, maxmem, etc) and I honestly find that none of it seems to make any great difference in performance or stability. Aside from the nightly CQR jobs (which lord knows what they are doing to require so much horsepower), our JBoss servers seem to be rather lightly loaded in terms of CPU/memory usage throughout the day.
I would love for the GE JBoss expert (assuming they have such a thing) to publish something explaining how these different values affect the system, how they impact eachother, what parts of the app use JBoss, what parts go directly to the database, what I have to do to make JBoss actually use the oodles of RAM it supposedly requires, but never seems to use, etc. Most of the online documentation about JBoss seems to be Linux based and it's hard to really match it up with how the Centricity app is using it. I can't help but think there is some opportunity for tuning, but you'd think the out of the box settings would be somewhat reasonably set too and wouldn't require too much tinkering by the customer.