Start a conversation

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.
 
Or
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.

Choose files or drag and drop files
Was this article helpful?
Yes
No
  1. Priyanka Bhotika

  2. Posted

Comments