[prev in list] [next in list] [prev in thread] [next in thread] 

List:       jboss-development
Subject:    [JBoss-dev] [ jboss-Bugs-745644 ] Basic Queue performance problem - too much synchronization
From:       "SourceForge.net" <noreply () sourceforge ! net>
Date:       2003-05-29 18:35:48
[Download RAW message or body]

Bugs item #745644, was opened at 2003-05-29 17:31
Message generated for change (Comment added) made by ejort
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=745644&group_id=22866

Category: JBossMQ
Group: None
Status: Open
>Resolution: Accepted
Priority: 5
Submitted By: john hutchinson (jamoville)
>Assigned to: Adrian Brock (ejort)
>Summary: Basic Queue performance problem - too much synchronization

Initial Comment:
This bug is not fixed - I looked at the latest code in cvs 
and the code has not been changed. While you did fix a 
deadlock situation in the BasicQueue class you missed 
fixing the one I was mentioning. Specifically the 
methods:
hasUnackedMessages
and
checkRemovedSubscribers

when these methods are called by two different threads 
a deadlock happens. You should be synchronizing on 
the methods. You are causing too much context 
switching and it's killing performance. You also wouldn't 
have to be doing all those nested synchronizations.

here is the stack trace:
FOUND A JAVA LEVEL DEADLOCK:

----------------------------

"Thread-186":

waiting to lock monitor 0x8ed8f4 (object 0x3395af8, a 
java.util.HashSet),

which is locked by "Thread-184"

"Thread-184":

waiting to lock monitor 0x8eda14 (object 0x3395a68, a 
java.util.HashMap),

which is locked by "Thread-186"



JAVA STACK INFORMATION FOR THREADS LISTED 
ABOVE:

------------------------------------------------

Java Stack for "Thread-186":

==========

at 
org.jboss.mq.server.BasicQueue.checkRemovedSubscri
bers(BasicQueue.java:508)

at org.jboss.mq.server.BasicQueue.acknowledge
(BasicQueue.java:404)

at org.jboss.mq.server.JMSQueue.acknowledge
(JMSQueue.java:114)

at org.jboss.mq.server.ClientConsumer.acknowledge
(ClientConsumer.java:328)

at 
org.jboss.mq.server.JMSDestinationManager.acknowledg
e(JMSDestinationManager.java:529)

at 
org.jboss.mq.server.JMSDestinationManager.acknowledg
e(JMSDestinationManager.java:513)

at 
org.jboss.mq.server.JMSServerInterceptorSupport.ackno
wledge(JMSServerInterceptorSupport.java:197)

at org.jboss.mq.server.TracingInterceptor.acknowledge
(TracingInterceptor.java:405)

at org.jboss.mq.server.JMSServerInvoker.acknowledge
(JMSServerInvoker.java:199)

at 
org.jboss.mq.il.uil2.ServerSocketManagerHandler.handle
Msg(ServerSocketManagerHandler.java:81)

at 
org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMs
g(SocketManager.java:355)

at org.jboss.mq.il.uil2.msgs.BaseMsg.run
(BaseMsg.java:377)

at 
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Work
er.run(PooledExecutor.java:732)

at java.lang.Thread.run(Thread.java:479)

Java Stack for "Thread-184":

==========

at 
org.jboss.mq.server.BasicQueue.hasUnackedMessages
(BasicQueue.java:500)

at org.jboss.mq.server.BasicQueue.removeSubscriber
(BasicQueue.java:178)

at org.jboss.mq.server.JMSQueue.removeSubscriber
(JMSQueue.java:60)

at 
org.jboss.mq.server.ClientConsumer.removeSubscription
(ClientConsumer.java:253)

at 
org.jboss.mq.server.JMSDestinationManager.unsubscrib
e(JMSDestinationManager.java:624)

at 
org.jboss.mq.server.JMSServerInterceptorSupport.unsub
scribe(JMSServerInterceptorSupport.java:249)

at org.jboss.mq.server.TracingInterceptor.unsubscribe
(TracingInterceptor.java:548)

at org.jboss.mq.server.JMSServerInvoker.unsubscribe
(JMSServerInvoker.java:251)

at 
org.jboss.mq.il.uil2.ServerSocketManagerHandler.handle
Msg(ServerSocketManagerHandler.java:171)

at 
org.jboss.mq.il.uil2.SocketManager$ReadTask.handleMs
g(SocketManager.java:355)

at org.jboss.mq.il.uil2.msgs.BaseMsg.run
(BaseMsg.java:377)

at 
EDU.oswego.cs.dl.util.concurrent.PooledExecutor$Work
er.run(PooledExecutor.java:732)

at java.lang.Thread.run(Thread.java:479)



Found 1 deadlock.


----------------------------------------------------------------------

>Comment By: Adrian Brock (ejort)
Date: 2003-05-29 18:35

Message:
Logged In: YES 
user_id=9459

Your thread dump refers to the 3.2.1 source code
which did indeed contain this deadlock.
It is fixed in latest CVS.

I will leave this log open as "Too much synchronization
in BasicQueue".
I'll try find to simplify (and more importantly test)
the synchronization before 3.2.2 goes final.

It is actually worse than you state, much of the
synchronization is only done in case another thread
comes in to perform a removeAllMessages when a 
non durable topic subscription closes due a network failure.

Regards,
Adrian

----------------------------------------------------------------------

Comment By: john hutchinson (jamoville)
Date: 2003-05-29 17:37

Message:
Logged In: YES 
user_id=733441

Just an FYI - each synch causes four byte code instruction 
and you have synch code that has four syncs.  this will 
generate 16 byte code instruction.  Sychronizing on the 
method will reduce this by 75%

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=376685&aid=745644&group_id=22866


-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5
_______________________________________________
Jboss-development mailing list
Jboss-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
[prev in list] [next in list] [prev in thread] [next in thread]