Expand my Community achievements bar.

Cumulative JBoss memory leak

Avatar

Former Community Member

Hi there,

I wasn't entirely sure which forum to post to so please let me know if I've got it wrong.

I am experiencing an unusual problem where by the JBoss for LiveCycle service is taking up more and more memory the more it gets used.  On one of our test environments it is using over 1.2 gigs, where as on another environment with an identical installation it is using less than half this because it has been used less.  One curious thing is that restarting the service or even restarting the server doesn't force JBoss to relinquish the extra memory it has appropriated; it just grabs back up to the level it was at.

This issue manifests in errors for the user when they try to save data from a PDF.  A new user can save and submit several times without experiencing problems but there comes a point where although it says it seems to have saved, in fact it hasn't, and there is no record of the event in Workbench despite setting that process to record.  Also intermittently when they try to save they get a "java.lang.OutOfMemoryError: Java heap space".  The user can at no stage save their work but a new user can repeat the above and work freely until they hit the same problem.

My initial investigations suggest that this may all be due to a memory leak and the only place I can think of this occurring are in the bespoke java servlets we have written for accessing the LiveCycle API (though I would have thought the garbage collector would guard against this?).

Can anyone suggest what the problem might be or recommend a productive line of enquiry? 

Many thanks,

Kieran

1 Reply

Avatar

Level 4

I would suggest that you log a case with support directly.  They can go through the process of getting your exact version of LC and the scenario.  From your description, this is not a workbench issue per se, but one of LiveCycle operation.  It would fit better under foundation or process management, but the "talk directly to support" would still be the advice.

This is a simple way of saying "yes, we do have problems like this at times, but it is better dealt with in the specific case of your process and software details."  It would be great if you summarized your experience on the forum when this issue is resolved.