Created attachment 587683 [details]
Issue reproducer

Steps to reproduce:

1) unpack into ${soa_root}/jboss-as/samples/quickstarts
2) ant deploy
3) use e.g. SOAP-UI:
   3.a) invoke the 'recreq' operation
   3.b) invoke the 'pickreq' operation
4) at this point you can invoke 'pickreq' as many times as you like and you will not see a running instance in the console.

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
When selecting pickreq, you will not see a running instance in the console. The message for the <receive> activity is not displayed if you send a SOAP message for <receive> before a <pick> activity

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When selecting pickreq, you will not see a running instance in the console. The message for the <receive> activity is not displayed if you send a SOAP message for <receive> before a <pick> activity+When selecting pickreq, you will not see a running instance in the console. The message for the receive activity is not displayed if you send a SOAP message for receive before a pick activity

Jeff Yu <cyu> updated the status of jira RIFTSAW-495 to Coding In Progress

Jeff Yu <cyu> made a comment on jira RIFTSAW-495

Below is what I found.

When BpelRuntime encounters this sort of case, it will save the 'MEX' (MessageEXchange) as the 'QUEUED' status, it will be automatically dequeued next time when the related process instance was triggered. Thats the reason that for the first time, if it sends the <pick>, the original <receive> activity message will be re-run automatically.

Somehow, the MEX still remains 'QUEUED' status, even though it has been matched in the second time in our case. This should be the bug.

Jeff Yu <cyu> made a comment on jira RIFTSAW-495

Fixed it by updating the status from 'QUEUED' to 'MATCHED' once we find it matched, and when dequeue the correlators, only those are not in the 'MATCHED' status will be tried.

Jeff Yu <cyu> updated the status of jira RIFTSAW-495 to Resolved

Not fixed in 5.3.ER4. 

The fix is included in RiftSaw 2.3.6.Final (see https://issues.jboss.org/browse/RIFTSAW-495). 5.3.ER4 includes RiftSaw 2.3.5.Final.

Changed proposed target milestone to ER5.

    Technical note updated. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    Diffed Contents:
@@ -1 +1 @@
-When selecting pickreq, you will not see a running instance in the console. The message for the receive activity is not displayed if you send a SOAP message for receive before a pick activity+When a BPEL process receives the second message for a receive activity before it receives the first one for a pick activity and the activities are correlated, the second message will no longer be required by any subsequent BPEL process instances with the same correlation identifiers.

Thanks Ivo.  I used your comment as the basis for the new note.

Please verify this issue on 5.3.0 CR1.

Verified in JBoss SOA-P 5.3.0.CR1

Hi, I noticed that on MSSQL2008R2 database, the fix doesn't work ... it causes a deadlock:

Transaction (Process ID 79) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
2012-07-26 07:53:16,958 ERROR [org.hibernate.event.def.AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.LockAcquisitionException: Could not execute JDBC batch update

To reproduce the issue ... use SOA-P 5.3.0.CR1 with MSSQL2008R2 and run issue reproducer from attachments.

Thanks

FYI, the deadlock issue appears also sometimes on another databases but not so often as mssql2008r2

Created attachment 600737 [details]
deadlock

Hi Ivo,

It seems to me that the deadlock problem is not related to this issue, it just happen to use this test case can reproduce the deadlock issue.

Hi Jeff,

thank you, so I created related issue https://bugzilla.redhat.com/show_bug.cgi?id=844278 (https://issues.jboss.org/browse/RIFTSAW-504)

Thanks Ivo. Should we close this issue. As you verified it against other databases, like mysql and postgres?

Yes, I think we can close it, I didn't meet another issues than the deadlock.

Jeff Yu <cyu> updated the status of jira RIFTSAW-495 to Closed