EE26002- Loads of "Policy device was not found" errors

Article Original Creation Date: 2012-04-23

Problem

we are receiving lots and lots of errors about a policy not found in encore.log:

2012-04-19 00:23:34,532 ERROR servicegateway.policy - class: com.supportsoft.servicegateway.policy.ejb.policyworkflowmanager.PolicyActionResponseMDB method: onMessage(): 10033 - Error receiving JMS Message: javax.ejb.FinderException: Policy device was not found
2012-04-19 00:23:34,540 ERROR servicegateway.policy - class: com.supportsoft.servicegateway.policy.ejb.policyworkflowmanager.PolicyActionResponseMDB method: onMessage(): 10033 - Error receiving JMS Message: javax.ejb.FinderException: Policy device was not found

Environment

Solaris 10

Oracle 10

WebLogic 9.2.3

Apache5.5.25

Cause

May be:

What is the Policy Action Timeout (PAT)setup to in Production? This can happen if policy actions take longer then the PAT is set to, but they 'are' completing. In that case the runAgedResultsCheck job (which runs every minute) would "time out" the actions in question, which causes the record to be deleted from the SPRT_SG_POLICY_DEVICE table.
Then, when the policy action completes normally after this time and post its result, the record is no longer in the SPRT_SG_POLICY_DEVICE table, causing the "Policy Device Not Found" errors.

The retry mechanism is causing it: but I thought that would have been solved in the past by a patch.

Another thing to check for would be the retries. We provided a hotfix to Telia that would prevent the multiple erroneous retries, which was resulting in seeing a lot of these “Policy Device Not Found” errors.

Solution

This is solved in SG4.3.1

The runAgedResultsCheck timer job would result in a "Policy device was
not found" error when attempting to mark stale actions as timed out if the
policy device record had already been removed from the database, resulting
in the stale records not being properly updated. This caused the
stale actions to be found again each time runAgedResultsCheck would run,
resulting in these errors each time it ran. This was due to
runAgedResultsCheck() mimicking the policy action by posting a "timeout"
result to a JMS queue. The runAgedResultsCheck() timer job has been updated
to now update the stale records directly, rather than mimicking a policy
action response.

Articles in this section

Problem

Environment

Cause

Solution

Still Have Questions?