activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tim Bain (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMQ-6099) Allow broker to read any OpenWire version from KahaDB
Date Tue, 22 Dec 2015 04:16:46 GMT

     [ 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 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.

  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.

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.


I split out the suggestion for a utility to migrate KahaDB data files to a different OpenWire
version into a stand-alone issue (AMQ-6103), to allow each JIRA entry be focused on only one
feature and evaluated on its own merits.

> 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)

Mime
View raw message