+1, it never really made a whole lot of sense to me to have a backup in the
same JVM when a new JVM can be spun up easily and is much easier to
support.  Also many different errors that might cause a failover to be
needed would affect the JVM such as OOM, etc.

On Mon, Feb 10, 2020 at 2:14 PM Justin Bertram <jbert...@apache.org> wrote:

> Artemis currently has the ability to configure both a live and a backup
> server in the same JVM. This is referred to as "colocated" brokers.
>
> The original use-case for this functionality was very early cloud
> infrastructure where durable, attached storage was not readily available.
> However, since the development of this feature most (if not all) cloud
> environments support durable storage separate from the broker so that if
> the broker goes down a new, identical broker can be spun-up quickly and
> attached to the same storage. This provides high availability without the
> need for any idle backups or replication of any kind which functionally
> nullifies this feature.
>
> Aside from this, it turns out that (surprise!) configuring & running
> multiple brokers in the same JVM is difficult and error-prone not to
> mention dynamically coordinating the acquisition of backups in a running
> cluster and protecting against split-brain. I was able to quickly search
> and find 5 open Jiras for colocated issues (of course, there may be more):
>
>   ARTEMIS-452 - Scale down with colocated backup failing when using
> replication
>   ARTEMIS-2165 - Not having backup available after restart in colocated
> configuration
>   ARTEMIS-2609 - Ha-policy collocated not working.
>   ARTEMIS-2452 - group-name ignored in shared store colocated setup
>   ARTEMIS-1863 - Colocated Replicating Cluster Ends Up in an Infinite
> Quorum Vote Loop After Failover and Restart
>
> At this point I recommend that we deprecate this feature and steer users
> who want this kind of functionality to either existing cloud infrastructure
> options or multiple, distinct brokers on the same hardware (i.e. outside
> the cloud).
>
> What are your thoughts?
>
>
> Justin
>

Reply via email to