activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-702) [Core JMS Client] Violates JMS 2.0 Specification for JMSConsumer receiveBody error handling
Date Tue, 06 Sep 2016 22:08:22 GMT


ASF GitHub Bot commented on ARTEMIS-702:

Github user johnament commented on the issue:
    @clebertsuconic I'm assuming all the tests you're running are in the code base right?

> [Core JMS Client] Violates JMS 2.0 Specification for JMSConsumer receiveBody error handling
> -------------------------------------------------------------------------------------------
>                 Key: ARTEMIS-702
>                 URL:
>             Project: ActiveMQ Artemis
>          Issue Type: Bug
>    Affects Versions: 1.3.0
>            Reporter: Timothy Bish
>            Assignee: Justin Bertram
>            Priority: Minor
> The JMS 2.0 Specification for the JMSConsumer#receiveBody methods states the following
about how in general the methods work and how body conversion or failure thereof is handled.
> {quote}
> Receives the next message produced for this JMSConsumer and returns its body as an object
of the specified type. This method may be used to receive any type of message except for StreamMessage
and Message, so long as the message has a body which is capable of being assigned to the specified
type. This means that the specified class or interface must either be the same as, or a superclass
or superinterface of, the class of the message body. If the message is not one of the supported
types, or its body cannot be assigned to the specified type, or it has no body, then a MessageFormatRuntimeException
is thrown.
> {quote}
> It then goes on to state that for that in the face of a MessageFormatRuntimeException
the client should do the following:
> {quote}
> AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE: The JMS provider will behave as if the unsuccessful
call to receiveBody had not occurred. The message will be delivered again before any subsequent
> This is not considered to be redelivery and does not cause the JMSRedelivered message
header field to be set or the JMSXDeliveryCount message property to be incremented.
> {quote}
> This does not seem to be the case in the Artemis Core JMS client as the following simple
test seems to show:
> {code}
>    @Test
>    public void testJMSConsumerReceiveBodyHandlesMFECorrectly() throws Exception {
>       final String CONTENT_EXPECTED = "Message-Content";
>       JMSContext context = null;
>       try {
>          context = cf.createContext();
>          JMSProducer producer = context.createProducer();
>          JMSConsumer consumer = context.createConsumer(topic);
>          TextMessage msg = context.createTextMessage(CONTENT_EXPECTED);
>          producer.send(topic, msg);
>          try {
>             consumer.receiveBody(Boolean.class, 2000);
>             fail("Should have thrown MessageFormatRuntimeException");
>          } catch (MessageFormatRuntimeException mfre) {
>          }
>          String received = consumer.receiveBody(String.class, 2000);
>          Assert.assertNotNull(received);
>          Assert.assertEquals(CONTENT_EXPECTED, received);
>       } finally {
>          if (context != null) {
>             context.close();
>          }
>       }
>    }
> {code}
> The specification mandated behaviour is that the message should not be acknowledged and
continue to be redelivered until such time as the receiveBody call actually succeeds.  

This message was sent by Atlassian JIRA

View raw message