[
https://issues.apache.org/jira/browse/ARTEMIS-702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15451991#comment-15451991
]
ASF GitHub Bot commented on ARTEMIS-702:
----------------------------------------
Github user clebertsuconic commented on the issue:
https://github.com/apache/activemq-artemis/pull/741
This change is breaking a lot of tests I have. We can speak offline.
> [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)
