Bug 826491
Summary: | Message for receive activity is not needed anymore if we send a SOAP message for receive before pick activity | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [JBoss] JBoss Enterprise SOA Platform 5 | Reporter: | Ivo Bek <ibek> | ||||||
Component: | riftsaw | Assignee: | Julian Coleman <jcoleman> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Ivo Bek <ibek> | ||||||
Severity: | medium | Docs Contact: | |||||||
Priority: | medium | ||||||||
Version: | 5.3.0 GA | CC: | dlesage, dpalmer, kconner, kejohnso, mbaluch, myarboro, sdorfiel, soa-p-jira | ||||||
Target Milestone: | CR1 | ||||||||
Target Release: | 5.3.0 GA | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Whiteboard: | |||||||||
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 17:25:57 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: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Ivo Bek
2012-05-30 10:49:55 UTC
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 |