@David please reach to me/us if you hit any issues on the new
functionality.
On Thu, Mar 11, 2021 at 5:12 PM David Martin wrote:
> Many thanks for the advice Clebert.
>
> I've just had to deal with journal corruption headaches with other
> messaging middleware in the past.
>
> It does seem like
Many thanks for the advice Clebert.
I've just had to deal with journal corruption headaches with other
messaging middleware in the past.
It does seem like an edge case for Artemis and with mirroring now available
I'll prioritise the DR solution. AMQP is already the protocol used
throughout.
Dav
If you are that concerned with losing the journal (which I believe it
would be pretty hard to happen),I would recommend you using the
Mirror.
Note: The Mirror is sending the message as AMQP. so if you send Core,
the message will be converted as AMQP through the wire. (AMQP
Connection).
I have bee
The journal getting corrupted could happen in 2 situations:
- the file system is damaged by the infra structure. (Hardware failures,
kernel issues ... etc)
* if you have a reliable file system here. I’m not sure how concerned you
should be.
- some invalid data in the journal making the broker
Sorry, just to add. I could create a kubernetes service for publishers with
affinity to 2 of 4 brokers and another service for consumers with affinity
to the other 2 but looking for something more dynamic if possible, to be
able to scale out seamlessly.
On Thu, 11 Mar 2021 at 13:52, David Martin
Hi,
Looking to host an Artemis cluster in Kubernetes and am not sure how to
achieve full local resilience. (Clusters for DR and remote distribution
will be added later using the mirroring feature introduced with v2.16).
It is configured as 3 active cluster members using static discovery because
