[ http://jira.jboss.com/jira/browse/JBMESSAGING-1079?page=all ] Julian Scheid updated JBMESSAGING-1079: --------------------------------------- Attachment: RedeliveryResetTest.java Test case demonstrating JBMESSAGING-1079. This should go into tests/src/org/jboss/test/messaging/jms/ -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1079?page=all ] Julian Scheid updated JBMESSAGING-1079: --------------------------------------- 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. was: $ 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 Description: 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... ) 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. was: 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.9, "Access to Sent Messages": "After sending a message, a client may retain and modify it without affecting the message that has been sent. The same message object may be sent multiple times. " 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... ) 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. Replaced wrong reference to JMS spec section 3.9 (modification of messages sent by the client) by reference to section 3.10 (modification of messages received by the client). Fixed PostgreSQL version in environment description. -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1079?page=all ] Clebert Suconic closed JBMESSAGING-1079. ---------------------------------------- Resolution: Done -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1079?page=all ] Tim Fox reassigned JBMESSAGING-1079: ------------------------------------ Assignee: Tim Fox (was: Clebert Suconic) -- 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

[ http://jira.jboss.com/jira/browse/JBMESSAGING-1079?page=all ] Tim Fox closed JBMESSAGING-1079. -------------------------------- Resolution: Done -- 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