Bug 826491 - Message for receive activity is not needed anymore if we send a SOAP message for receive before pick activity
Message for receive activity is not needed anymore if we send a SOAP message ...
Status: CLOSED CURRENTRELEASE
Product: JBoss Enterprise SOA Platform 5
Classification: JBoss
Component: riftsaw (Show other bugs)
5.3.0 GA
All All
medium Severity medium
: CR1
: 5.3.0 GA
Assigned To: Julian Coleman
Ivo Bek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-30 06:49 EDT by Ivo Bek
Modified: 2014-10-15 13:25 EDT (History)
8 users (show)

See Also:
Fixed In Version: 5.3.0.GA
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-10-15 13:25:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Issue reproducer (9.52 KB, application/zip)
2012-05-30 07:10 EDT, Marek Baluch
no flags Details
deadlock (1.33 MB, text/x-log)
2012-07-27 06:04 EDT, Ivo Bek
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
JBoss Issue Tracker RIFTSAW-495 Major Closed Message for <receive> activity is not needed anymore if we send a SOAP message for <receive> before <pick> activity 2012-10-05 04:35:26 EDT

  None (edit)
Description Ivo Bek 2012-05-30 06:49:55 EDT
Description of problem:

See linked issue
Comment 1 Marek Baluch 2012-05-30 07:10:27 EDT
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.
Comment 3 Suz 2012-06-12 02:09:32 EDT
    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
Comment 4 David Le Sage 2012-06-12 23:13:07 EDT
    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
Comment 5 JBoss JIRA Server 2012-06-12 23:51:14 EDT
Jeff Yu <cyu@redhat.com> updated the status of jira RIFTSAW-495 to Coding In Progress
Comment 6 JBoss JIRA Server 2012-06-13 04:46:51 EDT
Jeff Yu <cyu@redhat.com> 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.
Comment 7 JBoss JIRA Server 2012-06-13 08:30:19 EDT
Jeff Yu <cyu@redhat.com> 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.
Comment 8 JBoss JIRA Server 2012-06-13 08:31:01 EDT
Jeff Yu <cyu@redhat.com> updated the status of jira RIFTSAW-495 to Resolved
Comment 10 Marek Baluch 2012-06-22 01:48:15 EDT
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.
Comment 11 David Le Sage 2012-07-01 22:34:36 EDT
    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.
Comment 12 David Le Sage 2012-07-01 22:35:10 EDT
Thanks Ivo.  I used your comment as the basis for the new note.
Comment 14 Ryan Zhang 2012-07-20 02:34:57 EDT
Please verify this issue on 5.3.0 CR1.
Comment 15 Ivo Bek 2012-07-24 10:40:08 EDT
Verified in JBoss SOA-P 5.3.0.CR1
Comment 16 Ivo Bek 2012-07-26 08:06:06 EDT
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
Comment 17 Ivo Bek 2012-07-26 08:28:46 EDT
FYI, the deadlock issue appears also sometimes on another databases but not so often as mssql2008r2
Comment 18 Ivo Bek 2012-07-27 06:04:58 EDT
Created attachment 600737 [details]
deadlock
Comment 19 Jeff Yu 2012-07-30 02:08:25 EDT
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.
Comment 20 Ivo Bek 2012-07-30 04:02:04 EDT
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)
Comment 21 Jeff Yu 2012-07-30 04:12:45 EDT
Thanks Ivo. Should we close this issue. As you verified it against other databases, like mysql and postgres?
Comment 22 Ivo Bek 2012-07-30 04:21:52 EDT
Yes, I think we can close it, I didn't meet another issues than the deadlock.
Comment 23 JBoss JIRA Server 2012-10-05 04:35:26 EDT
Jeff Yu <cyu@redhat.com> updated the status of jira RIFTSAW-495 to Closed

Note You need to log in before you can comment on or make changes to this bug.