[ 
https://issues.apache.org/jira/browse/ARTEMIS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511168#comment-15511168
 ] 

ASF GitHub Bot commented on ARTEMIS-702:
----------------------------------------

Github user jbertram closed the pull request at:

    https://github.com/apache/activemq-artemis/pull/741


> [Core JMS Client] Violates JMS 2.0 Specification for JMSConsumer receiveBody 
> error handling
> -------------------------------------------------------------------------------------------
>
>                 Key: ARTEMIS-702
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-702
>             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 messages.
> 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
(v6.3.4#6332)

Reply via email to