Marek,
Thanks for the explanation; that helped me to separate the different things
you're seeing.
On Fri, Oct 31, 2014 at 5:21 AM, Marek Dominiak wrote:
> tbain98 wrote
> > I'm not clear on what behavior you're seeing, because the descriptions
> you
> > give (as I understand them) seem contradi
we are working on 5.11, and you can expect subsequent 5.xx releases as more
issues are identified and resolved.
Expect 5.x to become very stable.
On 30 October 2014 17:35, David O'Connor
wrote:
> Hi,
>
> Can I ask what is the current timeplan for ActiveMQ 5?
>
> Will there be continued updates t
In this case static: will do what you want.
On 30 October 2014 16:52, Tim Bain wrote:
> What you're suggesting sounds like it would behave the same as if I use the
> static: transport with two nested URIs, except that I'd have more
> configuration boilerplate since I'd have an additional network
tbain98 wrote
> I'm not clear on what behavior you're seeing, because the descriptions you
> give (as I understand them) seem contradictory. You say that the consumer
> won't abort, but that you've got a 30-minute client-side abort timeout.
> You say that after the intended abort, you know it didn
Hi,
Using ActiveMQ 5.10 and replicated leveldb.
Test Case:
1) Running 3 ActiveMQ brokers with zookeeper and using replicated leveldb
store.
2) Stop one of the slave broker.
3) Delete the levelDB index and other files.
4) Restart the slave broker.
At this time I got this error in the slave br
> Once the master is elected, the slave stores connect
> to elected master store and start receiving journal updates and
> synchronize their data files with the master
I was under the impression that master pushes data to the slaves. but it
looks like slaves pull data from master? Correct me if I