upgrading hornetq over time

[drkirwin]

Folks--

What's the standard procedure for upgrading HornetQ over time?

For instance, if our team wants to move from HornetQ 2.0.0 to 2.1.0, what would we need to do?

Do we need to replace the 2.0.0 client jars with 2.1.0 client jars, no matter what?

Do we need to rm -rf ./data before starting up a new one?

Make sure that all messages have been consumed before upgrading?

I'd be happy for a reference to a doc somewhere. Haven't found anything.

Keith

[timfox]

To be safe when upgrading community versions you need to do a clean install each time - i.e. follow the instructions in the quick start guide for installation.

[leosbitto]

Tim Fox wrote:

To be safe when upgrading community versions you need to do a clean install each time - i.e. follow the instructions in the quick start guide for installation.

Following the manual is obviously the only acceptable solution. Are you going to describe there how to migrate the persistent data (messages, XA transactions, etc.) stored by the previous version?

[timfox]

At some point we're probably going to write a migration tool for the data.

But, in general, we make no compatibility guarantees between any community version and another.

This differs from the product version that you pay for (in EAP) where you get compatibility guarantees. I.e. it's a value add that you pay for.

If you use the community version, it's free, you get quick updates and fixes but in general you'll have to do more work for yourselves.

[leosbitto]

Tim Fox wrote:

At some point we're probably going to write a migration tool for the data.

But, in general, we make no compatibility guarantees between any community version and another.

This differs from the product version that you pay for (in EAP) where you get compatibility guarantees. I.e. it's a value add that you pay for.

If you use the community version, it's free, you get quick updates and fixes but in general you'll have to do more work for yourselves.

That all makes sense, thanks for clarification. My employer actually pays for EAP subscription, so I am looking forward to see what is going to happen in EAP regarding HornetQ. Currently we use other commercial JMS vendor, which has various shortcomings, but the upgrade (even between major releases) is flawless - at the server side the persistent store gets upgraded with the first start of the new version, at the client side no changes are needed (each new server release is able to handle older clients, too!). They do even document how to upgrade clustered servers with zero downtime for the clients - I was not brave enough to try that yet, though...