On Thu, Mar 12, 2015 at 9:26 PM, Tim Bain wrote:
> This doesn't really work for topics; you need to get the new messages to
> collect on b2 while the old consumer drains b1, and only then have the old
> consumer disconnect and reconnect on b2; you can't have the consumer
> simultaneously connecte
This doesn't really work for topics; you need to get the new messages to
collect on b2 while the old consumer drains b1, and only then have the old
consumer disconnect and reconnect on b2; you can't have the consumer
simultaneously connected to both b1 and b2. (Obviously this is only for
durable s
On Thu, Mar 12, 2015 at 8:58 AM, Tim Bain wrote:
> And there would need to be a change
> to allow a non-durable subscriber to disconnect from the old broker without
> unsubscribing the consumer and to resume that subscription once the
> connection is made to the new broker (and obviously this wou
messages is not critical since otherwise the application
> is going to have major problems (due to message loss) when there are
> hiccups
> in the network.
>
>
>
> --
> View this message in context:
> http://activemq.2283324.n4.nabble.com/Data-Migration-from-KahaDB-to-LevelDB-tp4692615p4693034.html
> Sent from the ActiveMQ - User mailing list archive at Nabble.com.
>
since otherwise the application
is going to have major problems (due to message loss) when there are hiccups
in the network.
--
View this message in context:
http://activemq.2283324.n4.nabble.com/Data-Migration-from-KahaDB-to-LevelDB-tp4692615p4693034.html
Sent from the ActiveMQ - User mailing
Import/export of the stores still won't roll a non-durable topic
subscription from the old to the new broker, which means that when the
consumer disconnects from the old broker it will lose all unconsumed
messages as well as any messages produced between when it disconnects from
the old broker and
note - as part of apollo - there was some tooling around export/import
of message stores.
apollo does import and 5.x does export [1].
I guess it would not be much work to provide a 5.x import tool.
Scheduler store is still an outlier though.
[1]
https://github.com/apache/activemq/blob/5667e4ddcc4
View this message in context:
http://activemq.2283324.n4.nabble.com/Data-Migration-from-KahaDB-to-LevelDB-tp4692615p4692838.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
This solution works in certain situations, but there's currently no way to
cleanly migrate consumers to the new broker in all situations. Scheduled
messages and non-durable topic subscriptions are two examples of cases
where simply standing up a new broker and having all clients move to it
isn't r
On 03/09/2015 11:54 AM, James A. Robinson wrote:
On Fri, Mar 6, 2015 at 6:07 AM, underflow wrote:
- Another idea was to create a network of brokers with the original instance
(w/ kahadb persistence) and the new instance (w/ leveldb persistence) +
resending all content, if required...
I'll be c
On Fri, Mar 6, 2015 at 6:07 AM, underflow wrote:
> - Another idea was to create a network of brokers with the original instance
> (w/ kahadb persistence) and the new instance (w/ leveldb persistence) +
> resending all content, if required...
I'll be curious to see what advice you get. I'm new to
-from-KahaDB-to-LevelDB-tp4692615.html
Sent from the ActiveMQ - User mailing list archive at Nabble.com.
12 matches
Mail list logo
