> I'm not clear on the role which the proxies would play. Can you clarify that?
I believe today it is doable in a network of brokers fashion doing store and forward. If I store then I'd need backups and the point is lost. I was wondering if such a thing as a store-and-forward minus the store part (hence the no queues) was possible at all, but I am conscious it's a bit of a stretch request. > In general, if you had a broker with no queues then any client trying to > send message to that broker would fail. Neither the connections nor the > messages would somehow pass through that broker to another broker. I see, I'll probably have to think about something custom at the network layer instead of the k8s constructions, haproxy or similar. Or perhaps I should stick to AMQP only and use the qpid proton dispatcher. Thanks 2018-06-27 11:14 GMT-07:00 Justin Bertram <jbert...@apache.org>: > I'm not clear on the role which the proxies would play. Can you clarify > that? > > In general, if you had a broker with no queues then any client trying to > send message to that broker would fail. Neither the connections nor the > messages would somehow pass through that broker to another broker. > > > Justin > > On Tue, Jun 26, 2018 at 11:25 PM, Victor <victor.rom...@gmail.com> wrote: > > > I'm still playing with different topologies of ActiveMQ Artemis in > > Kubernetes. An almost satisfactory one (also playing with colocated but > > anti-affinity is difficult there) is to have master and slaves paired in > > two stateful sets: > > > > +-----------------------+ > > | | > > | | > > | | > > +-------+--------+ +--------+-------+ > > |artemis master 1| |artemis master 2| > > +----------------+ +--------+ ------+ > > |group-name=artemis-1 | > > | | > > v group-name=artemis-2| > > +-------+--------+ +------> --------+ > > |artemis slave 1 | |artemis slave 2 | > > +----------------+ +----------------+ > > > > Note that this configuration also has inter-pod anti-affinity > > <https://kubernetes.io/docs/concepts/configuration/assign-pod-node/> > > between master and slaves do they don't end up working on the same > physical > > node. Also, there is a disruption budget > > <https://kubernetes.io/docs/concepts/workloads/pods/disruptions/> of > just > > one and only one master or slave could be down at the same time without > > involving data loss. > > > > This could be acceptable as version 1, as it might be useful for many > > users. However, I found a little thing that is usually fine but seems to > be > > bothersome for Kubernetes. Slaves do not open ports nor serve traffic > while > > they are just being slaves. Kubernetes have one special nuance in terms > of > > load balancing, the load balancer does not check for the pods to be > > healthy. Its Kubernetes itself doing two checks, liveness (should I > restart > > you?) and readiness (are you ready?). the readiness mean both I'm started > > and also I'm ready to receive traffic. Given that slaves do not open > ports > > they won't typically be ready (if they where the load balancer would > route > > to them and those request would fail). And thus, the helm chart present > > weird behaviors like for instance the following: > > > > helm install activemq-artemis --wait > > > > Will timeout, as --wait will try to wait for every pod to be in ready > > state. Unless I go for much more sophisticated balancing solutions this > is > > mostly unavoidable and undesirable. > > > > One possible solution I have contemplated might be perhaps a bit too > > creative and I'd preferred to run it here before executing. What If I set > > up a cluster of Artemis with no persistence, no local queues and just > core > > connections to the real servers: > > > > > > +-----load balancer----+ > > | | > > | | > > | | > > | | > > +--proxy 1--+ +---proxy 2--+ > > | | | | > > | | | | > > | | | | > > | | | | > > | | | | > > master 1 slave 1 master 2 slave 2 > > > > > > With my limited understanding, I believe those mostly stateless Artemis > > would act as a proxy just as I wanted to wrap the needs of Kubernetes > into > > a proxy with no need of new code. > > > > Is this assumption right? Would there be a risk of data loss? I assume > > there would be unless I activate persistence, would there be a > work-around > > for this? > > > > Thanks! > > >
