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 Andrew K Gatford <GA...@uk.ibm.com> on 2009/03/03 12:30:06 UTC
Fw: svn commit: r747405 - /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Hi,
I've been looking at this change for a while and trying to work out what
you were trying to achieve as at the moment as I really don't like
catching a (RuntimeException).
At the very least we should log the exception that was caught. The best
solution would be to catch the actual exception that was thrown. Even so
- as you said, we probably have a problem with the InMemory transaction
model and we are now simply hiding this. This leads me onto another
question. What was the exception thrown ?
Andrew Gatford
Technical Project Lead
Websphere ESB Foundation Technologies
Hursley MP211
IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
Telephone :
Internal (7) 245743
External 01962 815743
Internet : gatfora@uk.ibm.com
----- Forwarded by Andrew K Gatford/UK/IBM on 03/03/2009 11:26 -----
From:
amilas@apache.org
To:
sandesha-cvs@ws.apache.org
Date:
24/02/2009 15:39
Subject:
svn commit: r747405 -
/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Author: amilas
Date: Tue Feb 24 15:38:33 2009
New Revision: 747405
URL: http://svn.apache.org/viewvc?rev=747405&view=rev
Log:
when handling duplicate messages. i.e if the services blocks the thread
for 60 seconds, then there is a possiblity
that RMS sends duplicate messages. these duplcate messages are locked in
the GloblaInHander util first message clear
the service. Then when after processing these messages they going to
commit. At this commit release locks method
throws a Runtime Exception which causes a soap fault message. this can be
avoided by catching this exception at this
level. But how ever there may be an error with the InMemory Transaction
model.
Modified:
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Modified:
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
URL:
http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java?rev=747405&r1=747404&r2=747405&view=diff
==============================================================================
---
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
(original)
+++
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Tue Feb 24 15:38:33 2009
@@ -81,12 +81,15 @@
this.useSerialization = useSerialization;
if(LoggingControl.isAnyTracingEnabled()
&& log.isDebugEnabled()) log.debug("Exit: InMemoryTransaction::<init>, " +
this);
}
-
- public void commit() {
- releaseLocks();
- if(sentMessages && useSerialization)
manager.getSender().wakeThread();
- active = false;
- }
+
+ public void commit() {
+ try {
+ releaseLocks();
+ } catch (RuntimeException e) {
+ }
+ if (sentMessages && useSerialization)
manager.getSender().wakeThread();
+ active = false;
+ }
public void rollback() {
releaseLocks();
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Fw: svn commit: r747405 - /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Posted by Amila Suriarachchi <am...@gmail.com>.
On Wed, Mar 11, 2009 at 6:47 PM, Andrew K Gatford <GA...@uk.ibm.com>wrote:
>
> Hi Amila
>
> Thanks for the exception. I managed to recreate the problem by modifying
> the Sandesha unit tests. I think I have fixed it by making a change to the
> InMemoryTransaction to only add a bean to the locked list if it really did
> lock it (revision 752438) . This means that the catch (RuntimeException)
> could be removed.
> Do you want to give it a try ?
Now it is working .
thanks,
Amila.
>
>
> Thanks
>
> Andrew Gatford
> Technical Project Lead
> Websphere ESB Foundation Technologies
> Hursley MP211
> IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
> Telephone :
> Internal (7) 245743
> External 01962 815743
> Internet : gatfora@uk.ibm.com
>
>
> From: Amila Suriarachchi <am...@gmail.com>
> To: Andrew K Gatford/UK/IBM@IBMGB Cc: "sandesha-dev@ws.apache.org" <
> sandesha-dev@ws.apache.org> Date: 11/03/2009 08:06 Subject: Re: Fw: svn
> commit: r747405 -
> /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> ------------------------------
>
>
>
> Here is the exception. which I got just putting a e.printStcktrance() at
> the empty catch block you have mentioned.
>
> java.lang.IllegalMonitorStateException
> at
> java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
> at
> java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
> at
> org.apache.sandesha2.storage.inmemory.InMemoryTransaction.releaseLocks(InMemoryTransaction.java:192)
> at
> org.apache.sandesha2.storage.inmemory.InMemoryTransaction.commit(InMemoryTransaction.java:87)
> at
> org.apache.sandesha2.handlers.SandeshaGlobalInHandler.processApplicationMessage(SandeshaGlobalInHandler.java:264)
> at
> org.apache.sandesha2.handlers.SandeshaGlobalInHandler.invoke(SandeshaGlobalInHandler.java:152)
> at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
> at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:252)
> at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:161)
> at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
> at
> org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:267)
> at
> org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281)
> at
> org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187)
> at
> org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
> at java.lang.Thread.run(Thread.java:595)
>
>
> thanks,
> Amila.
> On Wed, Mar 11, 2009 at 10:40 AM, Amila Suriarachchi <*
> amilasuriarachchi@gmail.com* <am...@gmail.com>> wrote:
> Hi,
>
> Sorry for late reply.
>
> On Tue, Mar 3, 2009 at 5:00 PM, Andrew K Gatford <*G...@uk.ibm.com>>
> wrote:
>
> Hi,
>
> I've been looking at this change for a while and trying to work out what
> you were trying to achieve as at the moment as I really don't like catching
> a (RuntimeException).
> I agree with you. As I have describes in the commit message I did this to
> stop the fault message thrown to the client.
>
> This is my scenario. I think you can easily reproduce this.
>
> Write a service which which delays 60s in its service method. Then invoke
> this method using RM where retransmission interval is set to 15s.
>
> When the first message comes it goes to the service and and hangs 60s. Then
> the other messages hangs at the Sandesha2 In handler level and after the
> waiting period, Inmemory storage throws and exception. (I'll forward the
> whole stack trace)
> Then this causes an *soap fault* to send to client. And that causes some
> other exceptions at the client side.
>
>
> At the very least we should log the exception that was caught. The best
> solution would be to catch the actual exception that was thrown.
>
> Do you think is it correct to send a soap fault to client? when there is a
> problem with the server side.
> Even so - as you said, we probably have a problem with the InMemory
> transaction model and we are now simply hiding this. This leads me onto
> another question. What was the exception thrown ?
>
> Andrew Gatford
> Technical Project Lead
> Websphere ESB Foundation Technologies
> Hursley MP211
> IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
> Telephone :
> Internal (7) 245743
> External 01962 815743
> Internet : *gatfora@uk.ibm.com* <ga...@uk.ibm.com>
> ----- Forwarded by Andrew K Gatford/UK/IBM on 03/03/2009 11:26 -----
> From: *amilas@apache.org* <am...@apache.org> To: *
> sandesha-cvs@ws.apache.org* <sa...@ws.apache.org> Date: 24/02/2009
> 15:39 Subject: svn commit: r747405 -
> /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>
> ------------------------------
>
>
>
> Author: amilas
> Date: Tue Feb 24 15:38:33 2009
> New Revision: 747405
>
> URL: *http://svn.apache.org/viewvc?rev=747405&view=rev*<http://svn.apache.org/viewvc?rev=747405&view=rev>
> Log:
> when handling duplicate messages. i.e if the services blocks the thread for
> 60 seconds, then there is a possiblity
> that RMS sends duplicate messages. these duplcate messages are locked in
> the GloblaInHander util first message clear
> the service. Then when after processing these messages they going to
> commit. At this commit release locks method
> throws a Runtime Exception which causes a soap fault message. this can be
> avoided by catching this exception at this
> level. But how ever there may be an error with the InMemory Transaction
> model.
>
> Modified:
>
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>
> Modified:
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> URL: *
> http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java?rev=747405&r1=747404&r2=747405&view=diff
> *<http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java?rev=747405&r1=747404&r2=747405&view=diff>
>
> ==============================================================================
> ---
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> (original)
> +++
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> Tue Feb 24 15:38:33 2009
> @@ -81,12 +81,15 @@
> this.useSerialization = useSerialization;
> if(LoggingControl.isAnyTracingEnabled()
> && log.isDebugEnabled()) log.debug("Exit: InMemoryTransaction::<init>, " +
> this);
> }
> -
> - public void commit() {
> - releaseLocks();
> - if(sentMessages && useSerialization)
> manager.getSender().wakeThread();
> - active = false;
> - }
> +
> + public void commit() {
> + try {
> + releaseLocks();
> + } catch (RuntimeException e) {
> + }
> + if (sentMessages && useSerialization)
> manager.getSender().wakeThread();
> + active = false;
> + }
>
> public void rollback() {
> releaseLocks();
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: *sandesha-dev-unsubscribe@ws.apache.org*<sa...@ws.apache.org>
> For additional commands, e-mail: *sandesha-dev-help@ws.apache.org*<sa...@ws.apache.org>
>
>
>
>
>
> ------------------------------
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: *http://amilachinthaka.blogspot.com/*<http://amilachinthaka.blogspot.com/>
>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: *http://amilachinthaka.blogspot.com/*<http://amilachinthaka.blogspot.com/>
>
>
>
>
> ------------------------------
>
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Fw: svn commit: r747405 - /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Posted by Andrew K Gatford <GA...@uk.ibm.com>.
Hi Amila
Thanks for the exception. I managed to recreate the problem by modifying
the Sandesha unit tests. I think I have fixed it by making a change to
the InMemoryTransaction to only add a bean to the locked list if it really
did lock it (revision 752438) . This means that the catch
(RuntimeException) could be removed.
Do you want to give it a try ?
Thanks
Andrew Gatford
Technical Project Lead
Websphere ESB Foundation Technologies
Hursley MP211
IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
Telephone :
Internal (7) 245743
External 01962 815743
Internet : gatfora@uk.ibm.com
From:
Amila Suriarachchi <am...@gmail.com>
To:
Andrew K Gatford/UK/IBM@IBMGB
Cc:
"sandesha-dev@ws.apache.org" <sa...@ws.apache.org>
Date:
11/03/2009 08:06
Subject:
Re: Fw: svn commit: r747405 -
/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Here is the exception. which I got just putting a e.printStcktrance() at
the empty catch block you have mentioned.
java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at
org.apache.sandesha2.storage.inmemory.InMemoryTransaction.releaseLocks(InMemoryTransaction.java:192)
at
org.apache.sandesha2.storage.inmemory.InMemoryTransaction.commit(InMemoryTransaction.java:87)
at
org.apache.sandesha2.handlers.SandeshaGlobalInHandler.processApplicationMessage(SandeshaGlobalInHandler.java:264)
at
org.apache.sandesha2.handlers.SandeshaGlobalInHandler.invoke(SandeshaGlobalInHandler.java:152)
at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:252)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:161)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at
org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:267)
at
org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281)
at
org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187)
at
org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
thanks,
Amila.
On Wed, Mar 11, 2009 at 10:40 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
Hi,
Sorry for late reply.
On Tue, Mar 3, 2009 at 5:00 PM, Andrew K Gatford <GA...@uk.ibm.com>
wrote:
Hi,
I've been looking at this change for a while and trying to work out what
you were trying to achieve as at the moment as I really don't like
catching a (RuntimeException).
I agree with you. As I have describes in the commit message I did this to
stop the fault message thrown to the client.
This is my scenario. I think you can easily reproduce this.
Write a service which which delays 60s in its service method. Then invoke
this method using RM where retransmission interval is set to 15s.
When the first message comes it goes to the service and and hangs 60s.
Then the other messages hangs at the Sandesha2 In handler level and after
the waiting period, Inmemory storage throws and exception. (I'll forward
the whole stack trace)
Then this causes an *soap fault* to send to client. And that causes some
other exceptions at the client side.
At the very least we should log the exception that was caught. The best
solution would be to catch the actual exception that was thrown.
Do you think is it correct to send a soap fault to client? when there is a
problem with the server side.
Even so - as you said, we probably have a problem with the InMemory
transaction model and we are now simply hiding this. This leads me onto
another question. What was the exception thrown ?
Andrew Gatford
Technical Project Lead
Websphere ESB Foundation Technologies
Hursley MP211
IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
Telephone :
Internal (7) 245743
External 01962 815743
Internet : gatfora@uk.ibm.com
----- Forwarded by Andrew K Gatford/UK/IBM on 03/03/2009 11:26 -----
From:
amilas@apache.org
To:
sandesha-cvs@ws.apache.org
Date:
24/02/2009 15:39
Subject:
svn commit: r747405 -
/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Author: amilas
Date: Tue Feb 24 15:38:33 2009
New Revision: 747405
URL: http://svn.apache.org/viewvc?rev=747405&view=rev
Log:
when handling duplicate messages. i.e if the services blocks the thread
for 60 seconds, then there is a possiblity
that RMS sends duplicate messages. these duplcate messages are locked in
the GloblaInHander util first message clear
the service. Then when after processing these messages they going to
commit. At this commit release locks method
throws a Runtime Exception which causes a soap fault message. this can be
avoided by catching this exception at this
level. But how ever there may be an error with the InMemory Transaction
model.
Modified:
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Modified:
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
URL:
http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java?rev=747405&r1=747404&r2=747405&view=diff
==============================================================================
---
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
(original)
+++
webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Tue Feb 24 15:38:33 2009
@@ -81,12 +81,15 @@
this.useSerialization =
useSerialization;
if(LoggingControl.isAnyTracingEnabled()
&& log.isDebugEnabled()) log.debug("Exit: InMemoryTransaction::<init>, " +
this);
}
-
- public void commit() {
- releaseLocks();
- if(sentMessages && useSerialization)
manager.getSender().wakeThread();
- active = false;
- }
+
+ public void commit() {
+ try {
+ releaseLocks();
+ } catch (RuntimeException e) {
+ }
+ if (sentMessages && useSerialization)
manager.getSender().wakeThread();
+ active = false;
+ }
public void rollback() {
releaseLocks();
---------------------------------------------------------------------
To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: sandesha-dev-help@ws.apache.org
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Re: Fw: svn commit: r747405 - /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Posted by Amila Suriarachchi <am...@gmail.com>.
Here is the exception. which I got just putting a e.printStcktrance() at the
empty catch block you have mentioned.
java.lang.IllegalMonitorStateException
at
java.util.concurrent.locks.ReentrantLock$Sync.tryRelease(ReentrantLock.java:125)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(AbstractQueuedSynchronizer.java:1137)
at
java.util.concurrent.locks.ReentrantLock.unlock(ReentrantLock.java:431)
at
org.apache.sandesha2.storage.inmemory.InMemoryTransaction.releaseLocks(InMemoryTransaction.java:192)
at
org.apache.sandesha2.storage.inmemory.InMemoryTransaction.commit(InMemoryTransaction.java:87)
at
org.apache.sandesha2.handlers.SandeshaGlobalInHandler.processApplicationMessage(SandeshaGlobalInHandler.java:264)
at
org.apache.sandesha2.handlers.SandeshaGlobalInHandler.invoke(SandeshaGlobalInHandler.java:152)
at org.apache.axis2.engine.Phase.invoke(Phase.java:318)
at org.apache.axis2.engine.AxisEngine.invoke(AxisEngine.java:252)
at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:161)
at
org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
at
org.apache.axis2.transport.http.HTTPWorker.service(HTTPWorker.java:267)
at
org.apache.axis2.transport.http.server.AxisHttpService.doService(AxisHttpService.java:281)
at
org.apache.axis2.transport.http.server.AxisHttpService.handleRequest(AxisHttpService.java:187)
at
org.apache.axis2.transport.http.server.HttpServiceProcessor.run(HttpServiceProcessor.java:82)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:650)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:675)
at java.lang.Thread.run(Thread.java:595)
thanks,
Amila.
On Wed, Mar 11, 2009 at 10:40 AM, Amila Suriarachchi <
amilasuriarachchi@gmail.com> wrote:
> Hi,
>
> Sorry for late reply.
>
> On Tue, Mar 3, 2009 at 5:00 PM, Andrew K Gatford <GA...@uk.ibm.com>wrote:
>
>>
>> Hi,
>>
>> I've been looking at this change for a while and trying to work out what
>> you were trying to achieve as at the moment as I really don't like catching
>> a (RuntimeException).
>
> I agree with you. As I have describes in the commit message I did this to
> stop the fault message thrown to the client.
>
> This is my scenario. I think you can easily reproduce this.
>
> Write a service which which delays 60s in its service method. Then invoke
> this method using RM where retransmission interval is set to 15s.
>
> When the first message comes it goes to the service and and hangs 60s. Then
> the other messages hangs at the Sandesha2 In handler level and after the
> waiting period, Inmemory storage throws and exception. (I'll forward the
> whole stack trace)
> Then this causes an *soap fault* to send to client. And that causes some
> other exceptions at the client side.
>
>
>> At the very least we should log the exception that was caught. The best
>> solution would be to catch the actual exception that was thrown.
>
>
> Do you think is it correct to send a soap fault to client? when there is a
> problem with the server side.
>
>> Even so - as you said, we probably have a problem with the InMemory
>> transaction model and we are now simply hiding this. This leads me onto
>> another question. What was the exception thrown ?
>>
>> Andrew Gatford
>> Technical Project Lead
>> Websphere ESB Foundation Technologies
>> Hursley MP211
>> IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
>> Telephone :
>> Internal (7) 245743
>> External 01962 815743
>> Internet : gatfora@uk.ibm.com
>> ----- Forwarded by Andrew K Gatford/UK/IBM on 03/03/2009 11:26 -----
>> From: amilas@apache.org To: sandesha-cvs@ws.apache.org Date: 24/02/2009
>> 15:39 Subject: svn commit: r747405 -
>> /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>> ------------------------------
>>
>>
>>
>> Author: amilas
>> Date: Tue Feb 24 15:38:33 2009
>> New Revision: 747405
>>
>> URL: http://svn.apache.org/viewvc?rev=747405&view=rev
>> Log:
>> when handling duplicate messages. i.e if the services blocks the thread
>> for 60 seconds, then there is a possiblity
>> that RMS sends duplicate messages. these duplcate messages are locked in
>> the GloblaInHander util first message clear
>> the service. Then when after processing these messages they going to
>> commit. At this commit release locks method
>> throws a Runtime Exception which causes a soap fault message. this can be
>> avoided by catching this exception at this
>> level. But how ever there may be an error with the InMemory Transaction
>> model.
>>
>> Modified:
>>
>> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>>
>> Modified:
>> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>> URL:
>> http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java?rev=747405&r1=747404&r2=747405&view=diff
>>
>> ==============================================================================
>> ---
>> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>> (original)
>> +++
>> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>> Tue Feb 24 15:38:33 2009
>> @@ -81,12 +81,15 @@
>> this.useSerialization =
>> useSerialization;
>> if(LoggingControl.isAnyTracingEnabled()
>> && log.isDebugEnabled()) log.debug("Exit: InMemoryTransaction::<init>, " +
>> this);
>> }
>> -
>> - public void commit() {
>> - releaseLocks();
>> - if(sentMessages && useSerialization)
>> manager.getSender().wakeThread();
>> - active = false;
>> - }
>> +
>> + public void commit() {
>> + try {
>> + releaseLocks();
>> + } catch (RuntimeException e) {
>> + }
>> + if (sentMessages && useSerialization)
>> manager.getSender().wakeThread();
>> + active = false;
>> + }
>>
>> public void rollback() {
>> releaseLocks();
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
>> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> *
>> *
>>
>> *Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>> *
>>
>>
>>
>>
>>
>>
>>
>
>
> --
> Amila Suriarachchi
> WSO2 Inc.
> blog: http://amilachinthaka.blogspot.com/
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/
Re: Fw: svn commit: r747405 - /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
Posted by Amila Suriarachchi <am...@gmail.com>.
Hi,
Sorry for late reply.
On Tue, Mar 3, 2009 at 5:00 PM, Andrew K Gatford <GA...@uk.ibm.com> wrote:
>
> Hi,
>
> I've been looking at this change for a while and trying to work out what
> you were trying to achieve as at the moment as I really don't like catching
> a (RuntimeException).
I agree with you. As I have describes in the commit message I did this to
stop the fault message thrown to the client.
This is my scenario. I think you can easily reproduce this.
Write a service which which delays 60s in its service method. Then invoke
this method using RM where retransmission interval is set to 15s.
When the first message comes it goes to the service and and hangs 60s. Then
the other messages hangs at the Sandesha2 In handler level and after the
waiting period, Inmemory storage throws and exception. (I'll forward the
whole stack trace)
Then this causes an *soap fault* to send to client. And that causes some
other exceptions at the client side.
> At the very least we should log the exception that was caught. The best
> solution would be to catch the actual exception that was thrown.
Do you think is it correct to send a soap fault to client? when there is a
problem with the server side.
> Even so - as you said, we probably have a problem with the InMemory
> transaction model and we are now simply hiding this. This leads me onto
> another question. What was the exception thrown ?
>
> Andrew Gatford
> Technical Project Lead
> Websphere ESB Foundation Technologies
> Hursley MP211
> IBM United Kingdom Laboratories, Hursley Park, Winchester, SO21 2JN
> Telephone :
> Internal (7) 245743
> External 01962 815743
> Internet : gatfora@uk.ibm.com
> ----- Forwarded by Andrew K Gatford/UK/IBM on 03/03/2009 11:26 -----
> From: amilas@apache.org To: sandesha-cvs@ws.apache.org Date: 24/02/2009
> 15:39 Subject: svn commit: r747405 -
> /webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> ------------------------------
>
>
>
> Author: amilas
> Date: Tue Feb 24 15:38:33 2009
> New Revision: 747405
>
> URL: http://svn.apache.org/viewvc?rev=747405&view=rev
> Log:
> when handling duplicate messages. i.e if the services blocks the thread for
> 60 seconds, then there is a possiblity
> that RMS sends duplicate messages. these duplcate messages are locked in
> the GloblaInHander util first message clear
> the service. Then when after processing these messages they going to
> commit. At this commit release locks method
> throws a Runtime Exception which causes a soap fault message. this can be
> avoided by catching this exception at this
> level. But how ever there may be an error with the InMemory Transaction
> model.
>
> Modified:
>
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
>
> Modified:
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> URL:
> http://svn.apache.org/viewvc/webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java?rev=747405&r1=747404&r2=747405&view=diff
>
> ==============================================================================
> ---
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> (original)
> +++
> webservices/sandesha/trunk/java/modules/core/src/main/java/org/apache/sandesha2/storage/inmemory/InMemoryTransaction.java
> Tue Feb 24 15:38:33 2009
> @@ -81,12 +81,15 @@
> this.useSerialization = useSerialization;
> if(LoggingControl.isAnyTracingEnabled()
> && log.isDebugEnabled()) log.debug("Exit: InMemoryTransaction::<init>, " +
> this);
> }
> -
> - public void commit() {
> - releaseLocks();
> - if(sentMessages && useSerialization)
> manager.getSender().wakeThread();
> - active = false;
> - }
> +
> + public void commit() {
> + try {
> + releaseLocks();
> + } catch (RuntimeException e) {
> + }
> + if (sentMessages && useSerialization)
> manager.getSender().wakeThread();
> + active = false;
> + }
>
> public void rollback() {
> releaseLocks();
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: sandesha-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: sandesha-dev-help@ws.apache.org
>
>
>
>
>
> ------------------------------
>
> *
> *
>
> *Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> *
>
>
>
>
>
>
>
--
Amila Suriarachchi
WSO2 Inc.
blog: http://amilachinthaka.blogspot.com/