mq
  1. mq
  2. MQ-228

Implement new name and behaviour for the JMSConsumer methods receivePayload and receivePayloadNoWait

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0-RI (JMS2.0), 5.0
    • Fix Version/s: 5.0-RI (Sprint 8 - 26)
    • Component/s: jms-client, mq-ra
    • Labels:
      None

      Description

      JMS_SPEC-102 proposes renaming the JMSConsumer methods receivePayload(Class<T> c), receivePayload(Class<T> c, long timeout) and receivePayloadNoWait(Class<T> c) to receiveBody(Class<T> c), receiveBody(Class<T> c, long timeout) and receiveBodyNoWait(Class<T> c), and changing throw behaviour slightly.

      This issue requests the implementation of that feature.

      Implementation work should not begin until JMS_SPEC-102 is approved by the expert group.

        Issue Links

          Activity

          Hide
          Nigel Deakin added a comment - - edited

          This is now implemented with the exception of the case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE. Currently the message is auto-acknowledged, whereas the JMS 2.0 API requires that the JMS provider behaves as if the unsuccessful call to receiveBody had not occurred and delivers the message again (without setting the redelivery flag) before any subsequent messages. Will leave this issue open until this is implemented.

          Also, the behaviour after a MessageFormatRuntimeException is thrown in the CLIENT_ACKNOWLEDGE and transacted cases needs to be tested.

          Show
          Nigel Deakin added a comment - - edited This is now implemented with the exception of the case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE . Currently the message is auto-acknowledged, whereas the JMS 2.0 API requires that the JMS provider behaves as if the unsuccessful call to receiveBody had not occurred and delivers the message again (without setting the redelivery flag) before any subsequent messages. Will leave this issue open until this is implemented. Also, the behaviour after a MessageFormatRuntimeException is thrown in the CLIENT_ACKNOWLEDGE and transacted cases needs to be tested.
          Hide
          Nigel Deakin added a comment -

          The case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE is now handled in the Java SE client and in JMSRA in TCP mode. However this case is still not handled correctly in JMSRA direct mode.

          New tests have been added to check that a MessageFormatRuntimeException has the correct behaviour (in respect of message delivery) in all modes except JTA.

          Remaining tasks:

          • Add support for the case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE in JMSRA direct mode. (Tests already written).
          • Add tests for JTA transactions (both TCP and direct modes)

          Will leave this issue open until this is implemented.

          Show
          Nigel Deakin added a comment - The case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE is now handled in the Java SE client and in JMSRA in TCP mode. However this case is still not handled correctly in JMSRA direct mode. New tests have been added to check that a MessageFormatRuntimeException has the correct behaviour (in respect of message delivery) in all modes except JTA. Remaining tasks: Add support for the case where a MessageFormatRuntimeException is thrown in AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE in JMSRA direct mode. (Tests already written). Add tests for JTA transactions (both TCP and direct modes) Will leave this issue open until this is implemented.
          Hide
          Nigel Deakin added a comment -

          Now fully implemented and tested.

          Show
          Nigel Deakin added a comment - Now fully implemented and tested.
          Hide
          saradak added a comment -


          Verified as part of the CTS testing.

          Show
          saradak added a comment - Verified as part of the CTS testing.

            People

            • Assignee:
              Nigel Deakin
              Reporter:
              Nigel Deakin
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: