SourceForge.net
2005-12-02 13:10:21 UTC
Bugs item #1214292, was opened at 2005-06-04 00:13
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1214292&group_id=54559
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: client
Group: v0.7.6.1
Submitted By: ssp (surjitinlondon)
Assigned to: Tim Anderson (tanderson)
Summary: topicSubscriber.close() hangs
Initial Comment:
Hi
We have cleanup code as shown below :
topicConnection.stop();
topicSubscriber.close(); <-- hangs here
topicSession.close();
topicConnection.close();
which ocassionaly hangs when executing
topicSubscriber.close();
Any ideas ?
Thanks
----------------------------------------------------------------------
Message:
Logged In: YES
user_id=557161
Fixed in CVS. Fix will be available in 0.7.7-alpha-2.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-07-23 23:48
Message:
Logged In: YES
user_id=557161
Using the attached SRTest, I can reproduce the problem in
0.7.6.1.
In 0.7.7-alpha-1, it also periodically deadlocks, but for a different
reason - the no. of pooled threads allocated to handle ORB
invocations is too small (10).
In the 0.7.7 CVS version, the deadlock for lack of threads doesn't
occur as the pooling strategy has changed.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-07-23 23:34
Message:
Logged In: YES
user_id=557161
The attached code can be used to reproduce the problem.
It starts 20 asynchronous subscribers, publishes 200 messages,
and tries to close each subscriber after they have handled >=
100 messages.
----------------------------------------------------------------------
Comment By: Russ (russellperry)
Date: 2005-06-10 20:37
Message:
Logged In: YES
user_id=1294329
I get this hang whenever I call topicSubscriebr.close() in the way
shown above. I'm using version 0.7.6.1.
This occurs whenever the Subscriber is trying to close() at the
same time that a message is being delivered by one of the JMS
RMI Threads.
Looking at the code it seems to be possible for a deadlock to
occur (possibly in multiple ways). This is because both the close
() and onMessage(~) methods on the TopicSubscriber use
synchronized and also the TopicSession uses synchronized on
the methods removeSubscriber(~) and execute(~).
I think what's happening is the close() method gets called by the
application thread, which internally calls removeSubscriber() on
the TopicSession. This grabs the TopicSession Lock as well as
the TopicSubscriber Locks.
At the same time, a JMS RMI thread tries to deliver a message.
This blocks on the TopicSession execute() method because it
can't get the TopicSession lock. It seems the application thread
eventually blocks on the
RemoteJmsServerSessionIfc.deleteSubscriber(long) call. I think
this is because a message delivery is in progress?
I think , there are other combinations of dealock that occur. For
example if close() is called by the app thread (grabs
TopicSubscriber Lock). A JMS-RMI thread inside the
TopicSession execute(~) method blocks trying to deliver a
message to the consumer using onMessage(~); it can't get the
TopicSubscriber lock. The app thread also blocks when calling
removeSubscriber(~) because it can' the TopicSession lock
currently held by the JMS RMI Thread.
Hope this helps.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-06-08 14:58
Message:
Logged In: YES
user_id=557161
Can you attach a client and server stack trace?
See http://openjms.sourceforge.net/faq.html if you don't now how
to generate these.
Also update the group field to include the openjms version you
are using.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1214292&group_id=54559
Message generated for change (Comment added) made by tanderson
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1214292&group_id=54559
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: client
Group: v0.7.6.1
Status: Closed
Resolution: Fixed
Priority: 5Resolution: Fixed
Submitted By: ssp (surjitinlondon)
Assigned to: Tim Anderson (tanderson)
Summary: topicSubscriber.close() hangs
Initial Comment:
Hi
We have cleanup code as shown below :
topicConnection.stop();
topicSubscriber.close(); <-- hangs here
topicSession.close();
topicConnection.close();
which ocassionaly hangs when executing
topicSubscriber.close();
Any ideas ?
Thanks
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-12-03 00:10Message:
Logged In: YES
user_id=557161
Fixed in CVS. Fix will be available in 0.7.7-alpha-2.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-07-23 23:48
Message:
Logged In: YES
user_id=557161
Using the attached SRTest, I can reproduce the problem in
0.7.6.1.
In 0.7.7-alpha-1, it also periodically deadlocks, but for a different
reason - the no. of pooled threads allocated to handle ORB
invocations is too small (10).
In the 0.7.7 CVS version, the deadlock for lack of threads doesn't
occur as the pooling strategy has changed.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-07-23 23:34
Message:
Logged In: YES
user_id=557161
The attached code can be used to reproduce the problem.
It starts 20 asynchronous subscribers, publishes 200 messages,
and tries to close each subscriber after they have handled >=
100 messages.
----------------------------------------------------------------------
Comment By: Russ (russellperry)
Date: 2005-06-10 20:37
Message:
Logged In: YES
user_id=1294329
I get this hang whenever I call topicSubscriebr.close() in the way
shown above. I'm using version 0.7.6.1.
This occurs whenever the Subscriber is trying to close() at the
same time that a message is being delivered by one of the JMS
RMI Threads.
Looking at the code it seems to be possible for a deadlock to
occur (possibly in multiple ways). This is because both the close
() and onMessage(~) methods on the TopicSubscriber use
synchronized and also the TopicSession uses synchronized on
the methods removeSubscriber(~) and execute(~).
I think what's happening is the close() method gets called by the
application thread, which internally calls removeSubscriber() on
the TopicSession. This grabs the TopicSession Lock as well as
the TopicSubscriber Locks.
At the same time, a JMS RMI thread tries to deliver a message.
This blocks on the TopicSession execute() method because it
can't get the TopicSession lock. It seems the application thread
eventually blocks on the
RemoteJmsServerSessionIfc.deleteSubscriber(long) call. I think
this is because a message delivery is in progress?
I think , there are other combinations of dealock that occur. For
example if close() is called by the app thread (grabs
TopicSubscriber Lock). A JMS-RMI thread inside the
TopicSession execute(~) method blocks trying to deliver a
message to the consumer using onMessage(~); it can't get the
TopicSubscriber lock. The app thread also blocks when calling
removeSubscriber(~) because it can' the TopicSession lock
currently held by the JMS RMI Thread.
Hope this helps.
----------------------------------------------------------------------
Comment By: Tim Anderson (tanderson)
Date: 2005-06-08 14:58
Message:
Logged In: YES
user_id=557161
Can you attach a client and server stack trace?
See http://openjms.sourceforge.net/faq.html if you don't now how
to generate these.
Also update the group field to include the openjms version you
are using.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=474136&aid=1214292&group_id=54559