Bug 780780 (SOA-3234)

Summary: BPEL process failover doesn't work
Product: [JBoss] JBoss Enterprise SOA Platform 5 Reporter: Ivo Bek <ibek>
Component: riftsawAssignee: Default User <jbpapp-maint>
Status: CLOSED NOTABUG QA Contact:
Severity: urgent Docs Contact:
Priority: urgent    
Version: 5.2.0 ER1CC: mbaluch
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
URL: http://jira.jboss.org/jira/browse/SOA-3234
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-08-09 06:35:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
cluster2_riftsaw.2.3.1.log
none
cluster2.log
none
TakeOverProcess.bpel none

Description Ivo Bek 2011-08-03 11:16:51 UTC 
project_key: SOA

I have bpel process with web service (which only print number of loop cycle) deployed on cluster1 and cluster2. I'll send soap message to process on cluster1 and process is running in for loop. In 50th loop It will wait and You can kill cluster1 with signal 9. The cluster2 should takeover process, but after some ConnectExceptions It do NOTHING.

BTW I tried Riftsaw 2.3.1-Snapshot on SOA-P 5.2.ER1 with fixed issue https://issues.jboss.org/browse/RIFTSAW-404 and cluster2 tried to restore process, but It failed in every attempt with this exception:

2011-08-02 15:36:31,475 ERROR [org.apache.ode.scheduler.simple.SimpleScheduler] (ODEServer-21) Error while processing a persisted job: [JobId: hqejbhcnphr6hf75eilk7w,nodeId: 127.0.0.1:1199,scheduled: false,transacted: true,ts: 1312292188221,channel: null,instaceId : 0,type: INVOKE_CHECK,retrycount: 2]
org.apache.ode.bpel.iapi.Scheduler$JobProcessorException
	at org.apache.ode.bpel.engine.BpelEngineImpl.acquireInstanceLock(BpelEngineImpl.java:396)
Comment 1 Ivo Bek 2011-08-03 11:21:58 UTC 
Attachment: Added: cluster2_riftsaw.2.3.1.log
Attachment: Added: cluster2.log
Comment 2 Ivo Bek 2011-08-03 11:23:22 UTC 
Link: Added: This issue relates to RIFTSAW-404
Comment 3 Ivo Bek 2011-08-03 11:30:03 UTC 
You can use TakeOverProcess or failover test from issue RIFTSAW-404. It should be same.
Comment 4 Ivo Bek 2011-08-03 11:30:03 UTC 
Attachment: Added: TakeOverProcess.bpel
Comment 5 Marek Baluch 2011-08-04 12:09:12 UTC 
It looks like Riftsaw clustering was not properly configured and that was the cause of the error. With a properly configured Riftsaw clustering I managed to reproduce Riftsaw-404.

IMO you can reject this issue.