On 2017-11-15 07:59, Justin Bertram wrote:
> Ultimately I believe the decision is in the hands of the ActiveMQ PMC [1].
The question you asked is a good one and something that the PMC should clarify
for the user community, especially given the confusion amongst the
> Is there any possibility to define a separate connector (server or client
side, does not matter in our use case) used for XA Recovery?
I don't think so, but it's been awhile since I looked at that bit of code
in HornetQ.
I think you could disable recovery by setting
false
on the
The client receives the properties of the cluster connection configured on
the serverside. Is there any possibility to define a separate connector
(server or client side, does not matter in our use case) used for XA
Recovery?
Deployment and configuration of the Artemis RA on every client is the
I'd try using the Artemis JCA RA. You can build it using the
/examples/features/sub-modules/artemis-ra-rar example shipped
with the broker.
Justin
On Fri, Nov 17, 2017 at 9:14 AM, Benjamin Buehlmann <
benjamin.buehlm...@gmail.com> wrote:
> I configured a ActiveMQ Artemis 2.4.0 HA setup with
I configured a ActiveMQ Artemis 2.4.0 HA setup with replication and a static
cluster connection of the two nodes (live- and backup node). As one of the
test clients I use a JBoss EAP 6.3.2 with embedded HornetQ.
Every two minutes a see a Warning in the clients log that some keys are not
know by
It is interesting... the entire index is in memory, and I noticed a jmx
operation that will swap the priority of a message, it just means moving it
between priority lists in the in memory index[1].
Ordering would be more expensive by far, but by replacing the priority
lists with some sort of
I also got these messages when I had a network connector setup. The setup
seems similar to OP, where we had a message configured to be sent via a
staticallyIncludedDestinations block, and it ended up in the DLQ with
"TopicSubDiscard". Here's a full dump of one of the messages that ended up
in the