[ 
https://issues.apache.org/jira/browse/AMQ-3874?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295037#comment-13295037
 ] 

Gary Tully commented on AMQ-3874:
---------------------------------

A thread dump of the broker will give an indication if there are any 
connections pending or pending close.

when the perl client goes away, it is the tcp client side socket that closes 
but it may not initiate the broker side close, that may need to timeout the 
read or even a pending write. I presume with lsof you are trying to eliminate 
that. Are u using it on the broker side?
                
> Unable to destroy a durable subscription
> ----------------------------------------
>
>                 Key: AMQ-3874
>                 URL: https://issues.apache.org/jira/browse/AMQ-3874
>             Project: ActiveMQ
>          Issue Type: Bug
>          Components: Broker
>    Affects Versions: 5.5.1
>         Environment: solaris, linux
>            Reporter: Bhanu
>
> I think theres an issue that occurs sometimes while removing durable 
> subscriptions from the broker. This has hit us second time in a week that 
> when a perl durable subscriber using stomp goes down, it is not shown as 
> inactive in broker. Even though there were no active connections(did a 
> thorough lsof check) somehow broker thought that the subscriber was active. 
> Whats more worse is trying to destroy that subscription via jconsole gives an 
> error :
> "Problem invoking destroy: java.rmi.UnmarshallException: Error unmarshalling 
> return; nested exception is java.lang.ClassNotFoundException: 
> javax.jms.InvalidDestinationException (no security manager: RMI class loader 
> disabled)"
> Since we cannot destroy this subscription, the client cannot come up with the 
> same client Id and subscription name. This is not reproducible easily
> but is some weird corner case. Can somebody please check. Let me know if you 
> have more queries.
> Thanks & Regards
> Bhanu

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Reply via email to