[
https://issues.apache.org/jira/browse/AMQ-6099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15067549#comment-15067549
]
Christopher L. Shannon commented on AMQ-6099:
---------------------------------------------
The main problem would be finding a good way to efficiently track which
OpenWire marshallers to use for each message. Right now the index just tracks
in one field the version used for the entire store, and if the index is corrupt
then it uses the default. But in this case since you wouldn't know ahead of
time which OpenWire versions were used or how many messages were using
different versions, you'd probably need to track the OpenWire version used for
every command written to the journal. You'd need to know which marshaller to
use before reading each message as there wouldn't be any guarantee ahead of
time which message used which marshaller.
The OpenWire version info could probably be tracked in the index for each
message but if the index were to get corrupted then there would be no current
way to know which OpenWire marshaller to use to recovery each message.
I'm sure these issues could be worked out and it could be supported, but it
would take some time to figure out a good way to do it. Another big thing
would be to make sure anything done here would not add a significant
performance penalty as well.
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
