It's all about the answers!

Ask a question

Ever run into this error, only on webUI, accessing WI & queries? After a memory and Tomcat heap size upgrade?

long TRUONG (3654104140) | asked Dec 11 '15, 6:28 p.m.
 We have RTC(only WI in use) and RRC 5.0.2 on Window with Tomcat. SQLserver 2012 is our DB.
Just upgraded memory from 16GB to 24 GB on our VM, and Tomcat heap size to -Xmx12G, -Xms12G (default -Xmn512M was bumped previously to -Xmn2G), as per IBM recommendations.

Access via Eclipse clients and API are OK. But immediately get into this error, when trying to access a work item or query or running a query via webUI:


Work Items could not be loaded due to a syntax error or missing dependency.
Page ID:
Run the default action

If we do a WI quick search, we can see the WI details in the popup window when hover over one on the listed WI's, but an actual search would resolve into above errors.

This error is persistent over the client PC/laptop reboots. And we can reproduce this on IE9 (user on up to IE11) and Firefox; though not Chrome. However it is persistent on Chrome at least for 1 user.

We had also upgrade memory and Tomcat heap size on TST env to match with PRD (from 12GB/-Xmx6G) but that error did not show up.

long TRUONG commented Dec 11 '15, 7:38 p.m.

 We guess there would be nothing a(n emergency) reboot won't fix! :)

We just tried to restart the apps (with a reboot here) before submitting a PMR at severity 1. Phew! and it worked.

We, however, still like to hear experience, guesses (educated or wild or otherwise), discussions, comments on what had happened.

Donald Nong commented Dec 13 '15, 7:06 p.m.

If a reboot resolved the issue, it is quite likely related to the server cache (mismatched with the clients'). But I haven't seen the actual details as no one wants to spend the time and effort to figure it out - the ultimate "solution" may still be a reboot, so why bother?

long TRUONG commented Dec 13 '15, 9:50 p.m.

Thx Don,

We first thought it was just resuming a session on the client over a server reboot (client cache), till even a client reboot did not resolve the issue.

It might be server cache, however that must be a long live cache in conjunction with the memory upgrade, surviving the very first reboot after; as we actually rebooted the server to restart the apps to make the Tomcat  new heap size effective, shortly (minutes) after the live VM memory upgrade.

Be the first one to answer this question!

Register or to post your answer.