LinkedIn
Copied!

PEGA0086: Requestor locked by a busy thread

The PEGA0086 alert is generated when the maximum number of attempts to acquire a lock on a requestor has been exceeded and a thread fails to obtain a lock on the requestor and displays the RequestorLockException message.

Example message text

requestorID=H9A6D8BED92E1CD15A9F128E9A2F4BF7C;originalLockOwner=http-bio-8080-exec-5;currentLockOwner=http-bio-8080-exec-5;*Requestor lock detected from single long running interaction

or

requestorID=H9A6D8BED92E1CD15A9F128E9A2F4BF7C;originalLockOwner=http-bio-8080-exec-5;currentLockOwner=http-bio-8080-exec-10;*Requestor lock detected for multiple overlapping interactions

The alert captures and displays the following information about the issue:

  • requestorID – The ID of the requestor for which RequestorLockException is thrown
  • originalLockOwner – The name of the thread that held the lock during the first attempt to acquire a lock on a requestor
  • currentLockOwner – The name of the thread that holds the lock
  • The message that contains the reason for the alert
  • Stack trace of the thread that holds the lock
  • The name of the thread that is trying to acquire a lock on a requestor and displays the RequestorLockException

Default prconfig.xml setting

The alert is triggered when the number of attempts to acquire a lock on a requestor is above the threshold of six attempts. The default threshold value applies to the httpmaxlockattempts attribute in the prconfig.xml file. You can modify the threshold default value by editing the prconfig.xml file and modifying the following setting:

<env name="initialization/httpmaxlockattempts" value="6" />

When you modify the default value, the new value applies only for the node on which the prconfig.xml file is modified. Ensure that the new value is propagated to all nodes in the cluster and that all nodes reflect the same threshold value in their configuration files.

You must restart the nodes for the changes to the prconfig.xml file to take effect.

Reason for the alert

The alert can occur in the following situations:

  • An interaction runs for a long period of time and holds a lock on a requestor (the thread that is holding a lock during the first attempt is the same as the thread that is holding the lock during last attempt). The requestor is not available for other interactions.
  • Several interactions overlap in the same requestor session (different threads hold a lock during the first and last attempt). In this situation, the alert is triggered by the interaction that was not able to acquire a lock in all attempts.

The issue is internal to the system and to eliminate this alert, an administrator should investigate the issue and debug the requestor activity on the thread that is holding the lock. Remedial actions depend on the use case and a system state.


Related Content

Have a question? Get answers now.

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