[jboss-jira] [JBoss JIRA] Assigned: (JBMESSAGING-1079) JBM should call BytesMessage.reset() before redelivery, or not redeliver the same message instance

[Tim Fox (JIRA)]

     [ http://jira.jboss.com/jira/browse/JBMESSAGING-1079?page=all ]

Tim Fox reassigned JBMESSAGING-1079:
------------------------------------

    Assignee: Tim Fox  (was: Clebert Suconic)

> JBM should call BytesMessage.reset() before redelivery, or not redeliver the same message instance
> --------------------------------------------------------------------------------------------------
>
>                 Key: JBMESSAGING-1079
>                 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-1079
>             Project: JBoss Messaging
>          Issue Type: Bug
>          Components: Messaging Core
>    Affects Versions: 1.4.0 CR3
>         Environment: $ java -version
> java version "1.5.0_12"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
> Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)
> The unit tests have been run using the postgresql provider with PostgreSQL 8.1.4.
>            Reporter: Julian Scheid
>         Assigned To: Tim Fox
>            Priority: Minor
>             Fix For: 1.4.0.SP1
>
>         Attachments: RedeliveryResetTest.java
>
>
> Consider the following sequence of events:
> - a durable subscriber subscribes to a topic with client acknowledgment
> - a BytesMessage is sent to that topic
> - the durable subscriber receives the message and reads its contents completely using BytesMessage.readBytes(byte[])
> - the connection is closed without the subscriber acknowledging the message
> - the subscriber re-subscribes and re-receives the message
> - the subscriber re-reads the contents of the message using BytesMessage.readBytes(byte[])
> In this situation, the second call to readBytes will not return any data (it will return -1 to indicate EOF and no data will be copied to the byte array passed in), unless the message is explicitly reset() by the client first.
> This can be verified by the unit test that I am going to attach.
> The JMS 1.1 specification isn't entirely clear on whether the provider is required to reset a message in this situation.
> However, the spec says in section 3.10, "Changing the Value of a Received Message"
> "If the consumer modifies a received message, and the message is subsequently redelivered, the redelivered message must be the original, unmodified message [...]"
> Here, I would interpret changing the BytesMessage's internal stream pointer as a side-effect of reading its data to be a modification.
> Furthermore, the API docs for javax.jms.BytesMessage say
> "The same message object can be sent multiple times. When a message has been received, the provider has called reset so that the message body is in read-only mode for the client."
> (see http://java.sun.com/j2ee/sdk_1.3/techdocs/api/javax/jms/BytesMessage.html#reset() )
> This also sounds to me like a client could expect that the reset() method has been called when receiving it, regardless of whether it has been received before.
> Even if I am misreading the spec and it is not the provider's responsibility to reset the message in the interim, there are clients out there (e.g. StompConnect - see my corresponding ticket at http://jira.codehaus.org/browse/STOMP-5 ) that do expect this behavior, and so in the spirit of the Robustness Principle ("Be conservative in what you do; be liberal in what you accept from others") I would suggest to implement this behavior regardless.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira