You are viewing a plain text version of this content. The canonical link for it is here.
Posted to sandesha-dev@ws.apache.org by "Amila Chinthaka Suriarachchi (JIRA)" <ji...@apache.org> on 2008/10/23 10:58:44 UTC
[jira] Commented: (SANDESHA2-179) Adding correct message numbers
with jdbc storage
[ https://issues.apache.org/jira/browse/SANDESHA2-179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12642121#action_12642121 ]
Amila Chinthaka Suriarachchi commented on SANDESHA2-179:
--------------------------------------------------------
this seems to be some thing related to Transaction Isolation level.
By default it set to 2. i.e TRANSACTION_READ_COMMITTED
when I set the transaction level to TRANSACTION_SERIALIZABLE as follows,
dbConnection.setTransactionIsolation(Connection.TRANSACTION_SERIALIZABLE);
then message sequences works fine. But after some time system stuck at the client side. i.e I assume there is a deadlock. This may happen if application message processor and sequence message processor does not access the database tables in a same order.
I'll try to check for that.
> 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
>
> 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: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org