[jira] [Commented] (ARTEMIS-702) [Core JMS Client] Violates JMS 2.0 Specification for JMSConsumer receiveBody error handling

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

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

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

Github user clebertsuconic commented on the issue:

    https://github.com/apache/activemq-artemis/pull/741
  
    This is introducing some sort of leak. tests won't complete.


> [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)