9 Replies Latest reply on Mar 10, 2010 1:24 PM by clebert.suconic

    Clustered Topic tests

    clebert.suconic

      Do we have any JMS topic tests done in cluster?

       

       

      I have had a few failures happening on the AS6 testsuite and it was being something annoying.. it would always pass individually.

       

      It appears that the bindings are not getting undeployed after the Topic is destroyed (by calling ServerControl.destroyTopic).

       

       

      I was going to write a test for this, but I don't see anything similar. So I guess I'm not mistaken and we don't have any test like that. (Just using the core queues for those)

        • 1. Re: Clustered Topic tests
          clebert.suconic

          Well, since I didn't find one.. I have created it.

           

          On the test I created.. (still on my local workspace only) I'm just creating a topic, and deleting it while the server is cluetered.

           

           

          And I can't delete the topic, as i will always have the message "There are consumers" because of the Bridge listening to the topic.

          • 2. Re: Clustered Topic tests
            timfox
            There's no such thing as a clustered topic in HornetQ, it's just a topic.
            • 3. Re: Clustered Topic tests
              clebert.suconic

              By Clustered Topic I mean... topics running over a clustered connection.

               

              I didn't mean that there is a Clustered property on the Topic like it was on JBM.

               

              It's just Topics under cluster. (Just a language usage here).

               

               

              Anyway.. we can't delete any queues after them are installed on the Bridge through the ClusteredConnection.

              • 4. Re: Clustered Topic tests
                clebert.suconic

                The issue I have is with the new new (corrected) implementation of destroyTopic:

                 

                   public synchronized boolean destroyTopic(final String name) throws Exception
                   {
                      checkInitialised();
                      undeployDestination(name);
                
                      destinations.remove(name);
                      jmsManagementService.unregisterTopic(name);
                      AddressControl addressControl = (AddressControl)server.getManagementService().getResource(ResourceNames.CORE_ADDRESS + HornetQDestination.createTopicAddressFromName(name));
                      if (addressControl != null)
                      {
                         for (String queueName : addressControl.getQueueNames())
                         {
                            server.getHornetQServerControl().destroyQueue(queueName);
                         }
                      }
                      return true;
                   }
                
                 
                

                 

                 

                This code is deleting all the queues associated with the address. There is a bridge address that should just be removed from the Address.. and not deleted.

                • 5. Re: Clustered Topic tests
                  jmesnil

                  I am not sure if it is "clean" but you can check if the queue name correspond to the cluster connection's queue (starts with "sf.") before destroying it.

                   

                  Bridge queues are named at ClusterConnectionImpl:410

                  • 6. Re: Clustered Topic tests
                    clebert.suconic

                    I will check for that..

                     

                     

                    Also: The delete for Topic is not atomic ATM, right?

                     

                     

                    Say.. you call deleteTopic on management.

                     

                     

                    The code is removing a bunch of management objects associated with the address... and then it will remove each queue associated with the topic.

                     

                     

                    On this case you only have one chance to remove the topic. Say you forgot a consumer on.. you will get the exception but you won't be able to call deleteTopic again as the queue was already removed.

                     

                     

                    I can of course delete the queues first.. but part of the queues associated with the subscription will be already gone.

                     

                     

                    I don't know how.. but as an user I think this should be atomic.

                     

                     

                    I'm not sure if that's an issue. What do you think?

                    • 7. Re: Clustered Topic tests
                      clebert.suconic
                      BTW: By "I will check into that" I meant.. i will check for the proper way to fix it.
                      • 8. Re: Clustered Topic tests
                        clebert.suconic

                        I am going to change the deleteTopic method to check if the binding on the queue is a RemoteBinding.

                         

                        So far the only way to check that is by an instanceof. Instead of doing the instanceof check I will add a method to the Binding interface (isRemote) and implement it on its subclasses.

                        • 9. Re: Clustered Topic tests
                          clebert.suconic
                          Actually no.. there is a getType() already on the Binding.. so I will use the getType(). no need for isRemote()