Visit the Below Website to access unlimited exam questions for all IT vendors and Get Oracle Certifications for FREE
http://www.free-online-exams.com
http://www.free-online-exams.com
Problem: Getting MD5 in Callback message manual
recovery
1. Login to BPEL
console
2. Goto BPEL Processes and then Manual Recovery
3. Click on Callback tab
2. Goto BPEL Processes and then Manual Recovery
3. Click on Callback tab
On 10.1.3.3.1 in Production:
We are getting MD5 message while trying to manually recover callback messages from BPEL console,
but there is no instance id for these messages. These messages never get cleared, even after
manually recovering them
We are getting MD5 message while trying to manually recover callback messages from BPEL console,
but there is no instance id for these messages. These messages never get cleared, even after
manually recovering them
Solution:
Bug 7022475 WORKLIST TASK EXPIRATION CAUSES DUPLICATE CALLBACKS AND ROWS IN
DLV_MESSAGE TABL
Bug 7671900 HOW TO RECOVER THE WAIT ACTIVITIES STUCK?
- Under heavy load, some bpel instances with <wait> activities may get stuck in open state on <wait> activities even after wait expiration.
- Only way to recover the stuck instances is to re-start the server or to bump up the default value of com.oracle.bpel.expirationAgent.threadCount, both of which are not feasible in a production envt.
how a wait activity that get stuck can be recovered, without re-starting the SOA suite.
Just refresh the Alarm Table!
This will "Re-register all activities with an expiration date (ie wait, onAlarm) with the scheduler and will be re-scheduled dynamically". No need for a re-start of the SOA suite. To do this:
In 10.1.3.4:
- Click of 'BPELConsole->Administration->Actions->Refresh Alarm Table'.
In 10.1.3.3 or 10.1.3.3.1
- Click on 'BPELConsole->BPEL Processes->Refresh Alarm Table'
Once you do this, All the pending activities <wait/alarm> activities will be re-scheduled and will be completed.
To avoid another bug 5479372 be at least in MLR 15
BPEL GOT A LOTS OF INSTANCE/ACTIVITY NOT FOUND, NEXT EXPIRATION ATTEMPT
- Under heavy load, some bpel instances with <wait> activities may get stuck in open state on <wait> activities even after wait expiration.
- Only way to recover the stuck instances is to re-start the server or to bump up the default value of com.oracle.bpel.expirationAgent.threadCount, both of which are not feasible in a production envt.
how a wait activity that get stuck can be recovered, without re-starting the SOA suite.
Just refresh the Alarm Table!
This will "Re-register all activities with an expiration date (ie wait, onAlarm) with the scheduler and will be re-scheduled dynamically". No need for a re-start of the SOA suite. To do this:
In 10.1.3.4:
- Click of 'BPELConsole->Administration->Actions->Refresh Alarm Table'.
In 10.1.3.3 or 10.1.3.3.1
- Click on 'BPELConsole->BPEL Processes->Refresh Alarm Table'
Once you do this, All the pending activities <wait/alarm> activities will be re-scheduled and will be completed.
To avoid another bug 5479372 be at least in MLR 15
BPEL GOT A LOTS OF INSTANCE/ACTIVITY NOT FOUND, NEXT EXPIRATION ATTEMPT
References:
No comments:
Post a Comment