You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Rupert Smith (JIRA)" <qp...@incubator.apache.org> on 2006/12/20 13:52:21 UTC
[jira] Created: (QPID-223) TopicConnTests#connNotStartedTopicTest
failing.
TopicConnTests#connNotStartedTopicTest failing.
-----------------------------------------------
Key: QPID-223
URL: http://issues.apache.org/jira/browse/QPID-223
Project: Qpid
Issue Type: Bug
Components: JMS Compliance
Reporter: Rupert Smith
TopicConnTests#connNotStartedTopicTest is failing.
This is due to the fact that this test resends the same TextMessage many times but the reset method on AbstractJMSMessage was performing a flip() on the buffer rather a rewind() between each message send. This was caused by the logic that decides whether to perform a flip or rewind being driven by the _isReadable flag when really the choice should be made depending on whether or not the buffer has 'just been written to' as opposed to 'just read'. A new flag to distinguish these two conditions, _changedData, has been introduced into AbstractJMSMessage and all methods in its derived child classes set this flag whenever they have just written to the buffer, so that the next reset and subsequent resets work correctly.
The _changedData flag is initially set to true if an AbstractJMSMessage is created with no data, so that reset works correctly on null messages. When AbstractJMSMessage is created with data, the buffer passed to it has already been flipped, so _changedData is set to false.
A patch to fix this is included.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (QPID-223) Sending the same message multiple times
results in a MessageNotWriteable exception
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/QPID-223?page=all ]
Martin Ritchie closed QPID-223.
-------------------------------
Resolution: Fixed
Completed: At revision: 489070
> Sending the same message multiple times results in a MessageNotWriteable exception
> ----------------------------------------------------------------------------------
>
> Key: QPID-223
> URL: http://issues.apache.org/jira/browse/QPID-223
> Project: Qpid
> Issue Type: Bug
> Components: JMS Compliance
> Reporter: Rupert Smith
> Assigned To: Martin Ritchie
> Attachments: QPID-22X.txt
>
>
> Sending the same message multiple times results in a MessageNotWriteable exception
> This is due to the fact that this test resends the same TextMessage many times but the reset method on AbstractJMSMessage was performing a flip() on the buffer rather a rewind() between each message send. This was caused by the logic that decides whether to perform a flip or rewind being driven by the _isReadable flag when really the choice should be made depending on whether or not the buffer has 'just been written to' as opposed to 'just read'. A new flag to distinguish these two conditions, _changedData, has been introduced into AbstractJMSMessage and all methods in its derived child classes set this flag whenever they have just written to the buffer, so that the next reset and subsequent resets work correctly.
> The _changedData flag is initially set to true if an AbstractJMSMessage is created with no data, so that reset works correctly on null messages. When AbstractJMSMessage is created with data, the buffer passed to it has already been flipped, so _changedData is set to false.
> A patch to fix this is included.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (QPID-223) Sending the same message multiple times
results in a MessageNotWriteable exception
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/QPID-223?page=all ]
Martin Ritchie updated QPID-223:
--------------------------------
Summary: Sending the same message multiple times results in a MessageNotWriteable exception (was: TopicConnTests#connNotStartedTopicTest failing.)
Description:
Sending the same message multiple times results in a MessageNotWriteable exception
This is due to the fact that this test resends the same TextMessage many times but the reset method on AbstractJMSMessage was performing a flip() on the buffer rather a rewind() between each message send. This was caused by the logic that decides whether to perform a flip or rewind being driven by the _isReadable flag when really the choice should be made depending on whether or not the buffer has 'just been written to' as opposed to 'just read'. A new flag to distinguish these two conditions, _changedData, has been introduced into AbstractJMSMessage and all methods in its derived child classes set this flag whenever they have just written to the buffer, so that the next reset and subsequent resets work correctly.
The _changedData flag is initially set to true if an AbstractJMSMessage is created with no data, so that reset works correctly on null messages. When AbstractJMSMessage is created with data, the buffer passed to it has already been flipped, so _changedData is set to false.
A patch to fix this is included.
was:
TopicConnTests#connNotStartedTopicTest is failing.
This is due to the fact that this test resends the same TextMessage many times but the reset method on AbstractJMSMessage was performing a flip() on the buffer rather a rewind() between each message send. This was caused by the logic that decides whether to perform a flip or rewind being driven by the _isReadable flag when really the choice should be made depending on whether or not the buffer has 'just been written to' as opposed to 'just read'. A new flag to distinguish these two conditions, _changedData, has been introduced into AbstractJMSMessage and all methods in its derived child classes set this flag whenever they have just written to the buffer, so that the next reset and subsequent resets work correctly.
The _changedData flag is initially set to true if an AbstractJMSMessage is created with no data, so that reset works correctly on null messages. When AbstractJMSMessage is created with data, the buffer passed to it has already been flipped, so _changedData is set to false.
A patch to fix this is included.
Assignee: Martin Ritchie
> Sending the same message multiple times results in a MessageNotWriteable exception
> ----------------------------------------------------------------------------------
>
> Key: QPID-223
> URL: http://issues.apache.org/jira/browse/QPID-223
> Project: Qpid
> Issue Type: Bug
> Components: JMS Compliance
> Reporter: Rupert Smith
> Assigned To: Martin Ritchie
> Attachments: QPID-22X.txt
>
>
> Sending the same message multiple times results in a MessageNotWriteable exception
> This is due to the fact that this test resends the same TextMessage many times but the reset method on AbstractJMSMessage was performing a flip() on the buffer rather a rewind() between each message send. This was caused by the logic that decides whether to perform a flip or rewind being driven by the _isReadable flag when really the choice should be made depending on whether or not the buffer has 'just been written to' as opposed to 'just read'. A new flag to distinguish these two conditions, _changedData, has been introduced into AbstractJMSMessage and all methods in its derived child classes set this flag whenever they have just written to the buffer, so that the next reset and subsequent resets work correctly.
> The _changedData flag is initially set to true if an AbstractJMSMessage is created with no data, so that reset works correctly on null messages. When AbstractJMSMessage is created with data, the buffer passed to it has already been flipped, so _changedData is set to false.
> A patch to fix this is included.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (QPID-223) TopicConnTests#connNotStartedTopicTest
failing.
Posted by "Rupert Smith (JIRA)" <qp...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/QPID-223?page=all ]
Rupert Smith updated QPID-223:
------------------------------
Attachment: QPID-22X.txt
Patch fix for QPID-223
> TopicConnTests#connNotStartedTopicTest failing.
> -----------------------------------------------
>
> Key: QPID-223
> URL: http://issues.apache.org/jira/browse/QPID-223
> Project: Qpid
> Issue Type: Bug
> Components: JMS Compliance
> Reporter: Rupert Smith
> Attachments: QPID-22X.txt
>
>
> TopicConnTests#connNotStartedTopicTest is failing.
> This is due to the fact that this test resends the same TextMessage many times but the reset method on AbstractJMSMessage was performing a flip() on the buffer rather a rewind() between each message send. This was caused by the logic that decides whether to perform a flip or rewind being driven by the _isReadable flag when really the choice should be made depending on whether or not the buffer has 'just been written to' as opposed to 'just read'. A new flag to distinguish these two conditions, _changedData, has been introduced into AbstractJMSMessage and all methods in its derived child classes set this flag whenever they have just written to the buffer, so that the next reset and subsequent resets work correctly.
> The _changedData flag is initially set to true if an AbstractJMSMessage is created with no data, so that reset works correctly on null messages. When AbstractJMSMessage is created with data, the buffer passed to it has already been flipped, so _changedData is set to false.
> A patch to fix this is included.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira