ActiveMQ
  1. ActiveMQ
  2. AMQ-3836

STOMP 1.0 protocol (SUBSCRIBE destination) broken on ActiveMQ 5.6.0

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.6.0
    • Fix Version/s: 5.7.0
    • Component/s: stomp
    • Labels:
      None
    • Environment:

      Centos 5 running Apache ActiveMQ 5.6.0, jre-1.6.0_20-fcs

      Description

      Destination specification on STOMP using activemq 5.6.0 is broken.

      Before 5.6.0, you had to specify "/queue/my_queue". Now, activemq automatically includes a "/queue/" on destination name, whether needed or not.

      For instance, sending messages to "/queue/nagios-events" works. Subscribing to "/queue/nagios-events" creates an additional queue named "/queue/queue/nagios-events".

      Message sending is also affected, although it accepts both "/queue/nagios-events" and "nagios-events"

      1. firsttony.php
        2 kB
        Alan Hudson

        Activity

        Deives Michellis created issue -
        Hide
        Timothy Bish added a comment -

        Recommend you create a JUnit test case to demonstrate your issue.

        Show
        Timothy Bish added a comment - Recommend you create a JUnit test case to demonstrate your issue.
        Hide
        Deives Michellis added a comment -

        I have absolutely no idea how to do that. I am not a java guy, sorry

        Show
        Deives Michellis added a comment - I have absolutely no idea how to do that. I am not a java guy, sorry
        Hide
        Timothy Bish added a comment -

        StompTest.java in our unit tests has plenty of examples, barring that please create a test case using the client you are currently using.

        Show
        Timothy Bish added a comment - StompTest.java in our unit tests has plenty of examples, barring that please create a test case using the client you are currently using.
        Hide
        Timothy Bish added a comment -

        You'll need to provide a test case, can't reproduce this so far.

        Show
        Timothy Bish added a comment - You'll need to provide a test case, can't reproduce this so far.
        Hide
        Alan Hudson added a comment -

        I'm seeing the same problem. We're using a modified first.php from the fuse php client. I'll clean it up and attach it.

        Show
        Alan Hudson added a comment - I'm seeing the same problem. We're using a modified first.php from the fuse php client. I'll clean it up and attach it.
        Hide
        Alan Hudson added a comment -

        modified first.php from fuse stomp php client. the result on 5.5.1 comes back as:

        Notice the destination has a /queue on it in 5.6.0 We checked the STOMP frame and its not coming from the client.

        In 5.5.1 we get this result:

        Received headers
        s_scale => 0.001
        message-id => ID:tony-desktop-53600-1338396365864-2:12:-1:1:1
        d_serviceName => ModelUpload
        destination => /topic/testtopic
        timestamp => 1338399414341
        s_modelID => 123456
        expires => 0
        priority => 4

        In 5.6.0 we get this result:

        Received headers
        s_scale => 0.001
        message-id => ID:maker-55961-1338400788753-2:2:-1:1:1
        d_serviceName => ModelUpload
        destination => /queue//topic/testtopic
        timestamp => 1338401617112
        s_modelID => 123456
        expires => 0
        priority => 4

        Here is the frame that was sent:

        SEND
        d_serviceName: ModelUpload
        s_modelID: 123456
        s_scale: 0.001
        destination: /topic/testtopic

        test


        I suspect its something in the FrameTranslator, digging in there.

        Show
        Alan Hudson added a comment - modified first.php from fuse stomp php client. the result on 5.5.1 comes back as: Notice the destination has a /queue on it in 5.6.0 We checked the STOMP frame and its not coming from the client. In 5.5.1 we get this result: Received headers s_scale => 0.001 message-id => ID:tony-desktop-53600-1338396365864-2:12:-1:1:1 d_serviceName => ModelUpload destination => /topic/testtopic timestamp => 1338399414341 s_modelID => 123456 expires => 0 priority => 4 In 5.6.0 we get this result: Received headers s_scale => 0.001 message-id => ID:maker-55961-1338400788753-2:2:-1:1:1 d_serviceName => ModelUpload destination => /queue//topic/testtopic timestamp => 1338401617112 s_modelID => 123456 expires => 0 priority => 4 Here is the frame that was sent: SEND d_serviceName: ModelUpload s_modelID: 123456 s_scale: 0.001 destination: /topic/testtopic test — I suspect its something in the FrameTranslator, digging in there.
        Alan Hudson made changes -
        Field Original Value New Value
        Attachment firsttony.php [ 12530245 ]
        Hide
        Timothy Bish added a comment -

        Why not try and reproduce it with a JUnit test? There's already a large number of them in StompTest.java to work from.

        Show
        Timothy Bish added a comment - Why not try and reproduce it with a JUnit test? There's already a large number of them in StompTest.java to work from.
        Hide
        Alan Hudson added a comment -

        I will. Just getting my head around the problem, so far we're learning stomp from the php client.

        Show
        Alan Hudson added a comment - I will. Just getting my head around the problem, so far we're learning stomp from the php client.
        Hide
        Alan Hudson added a comment -

        The issue is with STOMP clients that put spaces after values as in destination: /topic/test

        The convert destination method in LegacyFrameTranslator does a startsWith("/topic") to detect topics.

        The fuse stomp php client puts a space on items. My read of the stomp spec shows examples without it. But it doesn't really make it clear. We're looking around at a few other clients to see what they do.

        If its common of clients then it might make sense to deal with it on the server. The other php stomp client does not put spaces in its values.

        I can easily make a junit test for this case if you want it, but I kinda expect this will be labeled under "client error" or maybe incomplete spec language(my pet peeve).

        Show
        Alan Hudson added a comment - The issue is with STOMP clients that put spaces after values as in destination: /topic/test The convert destination method in LegacyFrameTranslator does a startsWith("/topic") to detect topics. The fuse stomp php client puts a space on items. My read of the stomp spec shows examples without it. But it doesn't really make it clear. We're looking around at a few other clients to see what they do. If its common of clients then it might make sense to deal with it on the server. The other php stomp client does not put spaces in its values. I can easily make a junit test for this case if you want it, but I kinda expect this will be labeled under "client error" or maybe incomplete spec language(my pet peeve).
        Hide
        Alan Hudson added a comment -

        I found this language in the STOMP specification under Value Encoding:

        The STOMP 1.0 specification included many example frames with padding in the headers and many servers and clients were implemented to trim or pad header values. This causes problems if applications want to send headers that SHOULD not get trimmed. In STOMP 1.1, clients and servers MUST never trim or pad headers with spaces.

        So I believe we should not do any space removal. I think this ticket can be closed.

        Show
        Alan Hudson added a comment - I found this language in the STOMP specification under Value Encoding: The STOMP 1.0 specification included many example frames with padding in the headers and many servers and clients were implemented to trim or pad header values. This causes problems if applications want to send headers that SHOULD not get trimmed. In STOMP 1.1, clients and servers MUST never trim or pad headers with spaces. So I believe we should not do any space removal. I think this ticket can be closed.
        Hide
        Timothy Bish added a comment -

        Agreed the spec was a bit vague in this regard. In 5.6 we removed the header trimming in order to not discard spaces that a client had intentionally placed there. It might be good to at least do a test on a trimmed destination value before assuming its a queue and getting into this scenario.

        Show
        Timothy Bish added a comment - Agreed the spec was a bit vague in this regard. In 5.6 we removed the header trimming in order to not discard spaces that a client had intentionally placed there. It might be good to at least do a test on a trimmed destination value before assuming its a queue and getting into this scenario.
        tabish committed 1344894 (1 file)
        Reviews: none

        fix for: https://issues.apache.org/jira/browse/AMQ-3836

        Make a best effort to find the correct destination name even if space padded before falling back to the fallback conversion config.

        Hide
        Timothy Bish added a comment -

        Fixed to attempt to find the right destination with spaces padding trimmed before falling back to the configured fallback handler. Also updated the Stomp PHP client to not pad headers.

        Show
        Timothy Bish added a comment - Fixed to attempt to find the right destination with spaces padding trimmed before falling back to the configured fallback handler. Also updated the Stomp PHP client to not pad headers.
        Timothy Bish made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Assignee Timothy Bish [ tabish121 ]
        Fix Version/s 5.7.0 [ 12321258 ]
        Resolution Fixed [ 1 ]

          People

          • Assignee:
            Timothy Bish
            Reporter:
            Deives Michellis
          • Votes:
            2 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development