Skip to main content

This content has been archived and is no longer being updated. Links may not function; however, this content may be relevant to outdated versions of the product.

Support Article

StaleThread error in logs with PRPC 6.3 SP1

SA-23378

Summary



StaleThread error appears in logs of PRPC 6.3 SP1.

2015-11-26 18:45:46,859 [j2ee14_ws,maxpri=10]] [ STANDARD] [ ] ( mgmt.base.ThreadData) ERROR - Trying to use a recycled thread
com.pega.pegarules.pub.context.StaleThreadError: Thread has been recycled
2015-11-26 23:45:19,271 [j2ee14_ws,maxpri=10]] [ STANDARD] [ ] ( mgmt.base.ThreadData) ERROR - Trying to use a destroyed thread
com.pega.pegarules.pub.context.StaleThreadError: Thread has been destroyed

HFix-20921 has been provided in this SR, also hotfixes(7815,7697,7666) have been already in inventory file.

 

Error Messages



2016-01-12 10:54:40,622 [j2ee14_ws,maxpri=10]] [ STANDARD] [ ] ( mgmt.base.ThreadData) ERROR - Trying to use a recycled thread
com.pega.pegarules.pub.context.StaleThreadError: Thread has been recycled
at com.pega.pegarules.session.internal.mgmt.base.ThreadData.validateUse(ThreadData.java:618)
at com.pega.pegarules.session.internal.mgmt.PRThreadImpl.validateUse(PRThreadImpl.java:336)


Steps to Reproduce



Not Applicable.


Root Cause



The reason for this is exception is due to a race condition type scenario, the code is aware of the stale thread due to the UsageDaemon and the stalethread exception is suppressed but the exception is displayed by the validation part of the code and it cannot be suppressed there as it is required to catch possible issue from other parts of the code.

Resolution




The scenario that leads to the messages:
The email listener locks the Inbox with requestor object that has requestor ID A , the UsageDaemon thread is trying to acquire the lock on the same requestor object held by email listener thread. As soon as email listener is done with the processing, it releases the lock on requestor object and returns the object to the pool but at this point it has not destroyed the requestor.

At the same time UsageDaemon that is waiting for lock obtains the requestor lock and tries to take the snapshot of the returned requestor by this time it has got the lock but the data/ threads in the requestor object are already cleared off when the requestor object is being returned to the pool by Email Listener thread. Now the UsageDaemon has just an empty requestor object in the pool when it tries to take the snapshot or performs processing on this empty requestor object.

There are same validation checks inside the Pega Engine Code for eg: com.pega.pegarules.session.internal.mgmt.base.ThreadData.validateUse(long)
which does object integrity checks before performing an operation and obviously the checks on empty object fails and Engine logs the error in log file.
 
We encountered these kind of issues when UsageDaemon is processing and we suppress these exceptions as they don’t have functional impact so that UsageDaemon will continue its processing of taking snapshots of other requestors. This is evident as you have mentioned that there are no functional issue associated with this error message in the logs.

However although we suppress the error message at the time it occurs, there is a independent validation component as part of the framework that logs errors or exceptions which is used mainly to spot anything untoward occurring in the code this continues to write the error into the logs, and we are unable to suppress this part of the validation as it will cause us to miss real important issues that may occur in the code.


So in summary the error is seen in the logs due to two points of validation, the first suppresses the exception because we are aware this occurs but has not functional significance, however the second layer of validation picks up on this and logs the message to the logs and we cannot suppress the messages here due to them being used by the rest of the application.

Unfortunately the issue cannot be fixed due to the way the code was designed without a major re-design and re-write of the PRPC code of the product. This area has been re-designed and is already in place in later versions of our product but these are unable to be backported due to nature of the design and the amount of re-work that would be required on the older version of the product.

 

Suggest Edit

Published May 21, 2016 - Updated October 8, 2020

Did you find this content helpful? Yes No

Have a question? Get answers now.

Visit the Collaboration Center to ask questions, engage in discussions, share ideas, and help others.

We'd prefer it if you saw us at our best.

Pega Community has detected you are using a browser which may prevent you from experiencing the site as intended. To improve your experience, please update your browser.

Close Deprecation Notice
Contact us