You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org> on 2007/01/30 14:50:33 UTC
[jira] Created: (QPID-329) Provide message replay functionality
Provide message replay functionality
------------------------------------
Key: QPID-329
URL: https://issues.apache.org/jira/browse/QPID-329
Project: Qpid
Issue Type: New Feature
Components: C++ Broker, Java Broker
Affects Versions: M1
Reporter: Marnie McCormack
Priority: Minor
A common recovery scenario is requesting replay on a queue from a given,
known message, either by its ID or by something in the header. Its saves all
that mucking about with XA and makes recovery the normal way of system
startup rather then some exceptional case.
This means when a message has reached all its recipients it should never be
marked for removal from the durable message store.
As a user, I would also like to control when messages get removed as part of
my end of day or even weekly processs, probably based on header property
selectors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-329) Provide message replay functionality
Posted by "Gordon Sim (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Gordon Sim updated QPID-329:
----------------------------
Fix Version/s: (was: M3)
> Provide message replay functionality
> ------------------------------------
>
> Key: QPID-329
> URL: https://issues.apache.org/jira/browse/QPID-329
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Broker, Java Broker
> Affects Versions: M1
> Reporter: Marnie McCormack
> Priority: Minor
>
> A common recovery scenario is requesting replay on a queue from a given,
> known message, either by its ID or by something in the header. Its saves all
> that mucking about with XA and makes recovery the normal way of system
> startup rather then some exceptional case.
> This means when a message has reached all its recipients it should never be
> marked for removal from the durable message store.
> As a user, I would also like to control when messages get removed as part of
> my end of day or even weekly processs, probably based on header property
> selectors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-329) Provide message replay functionality
Posted by "Martin Ritchie (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Ritchie updated QPID-329:
--------------------------------
Fix Version/s: M3
> Provide message replay functionality
> ------------------------------------
>
> Key: QPID-329
> URL: https://issues.apache.org/jira/browse/QPID-329
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Broker, Java Broker
> Affects Versions: M1
> Reporter: Marnie McCormack
> Priority: Minor
> Fix For: M3
>
>
> A common recovery scenario is requesting replay on a queue from a given,
> known message, either by its ID or by something in the header. Its saves all
> that mucking about with XA and makes recovery the normal way of system
> startup rather then some exceptional case.
> This means when a message has reached all its recipients it should never be
> marked for removal from the durable message store.
> As a user, I would also like to control when messages get removed as part of
> my end of day or even weekly processs, probably based on header property
> selectors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-329) Provide message replay functionality
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-329:
----------------------------------
See Jan 18th Thread 'Message History And Reply' initiated by Colin Christ
> Provide message replay functionality
> ------------------------------------
>
> Key: QPID-329
> URL: https://issues.apache.org/jira/browse/QPID-329
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Broker, Java Broker
> Affects Versions: M1
> Reporter: Marnie McCormack
> Priority: Minor
>
> A common recovery scenario is requesting replay on a queue from a given,
> known message, either by its ID or by something in the header. Its saves all
> that mucking about with XA and makes recovery the normal way of system
> startup rather then some exceptional case.
> This means when a message has reached all its recipients it should never be
> marked for removal from the durable message store.
> As a user, I would also like to control when messages get removed as part of
> my end of day or even weekly processs, probably based on header property
> selectors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (QPID-329) Provide message replay functionality
Posted by "Marnie McCormack (JIRA)" <qp...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/QPID-329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marnie McCormack updated QPID-329:
----------------------------------
Fix Version/s: (was: M4)
Moving items not being worked on afaik out of M4 Fix Version
> Provide message replay functionality
> ------------------------------------
>
> Key: QPID-329
> URL: https://issues.apache.org/jira/browse/QPID-329
> Project: Qpid
> Issue Type: New Feature
> Components: C++ Broker, Java Broker
> Affects Versions: M1
> Reporter: Marnie McCormack
> Priority: Minor
>
> A common recovery scenario is requesting replay on a queue from a given,
> known message, either by its ID or by something in the header. Its saves all
> that mucking about with XA and makes recovery the normal way of system
> startup rather then some exceptional case.
> This means when a message has reached all its recipients it should never be
> marked for removal from the durable message store.
> As a user, I would also like to control when messages get removed as part of
> my end of day or even weekly processs, probably based on header property
> selectors.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.