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 : gatf...@uk.ibm.com
From:
Amila Suriarachchi <amilasuriarach...@gmail.com>
To:
Andrew K Gatford/UK/i...@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 <
amilasuriarach...@gmail.com> wrote:
Hi,
Sorry for late reply.
On Tue, Mar 3, 2009 at 5:00 PM, Andrew K Gatford <gatf...@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 : gatf...@uk.ibm.com
----- Forwarded by Andrew K Gatford/UK/IBM on 03/03/2009 11:26 -----
From:
ami...@apache.org
To:
sandesha-...@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-unsubscr...@ws.apache.org
For additional commands, e-mail: sandesha-dev-h...@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
