Hi
I have never used consumer priorities, but the amq-website says about it
*** Once a particular consumer has its prefetch buffer filled up, the
broker will begin to dispatch messages to consumers of lower priorities. ***
So, the behaviour you describe seems to be ok to me. When the high prio
co
Hi
We prefix all destination names with an environment shortcut, e.g.
test.mycomponent.process, prod.mycomponent.process etc.
To configure special destination demands, I tried to create an environment
agnostic configuration I can distribute on all broker machines like this:
BUT that doesn't wo
Hi Tim
First of all: your suggestions to improve the failover sound great to me.
Thanks a lot for your effort in this field.
I also highly welcome James' answer that the failover implementation must
come along with NFS settings recommendations that work good with the
implementation.
There are so
AMQ works just
perfect, but it can only work if it is able to recognize the failure
situation.
Stephan
On Fri, Jun 12, 2015 at 11:47 PM, Tim Bain wrote:
> Stephan, can you describe which NFS settings resulted in which behavior?
> On Jun 12, 2015 8:34 AM, "Stephan Burkard"
Anuj
Have a look at https://issues.apache.org/jira/browse/AMQ-5549
You cannot avoid to have either two or zero master-brokers online during a
failover. The question is how long this situation lasts (see Arthur
Naseef's comment on AMQ-5549).
In my failover-tests with NFS shared storage I was able
Your case reminds me of ticket AMQ-5266. The ticket says the issue is fixed
with 5.11.0, so you should be fine, but perhaps it is a similar issue.
Stephan
On Wed, Feb 18, 2015 at 5:08 AM, artnaseef wrote:
> Duplicate messages are an unfortunate possibility for any JMS solution,
> hence
> the J
Hi
I would like to know what the expected state after a successful
master/slave failover is. The AMQ website seems to be inconsistent or at
least not very accurate in this topic.
The general master/slave page with the different flavours listed, says for
all types "Automatic recovery of old maste