ActiveMQ
  1. ActiveMQ
  2. AMQ-3802

Successful unsubscribing should not report inactive durable topic subscribers

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Not a Problem
    • Affects Version/s: 5.5.1
    • Fix Version/s: None
    • Component/s: Broker
    • Labels:
      None
    • Environment:

      Solaris,Linux

      Description

      An unsubscribe call should remove the client from inactive durable topic subscribers list. In the current broker behavior, even if a durable consumer unsubscribes & shuts down gracefully, the broker marks the durable subscriber as inactive. If this durable subscriber was never meant to come up again(as in my case where i am testing rigorously using unique client-ids each time based on pid) then broker will unnecessarily mark a lot of consumers as inactive durable.

      For inactive durable subscribers, there is no distinction between a subscriber going down abruptly or unsubscribing & going down gracefully.

      This should be improved I think. Moreover, any tips on how to remove those 1000s of inactive subscriptions dangling in my Jconsole ?? Destroying each manually isn't an option !

        Activity

        Hide
        Bhanu added a comment -

        http://activemq.apache.org/manage-durable-subscribers.html can be used but I am quite skeptic to use it.

        Show
        Bhanu added a comment - http://activemq.apache.org/manage-durable-subscribers.html can be used but I am quite skeptic to use it.
        Hide
        Timothy Bish added a comment -

        I added a specific unit test for this and cannot reproduce this, perhaps you can provide a unit test to demonstrate your issue.

        Show
        Timothy Bish added a comment - I added a specific unit test for this and cannot reproduce this, perhaps you can provide a unit test to demonstrate your issue.
        Hide
        Buchi Reddy B added a comment -

        This is easily reproducible with STOMP durable subscribers.

        Please see the below code for example.

        use Net::Stomp;

        my $stomp = Net::Stomp->new(

        { hostname => 'mybroker', port => '61613' }

        );
        $stomp->connect(

        { client-id => 'test_client', login => '', passcode => ''}

        );
        print "connected \n";

        $stomp->subscribe(

        { destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription" }

        );
        print "subscribed \n";
        sleep(3);
        $stomp->unsubscribe(

        {destination => '/topic/test_topic'}

        );
        sleep(2);
        $stomp->disconnect;

        When I run this client, I clearly see that the broker shows the client in inactive durable subscriptions list.

        Show
        Buchi Reddy B added a comment - This is easily reproducible with STOMP durable subscribers. Please see the below code for example. use Net::Stomp; my $stomp = Net::Stomp->new( { hostname => 'mybroker', port => '61613' } ); $stomp->connect( { client-id => 'test_client', login => '', passcode => ''} ); print "connected \n"; $stomp->subscribe( { destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription" } ); print "subscribed \n"; sleep(3); $stomp->unsubscribe( {destination => '/topic/test_topic'} ); sleep(2); $stomp->disconnect; When I run this client, I clearly see that the broker shows the client in inactive durable subscriptions list.
        Hide
        Timothy Bish added a comment -

        Try requesting a receipt for the unsubscribe action so that you are sure that the broker actually processes the request before breaking the socket connection.

        Show
        Timothy Bish added a comment - Try requesting a receipt for the unsubscribe action so that you are sure that the broker actually processes the request before breaking the socket connection.
        Hide
        Bhanu added a comment -

        Thanks Tim !
        Session unsubscribing did the trick for the case where I am using ActiveMQ API. But, using Spring JMSTemplate still leaves behind inactive durable subscribers. Any idea how to unsubscribe in the spring case?

        Show
        Bhanu added a comment - Thanks Tim ! Session unsubscribing did the trick for the case where I am using ActiveMQ API. But, using Spring JMSTemplate still leaves behind inactive durable subscribers. Any idea how to unsubscribe in the spring case?
        Hide
        Buchi Reddy B added a comment -

        @Timothy

        I have tried with receipt feature as well but that does not help. I think there is a real issue for STOMP clients here. I have tried this even from Python clients but same issue is there in Python as well.

        Show
        Buchi Reddy B added a comment - @Timothy I have tried with receipt feature as well but that does not help. I think there is a real issue for STOMP clients here. I have tried this even from Python clients but same issue is there in Python as well.
        Hide
        Timothy Bish added a comment -

        I added an addition to testDurableUnsub in StompTest.java to show that when the unsubscribe is sent with the correct headers it works as expected. The above stomp code doesn't set the 'activemq.subscriptionName' on the unsubscribe so it won't actually unsub anything.

        Show
        Timothy Bish added a comment - I added an addition to testDurableUnsub in StompTest.java to show that when the unsubscribe is sent with the correct headers it works as expected. The above stomp code doesn't set the 'activemq.subscriptionName' on the unsubscribe so it won't actually unsub anything.
        Hide
        Timothy Bish added a comment -

        Code is working as designed, issue is on the client end.

        Show
        Timothy Bish added a comment - Code is working as designed, issue is on the client end.
        Hide
        Buchi Reddy B added a comment -

        @Timothy I have actually tried to unsubscribe with 'activemq.subscriptionName' also but that doesn't work. Did you try to test with the above Perl code instead of using Java Stomp Client?

        Show
        Buchi Reddy B added a comment - @Timothy I have actually tried to unsubscribe with 'activemq.subscriptionName' also but that doesn't work. Did you try to test with the above Perl code instead of using Java Stomp Client?
        Hide
        Buchi Reddy B added a comment -

        I think the Java STOMP client and Perl STOMP client are behaving differently here and that is the reason we are seeing this issue still with Perl clients.

        Did you guys try with simple Perl client I have mentioned above?

        Show
        Buchi Reddy B added a comment - I think the Java STOMP client and Perl STOMP client are behaving differently here and that is the reason we are seeing this issue still with Perl clients. Did you guys try with simple Perl client I have mentioned above?
        Hide
        Timothy Bish added a comment -

        The perl sample doesn't send a proper unsubscribe with the subscription name so it will definitely not work.

        Show
        Timothy Bish added a comment - The perl sample doesn't send a proper unsubscribe with the subscription name so it will definitely not work.
        Hide
        Buchi Reddy B added a comment -

        @Timothy

        As I have mentioned already, I have tried to give the 'activemq.subscriptionName' in the unsubscribe call as well but still seeing this issue.

        Can you please try this problem with this code?

        use Net::Stomp;

        my $stomp = Net::Stomp->new(

        { hostname => 'mybroker', port => '61613' }

        );

        $stomp->connect(

        { client-id => 'test_client', login => '', passcode => ''}

        );
        print "connected \n";

        $stomp->subscribe(

        { destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription" }

        );
        print "subscribed \n";

        sleep(3);
        $stomp->unsubscribe(

        {destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription"}

        );

        sleep(2);
        $stomp->disconnect;

        And, to give more details to you, in Jconsole of the broker, I clearly see that the subscription is shown as test_subscription under the Durable topics before the client sends unsubscribe and is being shown under "false" topics with the following name after the client unsubscribes.
        ID_infraprod1.hyd.deshaw.com-34343-1335687381802-2_13_test_subscription

        Does this give any clue?

        Show
        Buchi Reddy B added a comment - @Timothy As I have mentioned already, I have tried to give the 'activemq.subscriptionName' in the unsubscribe call as well but still seeing this issue. Can you please try this problem with this code? use Net::Stomp; my $stomp = Net::Stomp->new( { hostname => 'mybroker', port => '61613' } ); $stomp->connect( { client-id => 'test_client', login => '', passcode => ''} ); print "connected \n"; $stomp->subscribe( { destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription" } ); print "subscribed \n"; sleep(3); $stomp->unsubscribe( {destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription"} ); sleep(2); $stomp->disconnect; And, to give more details to you, in Jconsole of the broker, I clearly see that the subscription is shown as test_subscription under the Durable topics before the client sends unsubscribe and is being shown under "false" topics with the following name after the client unsubscribes. ID_infraprod1.hyd.deshaw.com-34343-1335687381802-2_13_test_subscription Does this give any clue?
        Hide
        Timothy Bish added a comment -

        Your Stomp client must supply the same value for clientId and subscriptionName, refer to:
        http://activemq.apache.org/stomp.html

        Try changing your code to use the same subscription Id as the client Id and it should start working as expected.

        Show
        Timothy Bish added a comment - Your Stomp client must supply the same value for clientId and subscriptionName, refer to: http://activemq.apache.org/stomp.html Try changing your code to use the same subscription Id as the client Id and it should start working as expected.
        Hide
        Buchi Reddy B added a comment -

        @Timothy,

        I have changed the code to give same id on client-id and 'activemq.subscriptionName' but still helpless.

        I tried running broker in DEBUG logging mode and I see the below log messages in broker when I run this client. I am putting them if they can help you to debug this issue further.

        2012-05-02 17:28:14,299 | INFO | Removing subscription : RemoveSubscriptionInfo

        Unknown macro: {commandId = 4, responseRequired = false, connec tionId = ID}

        |
        org.apache.activemq.broker.util.LoggingBrokerPlugin | ActiveMQ Transport: tcp:///149.77.160.37:63026
        2012-05-02 17:28:14,304 | DEBUG | Error occured while processing async command: RemoveSubscriptionInfo

        Unknown macro: {commandId = 4, responseRequired = false, connectionId = ID}

        , exception: javax.jms.InvalidDestinationException: No durable subscription exists for: test_subscription | org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: tcp:///149.77.160.37:63026
        javax.jms.InvalidDestinationException: No durable subscription exists for: test_subscription
        at org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:135)
        at org.apache.activemq.broker.region.RegionBroker.removeSubscription(RegionBroker.java:491)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107)
        at org.apache.activemq.broker.util.LoggingBrokerPlugin.removeSubscription(LoggingBrokerPlugin.java:211)
        at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107)
        at org.apache.activemq.broker.TransportConnection.processRemoveSubscription(TransportConnection.java:342)
        at org.apache.activemq.command.RemoveSubscriptionInfo.visit(RemoveSubscriptionInfo.java:81)
        at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:306)
        at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179)
        at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69)
        at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:81)
        at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:140)
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:456)
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:190)
        at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:70)
        at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
        at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220)
        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202)
        at java.lang.Thread.run(Thread.java:722)

        Show
        Buchi Reddy B added a comment - @Timothy, I have changed the code to give same id on client-id and 'activemq.subscriptionName' but still helpless. I tried running broker in DEBUG logging mode and I see the below log messages in broker when I run this client. I am putting them if they can help you to debug this issue further. 2012-05-02 17:28:14,299 | INFO | Removing subscription : RemoveSubscriptionInfo Unknown macro: {commandId = 4, responseRequired = false, connec tionId = ID} | org.apache.activemq.broker.util.LoggingBrokerPlugin | ActiveMQ Transport: tcp:///149.77.160.37:63026 2012-05-02 17:28:14,304 | DEBUG | Error occured while processing async command: RemoveSubscriptionInfo Unknown macro: {commandId = 4, responseRequired = false, connectionId = ID} , exception: javax.jms.InvalidDestinationException: No durable subscription exists for: test_subscription | org.apache.activemq.broker.TransportConnection.Service | ActiveMQ Transport: tcp:///149.77.160.37:63026 javax.jms.InvalidDestinationException: No durable subscription exists for: test_subscription at org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:135) at org.apache.activemq.broker.region.RegionBroker.removeSubscription(RegionBroker.java:491) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107) at org.apache.activemq.broker.util.LoggingBrokerPlugin.removeSubscription(LoggingBrokerPlugin.java:211) at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107) at org.apache.activemq.broker.TransportConnection.processRemoveSubscription(TransportConnection.java:342) at org.apache.activemq.command.RemoveSubscriptionInfo.visit(RemoveSubscriptionInfo.java:81) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:306) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69) at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:81) at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:140) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:456) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:190) at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:70) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202) at java.lang.Thread.run(Thread.java:722)
        Hide
        Bhanu added a comment -

        Tim,

        I was playing around with Buchi's test, made some pretty minor changes and I am getting the below exception that durable consumer is in use !

        2012-05-03 10:59:21,204 | INFO | Removing subscription : RemoveSubscriptionInfo

        {commandId = 4, responseRequired = false, connectionId = ID:desh0007.hyd.desh aw.com-59732-1336021109112-3:8, clientId = test, subscriptionName = test}

        | org.apache.activemq.broker.util.LoggingBrokerPlugin | ActiveMQ Transport: tcp:///1
        0.240.170.27:42262
        2012-05-03 10:59:21,205 | WARN | Async error occurred: javax.jms.JMSException: Durable consumer is in use | org.apache.activemq.broker.TransportConnection.S
        ervice | ActiveMQ Transport: tcp:///10.240.170.27:42262
        javax.jms.JMSException: Durable consumer is in use
        at org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:138)
        at org.apache.activemq.broker.region.RegionBroker.removeSubscription(RegionBroker.java:491)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107)
        at org.apache.activemq.broker.util.LoggingBrokerPlugin.removeSubscription(LoggingBrokerPlugin.java:211)
        at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101)
        at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107)
        at org.apache.activemq.broker.TransportConnection.processRemoveSubscription(TransportConnection.java:342)
        at org.apache.activemq.command.RemoveSubscriptionInfo.visit(RemoveSubscriptionInfo.java:81)
        at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:306)
        at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179)
        at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69)
        at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:81)
        at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:140)
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:456)
        at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:190)
        at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:70)
        at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83)
        at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220)
        at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202)
        at java.lang.Thread.run(Thread.java:722)
        2012-05-03 10:59:21,205 | WARN | Exception occurred processing:
        null: javax.jms.JMSException: Durable consumer is in use | org.apache.activemq.transport.stomp.ProtocolConverter | ActiveMQ Connection Dispatcher: /10.240.170.27:42262

        Any clues !?

        Show
        Bhanu added a comment - Tim, I was playing around with Buchi's test, made some pretty minor changes and I am getting the below exception that durable consumer is in use ! 2012-05-03 10:59:21,204 | INFO | Removing subscription : RemoveSubscriptionInfo {commandId = 4, responseRequired = false, connectionId = ID:desh0007.hyd.desh aw.com-59732-1336021109112-3:8, clientId = test, subscriptionName = test} | org.apache.activemq.broker.util.LoggingBrokerPlugin | ActiveMQ Transport: tcp:///1 0.240.170.27:42262 2012-05-03 10:59:21,205 | WARN | Async error occurred: javax.jms.JMSException: Durable consumer is in use | org.apache.activemq.broker.TransportConnection.S ervice | ActiveMQ Transport: tcp:///10.240.170.27:42262 javax.jms.JMSException: Durable consumer is in use at org.apache.activemq.broker.region.TopicRegion.removeSubscription(TopicRegion.java:138) at org.apache.activemq.broker.region.RegionBroker.removeSubscription(RegionBroker.java:491) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107) at org.apache.activemq.broker.util.LoggingBrokerPlugin.removeSubscription(LoggingBrokerPlugin.java:211) at org.apache.activemq.broker.BrokerFilter.removeSubscription(BrokerFilter.java:101) at org.apache.activemq.broker.MutableBrokerFilter.removeSubscription(MutableBrokerFilter.java:107) at org.apache.activemq.broker.TransportConnection.processRemoveSubscription(TransportConnection.java:342) at org.apache.activemq.command.RemoveSubscriptionInfo.visit(RemoveSubscriptionInfo.java:81) at org.apache.activemq.broker.TransportConnection.service(TransportConnection.java:306) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:179) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:69) at org.apache.activemq.transport.stomp.StompTransportFilter.sendToActiveMQ(StompTransportFilter.java:81) at org.apache.activemq.transport.stomp.ProtocolConverter.sendToActiveMQ(ProtocolConverter.java:140) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompUnsubscribe(ProtocolConverter.java:456) at org.apache.activemq.transport.stomp.ProtocolConverter.onStompCommand(ProtocolConverter.java:190) at org.apache.activemq.transport.stomp.StompTransportFilter.onCommand(StompTransportFilter.java:70) at org.apache.activemq.transport.TransportSupport.doConsume(TransportSupport.java:83) at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:220) at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:202) at java.lang.Thread.run(Thread.java:722) 2012-05-03 10:59:21,205 | WARN | Exception occurred processing: null: javax.jms.JMSException: Durable consumer is in use | org.apache.activemq.transport.stomp.ProtocolConverter | ActiveMQ Connection Dispatcher: /10.240.170.27:42262 Any clues !?
        Hide
        Timothy Bish added a comment -

        The error you are seeing is telling you that your Stomp client is still actively subscribed to the destination, so you are almost there. To fully unsubscribe a durable consumer you need to first do a normal unsubscribe as you were previously doing such that there are no active durable subscribers, then you can issue the unsubscribe using the client id to completely eliminate that subscription.

        Show
        Timothy Bish added a comment - The error you are seeing is telling you that your Stomp client is still actively subscribed to the destination, so you are almost there. To fully unsubscribe a durable consumer you need to first do a normal unsubscribe as you were previously doing such that there are no active durable subscribers, then you can issue the unsubscribe using the client id to completely eliminate that subscription.
        Hide
        Bhanu added a comment -

        Presto !!! Works like a charm for me

        Thanks Tim. We should let Buchi also confirm this.

        Show
        Bhanu added a comment - Presto !!! Works like a charm for me Thanks Tim. We should let Buchi also confirm this.
        Hide
        Buchi Reddy B added a comment -

        Okay. It works finally with the following code though without using client-id while unsubscribing.

        $stomp->unsubscribe(

        Unknown macro: {destination => '/topic/test_topic'}

        );
        $stomp->unsubscribe(

        Unknown macro: {destination => '/topic/test_topic', 'activemq.subscriptionName' => 'test_subscription'}

        );

        @Timothy I find this design a little weird. Do we have any reasons on why the design is like this?
        Also, I see that this works only if client-id given while subscribing is same as the subscription name. I do not see any legitimate reason for doing that also. Can you please give us some background details for this? Or share some wiki page which throws more light on this please.

        FWIW, I feel that we should merge those two unsubscribe calls into one, to make best client side design for this case. Can you give your opinion on that?

        Show
        Buchi Reddy B added a comment - Okay. It works finally with the following code though without using client-id while unsubscribing. $stomp->unsubscribe( Unknown macro: {destination => '/topic/test_topic'} ); $stomp->unsubscribe( Unknown macro: {destination => '/topic/test_topic', 'activemq.subscriptionName' => 'test_subscription'} ); @Timothy I find this design a little weird. Do we have any reasons on why the design is like this? Also, I see that this works only if client-id given while subscribing is same as the subscription name. I do not see any legitimate reason for doing that also. Can you please give us some background details for this? Or share some wiki page which throws more light on this please. FWIW, I feel that we should merge those two unsubscribe calls into one, to make best client side design for this case. Can you give your opinion on that?
        Hide
        Buchi Reddy B added a comment -

        There seems to be another issue if a single client has multiple durable subscriptions. If the client-id and subscriptionName should be same for a durable subscription, how can the same client subscribe to a second durable namespace? I have tried this and saw that broker sends error message indicating there is a durable subscriber already with the same client-id and subscriptionName.

        Can you please suggest us how to fix this?

        Show
        Buchi Reddy B added a comment - There seems to be another issue if a single client has multiple durable subscriptions. If the client-id and subscriptionName should be same for a durable subscription, how can the same client subscribe to a second durable namespace? I have tried this and saw that broker sends error message indicating there is a durable subscriber already with the same client-id and subscriptionName. Can you please suggest us how to fix this?
        Hide
        Timothy Bish added a comment -

        Can you post a sample of you stomp client subscribing to two durables?

        Show
        Timothy Bish added a comment - Can you post a sample of you stomp client subscribing to two durables?
        Hide
        Buchi Reddy B added a comment -
        
        use Net::Stomp;
        my $stomp = Net::Stomp->new( { hostname => 'brokerhost', port => '61613' } );
        
        $stomp->connect( { 'client-id' => 'test_subscription', login => '', passcode => ''} );
        print "connected \n";
        
        $stomp->subscribe({ destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription"});
        $stomp->subscribe({ destination => '/topic/test_topic1', 'activemq.subscriptionName' => "test_subscription"});
        
        print "subscribed \n";
        
        sleep(5);
        
        $stomp->unsubscribe({destination => '/topic/test_topic' });
        $stomp->unsubscribe({destination => '/topic/test_topic', 'activemq.subscriptionName' => 'test_subscription' });
        $stomp->unsubscribe({destination => '/topic/test_topic1' });
        $stomp->unsubscribe({destination => '/topic/test_topic1', 'activemq.subscriptionName' => 'test_subscription' });
        print "unsubscribed \n";
        
        $stomp->disconnect();
        
        Show
        Buchi Reddy B added a comment - use Net::Stomp; my $stomp = Net::Stomp-> new ( { hostname => 'brokerhost', port => '61613' } ); $stomp->connect( { 'client-id' => 'test_subscription', login => '', passcode => ''} ); print "connected \n" ; $stomp->subscribe({ destination => '/topic/test_topic', 'activemq.subscriptionName' => "test_subscription" }); $stomp->subscribe({ destination => '/topic/test_topic1', 'activemq.subscriptionName' => "test_subscription" }); print "subscribed \n" ; sleep(5); $stomp->unsubscribe({destination => '/topic/test_topic' }); $stomp->unsubscribe({destination => '/topic/test_topic', 'activemq.subscriptionName' => 'test_subscription' }); $stomp->unsubscribe({destination => '/topic/test_topic1' }); $stomp->unsubscribe({destination => '/topic/test_topic1', 'activemq.subscriptionName' => 'test_subscription' }); print "unsubscribed \n" ; $stomp->disconnect();
        Hide
        Buchi Reddy B added a comment -

        @Timothy any updates here? Did you get a chance to look at this?

        Show
        Buchi Reddy B added a comment - @Timothy any updates here? Did you get a chance to look at this?
        Hide
        Timothy Bish added a comment -

        This is another limitation of the Stomp support which allows for only one durable subscription since clientId and subscription name are linked. This is because the Stomp v1.0 spec didn't require that you assign unique Ids to subscriptions, so the correlation is made per connection using the matching clientId and subscription name. You can work around this by creating a connection for each durable subscriber.

        Show
        Timothy Bish added a comment - This is another limitation of the Stomp support which allows for only one durable subscription since clientId and subscription name are linked. This is because the Stomp v1.0 spec didn't require that you assign unique Ids to subscriptions, so the correlation is made per connection using the matching clientId and subscription name. You can work around this by creating a connection for each durable subscriber.
        Hide
        Buchi Reddy B added a comment -

        Okay. Are we going to fix this in future versions of ActiveMQ? Should I log a separate request for the enhancement?

        I think STOMP v1.1 mandates a separate id for each subscription so even if you talk in terms of STOMP v1.1 spec, ActiveMQ should support this feature.

        Show
        Buchi Reddy B added a comment - Okay. Are we going to fix this in future versions of ActiveMQ? Should I log a separate request for the enhancement? I think STOMP v1.1 mandates a separate id for each subscription so even if you talk in terms of STOMP v1.1 spec, ActiveMQ should support this feature.

          People

          • Assignee:
            Unassigned
            Reporter:
            Bhanu
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development