Maybe I'm oversimplifying this, but isn't the client required to use a
unique client ID, and we're splitting hairs over the exact undefined
behavior that occurs when something invalid is done? It seems like the real
solution is to modify the client applications to make them use unique
client IDs,
The address names don't match. You define the address like so:
But your divert is using:
sf000144_debug.dbg
As you can see "sf000144_debug" is not the same as "sf000144_debug.dbg".
Can you change your configuration so these match?
Justin
On Fri, Jul 23, 2021 at 3:34 PM Edson Richter
Right, I forgot to put in the provided example – follow with complete address
declarations:
true
true
true
<-- divert rule -->
sf000144_debug
my-portal
sf000144_debug.dbg
false
Enviado do
Where is the address "sf000144_debug.dbg" defined? I don't see it in your
block.
Justin
On Fri, Jul 23, 2021 at 3:18 PM Edson Richter
wrote:
> Hi!
>
> I’ve been trying to “divert” messages for my team debugging purposes.
>
> What I have done so far:
>
>
>
>
> true
> true
>
>
>
> <--
Hi!
I’ve been trying to “divert” messages for my team debugging purposes.
What I have done so far:
true
true
<-- divert rule -->
sf000144_debug
my-portal
sf000144_debug.dbg
false
What I did I expect: “all messages sent to
Hello,
I have couple of questions about certs in broker keystore and which cert is
used
in ssl protocol.
I could not find any info in the doc. I did find couple of old queries in
this forum. But,
there are no replies. So, hoping someone can comment on these questions:
1. If there are multiple
Hi David,
it could be a timing issue, when a first client connects to a broker, it
sends a notification to other brokers of the cluster. So if a second client
with the same clienID connects to another broker of the cluster before it
receive the notification, the second broker accepts the
Hi Domenico,
OK thanks I'll have a look at that.
Was considering writing a plugin to block authorisation when the same
client ID is already connected elsewhere on the cluster, with leader
election via a multicast queue.
I'm puzzled why it's behaving this way though. It's not consistent. Usually
Hi Dave,
I'm working on a new ActiveMQ Artemis feature that allows users to
balance incoming client connections according to their ClientID (or other
connection parameters), see the draft documentation[2] for further details.
[2]
Hi all,
Puzzled by some behaviour we're seeing on a broker cluster of 3 live
Artemis v2.16.0 brokers hosted on k8s which has an F5 in front of it
terminating TLS and routing to a k8s node port forwarding to an AMQP
acceptor for each broker. The cluster is healthy and has been up for about
2
10 matches
Mail list logo