You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org> on 2007/02/09 17:32:05 UTC
[jira] Updated: (QPID-348) Problems related to prefetching of
messages
[ https://issues.apache.org/jira/browse/QPID-348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-348:
--------------------------------
Description:
The problem is that messages are be prefetched (push) so when a rollback/recover is called this cache must be cleared or the messages will arrive out of order.
We have to invalidate all the messages that have been sent to the client as we do not know which messages have been processed. TxRollback and Basic.Recover do not provide facilities to send this information. Perhaps an improvement would be to do this analysis and send back the last message id sent to the consumer so we can leave the cache intact.
In our Java implementation this cache is a the "pre-receive Queue" we also have a _synchronousQueue that is used to store messages that have been dispatched but not yet consumed by the consumer when they are using receive() rather than a message listener.
Both of these queues need to be purged to ensure that only have one copy of each message sent to the client.
was:Details tbc
> Problems related to prefetching of messages
> -------------------------------------------
>
> Key: QPID-348
> URL: https://issues.apache.org/jira/browse/QPID-348
> Project: Qpid
> Issue Type: Bug
> Components: Java Client
> Reporter: Marnie McCormack
> Assigned To: Martin Ritchie
>
> The problem is that messages are be prefetched (push) so when a rollback/recover is called this cache must be cleared or the messages will arrive out of order.
> We have to invalidate all the messages that have been sent to the client as we do not know which messages have been processed. TxRollback and Basic.Recover do not provide facilities to send this information. Perhaps an improvement would be to do this analysis and send back the last message id sent to the consumer so we can leave the cache intact.
> In our Java implementation this cache is a the "pre-receive Queue" we also have a _synchronousQueue that is used to store messages that have been dispatched but not yet consumed by the consumer when they are using receive() rather than a message listener.
> Both of these queues need to be purged to ensure that only have one copy of each message sent to the client.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.