[
https://issues.apache.org/jira/browse/AMQ-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tim Bain updated AMQ-6099:
--------------------------
Description:
The current persistence store implementation only allows a single OpenWire
version to be read from the store. This works fine during normal operations,
but when a user upgrades to a version of ActiveMQ that uses a different
OpenWire version, the new broker is unable to read any persisted messages from
the store because of the version mismatch, as described in AMQ-5995.
Broker upgrades are going to happen, and the requirement that they be done with
an empty message store, or that the user apply temporary workarounds like
running the old broker in a networked configuration that's not the standard
config for the cluster, leads to a less-than-satisfactory experience during the
upgrade. As much as possible, broker upgrades should be seamless; sometimes
that's not possible, but in this case it seems like code that would be able to
read any version of OpenWire but only write the current one (and that could be
less-efficient with older versions if necessary) wouldn't be all that hard and
would eliminate this problem.
I expect that the choice of persistence store technology wouldn't affect the
implementation of this feature, and that if you implement it you'd be able to
use it for all persistence store types.
was:
The current KahaDB implementation only allows a single OpenWire version to be
read from the store. This works fine during normal operations, but when a user
upgrades to a version of ActiveMQ that uses a different OpenWire version, the
new broker is unable to read any persisted messages from the store because of
the version mismatch, as described in AMQ-5995.
Broker upgrades are going to happen, and the requirement that they be done with
an empty message store, or that the user apply temporary workarounds like
running the old broker in a networked configuration that's not the standard
config for the cluster, leads to a less-than-satisfactory experience during the
upgrade. As much as possible, broker upgrades should be seamless; sometimes
that's not possible, but in this case it seems like code that would be able to
read any version of OpenWire but only write the current one (and that could be
less-efficient with older versions if necessary) wouldn't be all that hard and
would eliminate this problem.
Summary: Allow broker to read any OpenWire version from a persistence
store (was: Allow broker to read any OpenWire version from KahaDB)
> Allow broker to read any OpenWire version from a persistence store
> ------------------------------------------------------------------
>
> Key: AMQ-6099
> URL: https://issues.apache.org/jira/browse/AMQ-6099
> Project: ActiveMQ
> Issue Type: New Feature
> Components: KahaDB
> Affects Versions: 5.x
> Reporter: Tim Bain
>
> The current persistence store implementation only allows a single OpenWire
> version to be read from the store. This works fine during normal operations,
> but when a user upgrades to a version of ActiveMQ that uses a different
> OpenWire version, the new broker is unable to read any persisted messages
> from the store because of the version mismatch, as described in AMQ-5995.
> Broker upgrades are going to happen, and the requirement that they be done
> with an empty message store, or that the user apply temporary workarounds
> like running the old broker in a networked configuration that's not the
> standard config for the cluster, leads to a less-than-satisfactory experience
> during the upgrade. As much as possible, broker upgrades should be seamless;
> sometimes that's not possible, but in this case it seems like code that would
> be able to read any version of OpenWire but only write the current one (and
> that could be less-efficient with older versions if necessary) wouldn't be
> all that hard and would eliminate this problem.
> I expect that the choice of persistence store technology wouldn't affect the
> implementation of this feature, and that if you implement it you'd be able to
> use it for all persistence store types.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
