RE: Blocking jms access after sudden death of openjms server

"Tim Anderson" <[email protected]>
Newsgroups gmane.comp.java.openjms.user
Message-ID <[email protected]>
This is a known problem in 0.7.6.x and earlier,
that has been corrected in 0.7.7-alpha-1.

-Tim 

> -----Original Message-----
> From: openjms-user-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> [mailto:openjms-user-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf 
> Of A. Schiefke (ancosys)
> Sent: Tuesday, 13 December 2005 5:51 AM
> To: [email protected]
> Subject: [openjms-user] Blocking jms access after sudden 
> death of openjms server
> 
> Unter certain circumstances I experience a very strange 
> behaviour of our openjms application.
> 
> A JMS-Server and at least two clients are running on the same 
> WinXP-PC and are exchanging regularely a few messages per 
> second (All openjms 0.7.6.1, using TcpConfiguration and Topics).
> 
> If I kill the jms server process deliberately or deactivate 
> the network connection I experience very often that one or 
> more active threads hang at the following method (Stacktrace 
> from Eclipse, where the problem can be reproduced, sometimes):
> 
> Thread [AN1] (Suspended)
> 	owns: ObjectChannel  (id=104)
> 	owns: JmsTopicSession  (id=123)	
> 	waiting for: LinkedList  (id=122)
> 	Object.wait(long) line: not available [native method]
> 	LinkedList(Object).wait() line: 429
> 	Queue.remove() line: 93
> 	QueueInputStream.receive() line: 93
> 	ObjectChannel.receive() line: 141
> 	IpcJmsSessionStub.checkReply(String) line: 841
> 	IpcJmsSessionStub.createSubscriber(JmsTopic, String, 
> long, String, boolean) line: 451
> 	JmsTopicSession.addSubscriber(JmsTopicSubscriber, 
> String) line: 313
> 	JmsTopicSession.createSubscriber(Topic, String, 
> boolean) line: 160
> 	JmsTopicSession.createSubscriber(Topic) line: 123
> 	JMSManager.sendQuestion(Object, Topic, Topic, String, 
> Serializable, long) line: 393
> 	JMSManager.sendQuestion(Object, Topic, Topic, String, 
> Serializable) line: 734
> 	SystemProxy.executeMethodWithRet(Serializable[]) line: 462
> 	SystemProxy.checkAlive() line: 521
> 	SystemProxy.workAtIdle() line: 669
> 	SystemProxy(MyThread).run() line: 631
> 
> 
> It seems that no other thread feels responsible to call 
> notifyAll() to get out of the wait(). 
> Unfortunately, the classes ObjectChannel, QueueInputStream 
> and Queue are part of exolabcore-0.3.7.jar that is not 
> available as source code, so my debugging possibilities are 
> very limited.
> 
> Question: Which thread ist responsible for waking up the 
> waiting "Queue" and why does it not happen? 
> Shurely there is a kind of timeout in the helper thread when 
> the tcp connection is broken? There seem to be several helper 
> threads on the client side (EventManagerThread, Multiplexer-xx,
> MessageCopier-0) but I am not able to evaluate the right one.
> 
> Any help would be appreciated,
> 
> Andreas Schiefke
> email: [email protected]
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep 
> through log files for problems?  Stop!  Download the new AJAX 
> search engine that makes searching your log files as easy as 
> surfing the  web.  DOWNLOAD SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> openjms-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/openjms-user
> 




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.