Qpid
  1. Qpid
  2. QPID-4389

[Java client] DurableSubscriber resubscription fails when using the 'Address' destination syntax

    Details

    • Type: Bug Bug
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 0.14
    • Fix Version/s: 0.19
    • Component/s: Java Client
    • Labels:
    • Environment:

      Linux,Netbeans 7.2

      Description

      When testing durable subscibers, I first publish a message to a subscriber to be sure it can receive messages. Checks out ok. Then I bring the subscriber down with subscriber.close() where subscriber is an instance of MessageConsumer. Next, I publish another message while the subscriber is down, then I bring the subsciber back up and wait 10 seconds for a message...no message comes. To be sure the everything is working properly, I create another message and publish it, the subscriber has no problem receiving it. My question is where has the second message gone? I would think that the message would have been queued up some place to be sent out again but that is not the case. Please let me know if I am looking at this totally wrong.

      1. qpid.log
        25 kB
        Andrew Burks
      2. DurSubProject.tar.gz
        9 kB
        Andrew Burks

        Activity

        Hide
        Andrew Burks added a comment -

        Attached a test project to show my steps

        Show
        Andrew Burks added a comment - Attached a test project to show my steps
        Hide
        Alex Rudyy added a comment -

        Hi Andrew,

        I looked into this issue and found that with Address based syntax the AMQP 0.10 client did not send the subscriber selector expression as part of arguments of ExchangeBind command on creation of durable subscription. As result, on closing and re-opening of durable subscriber the client tried to check whether expected and real binding arguments match and on matching failure the JMS client deleted and re-created the subscription queue on the broker. That caused the losing of all the messages on the queue.

        I fixed this issue on trunk. You can try to checkout fresh Qpid sources and build the java client from java sub-module by running ant command as follows:

        ant clean build release-bin

        The client build will be created in java/client/release folder.

        Alternatively, you can try to use Binding URL syntax for your topics as described at
        https://cwiki.apache.org/qpid/bindingurlformat.html . The bug does not occur when Binding URL syntax is used.

        Please note that you need to prefix the binding URL with "BURL:" as Address based syntax is used by default in java Qpid client. Also, you can use JVM setting -Dqpid.dest_syntax=BURL to set the Binding URL syntax as a default for all your queues and topics.

        Show
        Alex Rudyy added a comment - Hi Andrew, I looked into this issue and found that with Address based syntax the AMQP 0.10 client did not send the subscriber selector expression as part of arguments of ExchangeBind command on creation of durable subscription. As result, on closing and re-opening of durable subscriber the client tried to check whether expected and real binding arguments match and on matching failure the JMS client deleted and re-created the subscription queue on the broker. That caused the losing of all the messages on the queue. I fixed this issue on trunk. You can try to checkout fresh Qpid sources and build the java client from java sub-module by running ant command as follows: ant clean build release-bin The client build will be created in java/client/release folder. Alternatively, you can try to use Binding URL syntax for your topics as described at https://cwiki.apache.org/qpid/bindingurlformat.html . The bug does not occur when Binding URL syntax is used. Please note that you need to prefix the binding URL with "BURL:" as Address based syntax is used by default in java Qpid client. Also, you can use JVM setting -Dqpid.dest_syntax=BURL to set the Binding URL syntax as a default for all your queues and topics.
        Hide
        Alex Rudyy added a comment -

        Robbie,
        Could you please review the changes?

        Show
        Alex Rudyy added a comment - Robbie, Could you please review the changes?
        Hide
        Andrew Burks added a comment -

        So are you presenting the binding URL as an alternative to creating the subscribers programmatically? What I mean is that if I did not want to upgrade my broker (which would be the case if I use the new code fix), could I use the binding URL to accomplish the same task of my end goal to dynamically create/delete topic subscribers?

        Show
        Andrew Burks added a comment - So are you presenting the binding URL as an alternative to creating the subscribers programmatically? What I mean is that if I did not want to upgrade my broker (which would be the case if I use the new code fix), could I use the binding URL to accomplish the same task of my end goal to dynamically create/delete topic subscribers?
        Hide
        Andrew Burks added a comment -

        After checking out the source code, building at the java sub-module, and starting the server up, I am still running into the same issue where the second message is not being picked up for some reason. Again, the first and last messages are received no problem.

        Show
        Andrew Burks added a comment - After checking out the source code, building at the java sub-module, and starting the server up, I am still running into the same issue where the second message is not being picked up for some reason. Again, the first and last messages are received no problem.
        Hide
        Andrew Burks added a comment -

        I have attached the log if it helps any

        Show
        Andrew Burks added a comment - I have attached the log if it helps any
        Hide
        Robbie Gemmell added a comment -

        Hi Andrew,

        The issue is actually client side as Alex mentioned, so the change made on trunk doesnt involve the broker.

        The use of the Binding URL format is a workaround if you dont want to update to the latest client, as using BindingURL destination format the issue shouldnt occur (and its proably worth mentioning that in addition to the full syntax outlined on the page, you should jsut be able to use "BURL:your.topic.name" and it will use the amq.topic exchange by default, or set the system property as Alex outlined so that you can emit the BURL: prefix). How your program is written probably shouldnt need to change, just the values used for your destinations.

        Robbie

        Show
        Robbie Gemmell added a comment - Hi Andrew, The issue is actually client side as Alex mentioned, so the change made on trunk doesnt involve the broker. The use of the Binding URL format is a workaround if you dont want to update to the latest client, as using BindingURL destination format the issue shouldnt occur (and its proably worth mentioning that in addition to the full syntax outlined on the page, you should jsut be able to use "BURL:your.topic.name" and it will use the amq.topic exchange by default, or set the system property as Alex outlined so that you can emit the BURL: prefix). How your program is written probably shouldnt need to change, just the values used for your destinations. Robbie
        Hide
        Andrew Burks added a comment -

        Ok, so if the issue is with the client, then how am I supposed to test it?

        Show
        Andrew Burks added a comment - Ok, so if the issue is with the client, then how am I supposed to test it?
        Hide
        Alex Rudyy added a comment -

        Hi Andrew,
        I am not sure that I understood your question.
        If you are asking about setting dependencies in pom.xml to newly built client then you can use system maven dependencies
        and can replace your current dependencies with something like

            <dependency>
              <groupId>org.apache.qpid</groupId>
              <artifactId>qpid-common</artifactId>
              <version>0.19</version>
              <scope>system</scope>
              <systemPath>path/to/lib/qpid-common-0.19.jar</systemPath>
            </dependency>
            <dependency>
              <groupId>org.apache.qpid</groupId>
              <artifactId>qpid-client</artifactId>
              <version>0.19</version>
              <scope>system</scope>
              <systemPath>path/to/lib/qpid-client-0.19.jar</systemPath>
            </dependency>
            
             <dependency>
              <groupId>org.apache.geronimo.specs</groupId>
              <artifactId>geronimo-jms_1.1_spec</artifactId>
              <version>1.0</version>
              <scope>provided</scope>
            </dependency>
        
        <dependency>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
            <version>1.6.4</version>
        </dependency>
        
        <dependency>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
            <version>1.2.16</version>
        </dependency>
        
        
        

        In case of using Binding URL, you can replace in your test class line
        Topic topic = ts.createTopic("amq.topic/sitaware.test");
        with
        Topic topic = ts.createTopic("BURL:sitaware.test");

        Show
        Alex Rudyy added a comment - Hi Andrew, I am not sure that I understood your question. If you are asking about setting dependencies in pom.xml to newly built client then you can use system maven dependencies and can replace your current dependencies with something like <dependency> <groupId> org.apache.qpid </groupId> <artifactId> qpid-common </artifactId> <version> 0.19 </version> <scope> system </scope> <systemPath> path/to/lib/qpid-common-0.19.jar </systemPath> </dependency> <dependency> <groupId> org.apache.qpid </groupId> <artifactId> qpid-client </artifactId> <version> 0.19 </version> <scope> system </scope> <systemPath> path/to/lib/qpid-client-0.19.jar </systemPath> </dependency> <dependency> <groupId> org.apache.geronimo.specs </groupId> <artifactId> geronimo-jms_1.1_spec </artifactId> <version> 1.0 </version> <scope> provided </scope> </dependency> <dependency> <groupId> org.slf4j </groupId> <artifactId> slf4j-log4j12 </artifactId> <version> 1.6.4 </version> </dependency> <dependency> <groupId> log4j </groupId> <artifactId> log4j </artifactId> <version> 1.2.16 </version> </dependency> In case of using Binding URL, you can replace in your test class line Topic topic = ts.createTopic("amq.topic/sitaware.test"); with Topic topic = ts.createTopic("BURL:sitaware.test");
        Hide
        Andrew Burks added a comment -

        Thanks Alex, the dependency layout is what I needed to know. I will let you know what I come up with. Again, thanks Alex and Robbie for bearing with me.

        Show
        Andrew Burks added a comment - Thanks Alex, the dependency layout is what I needed to know. I will let you know what I come up with. Again, thanks Alex and Robbie for bearing with me.
        Hide
        Andrew Burks added a comment -

        I've just tested my scenario out and it worked perfectly. Thanks.

        Show
        Andrew Burks added a comment - I've just tested my scenario out and it worked perfectly. Thanks.
        Hide
        Robbie Gemmell added a comment -

        Small note on this JIRA (which I had forgotten about and thus haven't reviewed yet), following QPID-4431 we are now deploying nightly builds to the ASF snapshots repository at https://repository.apache.org/content/repositories/snapshots/

        Show
        Robbie Gemmell added a comment - Small note on this JIRA (which I had forgotten about and thus haven't reviewed yet), following QPID-4431 we are now deploying nightly builds to the ASF snapshots repository at https://repository.apache.org/content/repositories/snapshots/

          People

          • Assignee:
            Robbie Gemmell
            Reporter:
            Andrew Burks
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development