[
https://issues.apache.org/jira/browse/AMQ-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15066388#comment-15066388
]
Christopher L. Shannon commented on AMQ-6099:
---------------------------------------------
If a user upgrades to a new version of ActiveMQ, KahaDB will detect the older
OpenWire version and fall back. In case the index needs to be rebuilt, the
{{storeOpenWireVersion}} property on the BrokerService can be set so that the
existing version is always used, so this is the safest thing to do.
Supporting multiple versions at one time could be tricky as you could get into
a situation where you have more than 2...maybe 3 or 4 types written at the same
time if multiple upgrades were done.
In my opinion, the best solution is the one you mentioned last. There has been
talk on the dev list about creating a new sub project for store utilities and
one of the features would be the ability to upgrade KahaDB to a new OpenWire
version.
> Allow broker to read any OpenWire version from KahaDB
> -----------------------------------------------------
>
> 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 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.
> Alternatively, we could create a command-line utility to transform a set of
> KahaDB data files from an (offline) broker from one version to another.
> That's a little clunkier for the user, but reasonable if it's substantially
> easier to implement.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
