1 2 Previous Next 15 Replies Latest reply on Oct 8, 2014 3:57 PM by Justin Bertram

    STOMP destination naming issue

    Dawid Wrobel Newbie

      Hi.

       

      I am having a huge problem here by trying to configure HornetQ to make the /queue/ExampleQueue STOMP destination naming work [1]. I tried configuring an example queue at both core level (hornetq-configuration.xml) and JMS level (hornetq-jms.xml), but I can only get the STOMP communication work when using jms.queue.ExampleQueue destination naming [2].

       

      Now the question is: does HornetQ actually support what I am trying to achieve here? If not, it's quite unfortunate, since ActiveMQ does support it, STOMP documentation uses it in its examples and even some old HornetQ STOMP implementations work fine with it  (e.g. http://github.com/jmesnil/hornetq-stomp). I am perfectly aware that the naming convention is not defined nor limited by STOMP protocol, but still it would be nice if HornetQ supported a de facto standard.

       

      I need to work it out somehow, because the library that I use for STOMP communication (which is apache's NMS for .Net) actually has this naming scheme built in. I could modify the source code but I'd rather not do so to avoid licensing issues.

       

      [1]

      SEND
      destination:/queue/ExampleQueue

      [2]

      SEND
      destination:jms.queue.ExampleQueue
        • 1. STOMP destination naming issue
          qish Newbie

          Hi Dawid,

           

          I know you posted this a long time ago so apologies for reopening it but I was wondering if you had any luck getting /queue/ExampleQeue naming working. I have encountered exactly the same issue with NMS for STOMP 1.5.1 and HornetQ 2.1.2.

           

          Thanks,

          Qish

          • 2. STOMP destination naming issue
            Dawid Wrobel Newbie

            Unfortunately, no. We gave up trying with HornetQ and switched to ActiveMQ, which works fine with NMS - as expected.

            • 3. STOMP destination naming issue
              qish Newbie

              Hi Dawid,


              Thank you for responding.

               

              I resorted to modifying the NMS source code last night which is far from ideal. I have to use HornetQ so I haven't got a choice at the moment.

               

              I am going to contact the HornetQ and NMS developers to see if they can resolve this but I don't hold a lot of hope.

               

              For the benefit of anyone else trying this the modification is in version 1.5.1 of NMS for STOMP. You can download the source here: http://activemq.apache.org/nms/apachenmsstomp-v151.html

               

              Open  Apache.NMS.Stomp.Commands.Destination.cs

              In the ConvertToStompString method the default clause of the switch statement reads: result = "/queue/" + destination.PhysicalName;

              Change to: result = destination.PhysicalName;

               

              I assume you will need to do similar in the same method for Topic, TemporaryTopic and TemporaryQueue.

               

              If I have any luck with NMS/HornetQ I will feedback to this post.

               

              Qish

              • 4. STOMP destination naming issue
                Andy Taylor Master
                I am going to contact the HornetQ and NMS developers to see if they can resolve this but I don't hold a lot of hope.

                Why dont you see a lot of hope , raise a jira and we will see what we can do, altho we are tied up with high priority tasks at the mo.

                 

                Alternatively, we are a community project and would gladly accept contributions if someone wants to write a patch.

                • 5. STOMP destination naming issue
                  qish Newbie

                  Hi Andy,

                   

                  Sorry, that was a little unfair. I guess what I meant was I doubt it'll be fixed in the timeframes I have but I will log a JIRA. The problem for me is that I can't adopt a change to HornetQ but I can for NMS so it would be better for me if NMS changed.

                   

                  I'm guessing that what NMS does is correct for a STOMP connection but the problem is down to HornetQ not implementing the queue naming in the same way STOMP does when it was implemented inside HornetQ. So should NMS change to accomodate standalone STOMP and HornetQ STOMP? If it does, what happens if HornetQ "fixes" its STOMP implementation?

                   

                  Anyway, I will log a JIRA and look at whether I can write a patch for HornetQ. I may not find the time to help with that in the short term now I have a "fix" for my needs but will do my best to help.

                   

                  Cheers,

                  Qish

                  • 6. STOMP destination naming issue
                    Andy Taylor Master

                    raise a jira, we'll see what we can do. unfortunately the guy that wrote the stomp impl is no longer with the project so picking this stuff up will take some time. We actually are doing a release next week so it would have been cool to fix this.

                    • 7. STOMP destination naming issue
                      qish Newbie

                      Apologies for not getting this done on Friday.For some reason I couldn't get JIRA to save my bug, probably I was missing something. Anyway, new bug now logged: https://issues.jboss.org/browse/HORNETQ-657

                      • 8. Re: STOMP destination naming issue
                        jombo wang Newbie

                        i dont think this a bug of HornerQ,refering to the Stomp standard for the  "Send" operation:

                        SEND

                        destination:/queue/a

                         

                        hello queue a

                        ^@


                        This sends a message to the /queue/a destination. This name, by the way, is arbitrary, and despite seeming to indicate that the destination is a "queue" it does not, in fact, specify any such thing. Destination names are simply strings which are mapped to some form of destination on the server - how the server translates these is left to the server

                        but by the way ,it is not a difficult thing for HornetQ to support this destination naming. but i dont know it is necessary or good to support it, may be it will result in  confusion.

                        • 9. Re: STOMP destination naming issue
                          Zheng Wang Newbie

                          Hi,

                           

                          Sorry to dig up the old post. But we have a similar problem: we want to add a stomp client to our msg bus. But for stomp client the topic/queue name must begin with jms.topic or jms.queue. Which is a pain for us to change. As all other components are core hornetq client. They have normal topic name like My.Awesome.Topic.

                           

                          We check the StompSession class, the problem is in the addSubscription method, if a destination is not beginning with jms, it won't create a queue. Then the program will throw an error. Is there any specific reason the jms prefix is a must?

                           

                          Thanks

                          • 10. Re: STOMP destination naming issue
                            Yong Hao Gao Master

                            The reason behind this I think is that HornetQ JMS server uses 'jms.queue/topic' naming convention. So to make sure stomp client can interact with HornetQ JMS clients, the stomp requires the same naming convention. This is of course not part of the spec and each providers may have its own way of doing it (for example ActiveMQ). Any common stomp clients should be able to allow users to use different naming convention to be able to talk to different servers.

                            • 11. Re: STOMP destination naming issue
                              Zheng Wang Newbie

                              STOMP is not a problem.(I'm not the guy who doing the stomp part kidding... ) But we need to modify existing to add that prefix(Or is there a way in hornetq we could link jms.topic.mytopic into mytopic?...) It's a pain.

                               

                              It looks like hornetq have more restrict convention than we thought.

                              • 12. Re: STOMP destination naming issue
                                Yong Hao Gao Master

                                You can consider using a divert to forward messages from one queue to another.

                                • 13. Re: STOMP destination naming issue
                                  Justin Bertram Master

                                  Read this.  It may help you understand the naming scheme better.

                                  • 14. Re: STOMP destination naming issue
                                    Zheng Wang Newbie

                                    Thanks guys for the quick replies. I will check the divert.

                                     

                                    Hi Justin,

                                     

                                    I see the reason why we have this prefix thing in the hornetq. What I don't understand is why the stomp is strongly coupled to jms. I'm not a stomp expert in the team but my understanding is stomp should be independent from jms. I could have a core client send a welcome msg with content "Welcome to My App" to address Welcome.Topic every 5 sec. On the other end stomp client just read and print it. But it seems the prefix is strongly forced (not like other recommendation).

                                     

                                    Sorry for so many questions. I'm trying to understand what's the logic behind it.

                                     

                                    [New Update]

                                    Thanks again for the advice. The divert might work. I might need to do something like this:

                                     

                                    <divert name="prices-divert">

                                       <address>#</address>

                                       <forwarding-address>jms.topic.#</forwarding-address>

                                    </divert>

                                     

                                    What's the performance impact on this? We probably have several hundreds of address in the system and thousands queues on top of that. By doing this basically I double the address size. But we normally send no persistent msg. Then no msg will be lined up. I guess there won't be a huge decrease in performance. Am I right?

                                    1 2 Previous Next