Uploaded image for project: 'AMQ Broker'
  1. AMQ Broker
  2. ENTMQBR-2034

AMQ7: consuming from the same address using multiple consumers, with AMQP producer and CORE consumer, sometimes fails

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • AMQ 7.2.2.GA
    • AMQ 7.2.1.GA
    • core-protocol
    • None
    • Hide
      Cause:
      When using AMQP clients to consume core messages some of the received messages has their body length changed to zero.
      The root cause is a race condition on getProtonMessage / getHeader (see ARTEMIS-2135)

      Consequence:
      AMQP clients won't be able to receive messages correctly.

      Fix:
      The race condition has been corrected.

      Result:
      AMQP clients can receive messages without such error.
      Show
      Cause: When using AMQP clients to consume core messages some of the received messages has their body length changed to zero. The root cause is a race condition on getProtonMessage / getHeader (see ARTEMIS-2135) Consequence: AMQP clients won't be able to receive messages correctly. Fix: The race condition has been corrected. Result: AMQP clients can receive messages without such error.
    • Hide

      1. Unpack the attached coreconsume.zip
      2. Edit src/main/resources/jndi.properties to indicate the broker hostname(s)
      3. Edit App.java to indicate the broker user credentials, if required
      4. mvn package, then run the JAR

      $ java -jar target/coreconsume-0.0.1-jar-with-dependencies.jar [client_id]

      Client ID is arbitrary in this test

      5. Using any AMPQ client, post a message to the broker destination t1. See a ClassCastException when the message is retrieved the second time.

      Show
      1. Unpack the attached coreconsume.zip 2. Edit src/main/resources/jndi.properties to indicate the broker hostname(s) 3. Edit App.java to indicate the broker user credentials, if required 4. mvn package, then run the JAR $ java -jar target/coreconsume-0.0.1-jar-with-dependencies.jar [client_id] Client ID is arbitrary in this test 5. Using any AMPQ client, post a message to the broker destination t1. See a ClassCastException when the message is retrieved the second time.

    Description

      A CORE or CORE-JMS consumer can fail, with an invalid or zero-length message body, in the following circumstances:

      1. The message is produced to an anycast destination using an AMQP client
      2. The message is consumed from that destination using a CORE or CORE-JMS client
      3. The client creates multiple consumers from the same session
      4. The consumers consume from the same topic.

      The code outline below demonstrates the troublesome client behaviour.

      Connection connection = // Create CORE-JMS connection
      Session session = connection.createSession
               (false, Session.AUTO_ACKNOWLEDGE);
      
          Topic topic1 = session.createTopic (TOPIC1);
          Topic topic2 = session.createTopic (TOPIC2);
      
          MessageConsumer consumer1 = session.createConsumer (topic1);
          MessageConsumer consumer2 = session.createConsumer (topic2);
      
          Message m1 = consumer1.receive(); 
          TextMessage t1 = (TextMessage) m1; // Sometimes fails here with a ClassCastException
          System.out.println ("got message 1" + t1.getText());
      
          Message m2 = consumer2.receive();
          TextMessage t2 = (TextMessage) m2;
          System.out.println ("got message 2" + t2.getText());
      

      The problem is not 100% reproducible. When it does reproduce, a CORE consumer gets a message with a zero-length body, while a CORE-JMS client gets a BytesMessage of zero length and whose JMSType property is "null", whatever the original message type was.

      The problem never reproduces (for me) when using an OpenWire producer and CORE consumer, nor an AMQP producer and AMQP consumer – it seems to be related to the specific conversion of AMQP messages to CORE messages.

      Also, the problem never reproduces when the consumers are assigned to different addresses – it seems to be specific to consuming from the same destination with multiple consumers. The code example above is pretty contrived, but the problem reproduces also when the consumers are derived from separate sessions in the same connection, and in different threads (which is a more realistic use of multiple consumers).

      Attachments

        Activity

          People

            gaohoward Howard Gao
            rhn-support-kboone Kevin Boone
            Votes:
            0 Vote for this issue
            Watchers:
            6 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: