[
https://issues.apache.org/jira/browse/SANDESHA2-179?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Damitha Kumarage updated SANDESHA2-179:
---------------------------------------
Attachment: patch.txt
Hi Amila,
As I understand the reason for missing messages could be described as
follows(specific case why message number 16 missing)
1. Application message processors processOutMessage() is called by application
client in the process of sending message body marked as element 15 as message
number 15.
2. In application message processor rmsBean with next message number 15 is
retrieved calling rmsBeanMgr.retrieve(). Then after doing changes and marking
the next message number as the message number 16 it is updated to the data
base using rmsBeanMgr.update().
3. At another place of code rmsBean is retrieved before the above update(Say
within acknowledement message processor). So this rmsBean also has message
number as 15. after doing some changes(here next message number is not
increased) it also update to the database calling rmsBeanMgr.update(). Note
that if this update happen after the first update then in the database the next
message number become 15 again(which cause the problem in hand).
4. Now when again rmsBean is retrieved at application message processor within
the process of sending element 16, still it is message number 15 which would
result in not sending a message with message number marked as 16.
So my understanding is, to avoid this problem we should lock the rmsBeanMgr
object for the duration from retrieve to update. This is possible since
rmsBeanMgr is stored in storage manager which in turn has only one instance
stored as a parameter in the configuration context.
The patch attached do this on revision r707102 which is just after persistence
patch was applied(prier to your solution for the problem in hand). Please try
this patch on the revision mentioned and see whether it solve the problem.
> Adding correct message numbers with jdbc storage
> -------------------------------------------------
>
> Key: SANDESHA2-179
> URL: https://issues.apache.org/jira/browse/SANDESHA2-179
> Project: Sandesha2
> Issue Type: Bug
> Reporter: Amila Chinthaka Suriarachchi
> Attachments: core_patch.txt, patch.txt, patch.txt,
> persistence_patch.txt
>
>
> I ran a 100 message message sequence using the jdbc storage. The message
> receiver looks like this,
> protected void invokeBusinessLogic(MessageContext messageContext)
> throws AxisFault {
> System.out.println("Got the soap message ==> " +
> messageContext.getEnvelope().getBody().getFirstElement());
> }
> and the client has this code to produce 100 messages.
> for (int i = 1; i < 100; i++) {
> serviceClient.fireAndForget(getTestOMElement(i));
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> }
> }
> private OMElement getTestOMElement(long number) {
> OMFactory omFactory = OMAbstractFactory.getOMFactory();
> OMNamespace omNamespace =
> omFactory.createOMNamespace("http://wso2.org/temp1";, "ns1");
> OMElement omElement = omFactory.createOMElement("TestElement",
> omNamespace);
> omElement.setText("org element " + number);
> return omElement;
> }
> so I expects a 1 - 100 message sequence as follows on the server side console.
> Got the soap message ==> <ns1:TestElement
> xmlns:ns1="http://wso2.org/temp1";>org element 1</ns1:TestElement>
> Got the soap message ==> <ns1:TestElement
> xmlns:ns1="http://wso2.org/temp1";>org element 2</ns1:TestElement>
> Got the soap message ==> <ns1:TestElement
> xmlns:ns1="http://wso2.org/temp1";>org element 3</ns1:TestElement>
> but there were some missing messages in this sequence
> Got the soap message ==> <ns1:TestElement
> xmlns:ns1="http://wso2.org/temp1";>org element 14</ns1:TestElement>
> Got the soap message ==> <ns1:TestElement
> xmlns:ns1="http://wso2.org/temp1";>org element 15</ns1:TestElement>
> Got the soap message ==> <ns1:TestElement
> xmlns:ns1="http://wso2.org/temp1";>org element 17</ns1:TestElement>
> However message sequence terminates properly. but server sends
> acknowledgments only for 96 messsages.
> Then I went through each and every message using tcp mon and saw the
> following.
> <wsrm:Sequence xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm";
> soapenv:mustUnderstand="1">
>
> <wsrm:Identifier>urn:uuid:63C7D88DAE5A969F4C1224742882720</wsrm:Identifier>
> <wsrm:MessageNumber>15</wsrm:MessageNumber>
> </wsrm:Sequence>
> </soapenv:Header>
> <soapenv:Body>
> <ns1:TestElement xmlns:ns1="http://wso2.org/temp1";>org element
> 15</ns1:TestElement>
> </soapenv:Body>
> <wsrm:Sequence xmlns:wsrm="http://schemas.xmlsoap.org/ws/2005/02/rm";
> soapenv:mustUnderstand="1">
>
> <wsrm:Identifier>urn:uuid:63C7D88DAE5A969F4C1224742882720</wsrm:Identifier>
> <wsrm:MessageNumber>15</wsrm:MessageNumber>
> </wsrm:Sequence>
> </soapenv:Header>
> <soapenv:Body>
> <ns1:TestElement xmlns:ns1="http://wso2.org/temp1";>org element
> 16</ns1:TestElement>
> </soapenv:Body>
> So the reason is that the message number 15 is repeated in two messages. But
> this did not happen with the Inmemory mode. Seems to be a transaction
> handling problem. I am testing with the Derby data base.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
