Issue using Last Value Queue in Cluster

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Issue using Last Value Queue in Cluster

ldebello
Hi,

I have two Artemis broker (2.9.0) running creating a cluster using UDP, and
I hit and issue using LVQ in this way. It general works ok but in some
situations it does not.

Use Cases:


1) Working as Expected
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=985,
Queue=State)
Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=940,
Queue=State)

Consume Message to Broker in port 5672: Got 940

2) Working as Expected
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=83,
Queue=State)
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=250,
Queue=State)
Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=46,
Queue=State)

Consume Message to Broker in port 5672: Got 46

3) NOT Working as Expected
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=887,
Queue=State)
Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=660,
Queue=State)

Consume Message to Broker in port 5674: Got 887

4) NOT Working as Expected
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=520,
Queue=State)
Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=690,
Queue=State)
Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=784,
Queue=State)

Consume Message to Broker in port 5674: Got 690

Did you see something similar?

Thanks & Best Regards,
Luis





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Issue using Last Value Queue in Cluster

jbertram
Although the behavior appears incorrect I think it is, in fact, correct.
This is because every node in the cluster maintains its own independent
queues and therefore the last-value on each node will be different.
Furthermore, when messages are redistributed then the last-value can change
because even though the redistributed messages may have been sent before
the messages already in the queue the redistribution process will cause the
last-value to be reassessed.

Due to this I would recommend against using last-value queues in a cluster.


Justin

On Thu, Dec 12, 2019 at 2:58 PM ldebello <[hidden email]> wrote:

> Hi,
>
> I have two Artemis broker (2.9.0) running creating a cluster using UDP, and
> I hit and issue using LVQ in this way. It general works ok but in some
> situations it does not.
>
> Use Cases:
>
>
> 1) Working as Expected
> Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=985,
> Queue=State)
> Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=940,
> Queue=State)
>
> Consume Message to Broker in port 5672: Got 940
>
> 2) Working as Expected
> Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=83,
> Queue=State)
> Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=250,
> Queue=State)
> Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=46,
> Queue=State)
>
> Consume Message to Broker in port 5672: Got 46
>
> 3) NOT Working as Expected
> Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=887,
> Queue=State)
> Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=660,
> Queue=State)
>
> Consume Message to Broker in port 5674: Got 887
>
> 4) NOT Working as Expected
> Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=520,
> Queue=State)
> Sending Message to Broker in port 5672: Message(LVQ_ID="Some", Content=690,
> Queue=State)
> Sending Message to Broker in port 5674: Message(LVQ_ID="Some", Content=784,
> Queue=State)
>
> Consume Message to Broker in port 5674: Got 690
>
> Did you see something similar?
>
> Thanks & Best Regards,
> Luis
>
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue using Last Value Queue in Cluster

ldebello
I got your point, after analyzing the result it seems when connecting to a
different broker is first doing the message aggregation/redistribution and
then providing the message to consumer.

Given the fact clustering is something good to scale out and LVQ is
something like a good feature, I was thinking if would be possible to have
some property for LVQ cases to guarantee global order in cluster mode and
always keeping the "real" last value message. Maybe this property could be
fill up by the producer to allow ordering before replacing last value.

I like the idea of clustering for scalability or could you share which
strategy use for high traffic/volumen?

Thanks & Best Regards,
Luis



--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Issue using Last Value Queue in Cluster

jbertram
I addressed your question about global order on the other thread whose
subject is "Global Order + Cluster + Message Redistribution." In short,
"global order" and "high traffic/volume" are essentially at odds with each
other. If you really want global order then don't cluster. If you want high
volume then ditch global ordering and create a cluster.

That said, a single instance of ActiveMQ Artemis can potentially process
millions of messages per second so you may not even need a cluster to deal
with your volume. Have you benchmarked your application with real-world
data content/volume and concluded that a cluster is necessary to deal with
it? If not, that would be a worthwhile exercise. I've seen lots of users
simply assume that they need to cluster when they really don't which
complicates their architecture and wastes lots of resources.


Justin

On Fri, Dec 13, 2019 at 11:02 AM ldebello <[hidden email]> wrote:

> I got your point, after analyzing the result it seems when connecting to a
> different broker is first doing the message aggregation/redistribution and
> then providing the message to consumer.
>
> Given the fact clustering is something good to scale out and LVQ is
> something like a good feature, I was thinking if would be possible to have
> some property for LVQ cases to guarantee global order in cluster mode and
> always keeping the "real" last value message. Maybe this property could be
> fill up by the producer to allow ordering before replacing last value.
>
> I like the idea of clustering for scalability or could you share which
> strategy use for high traffic/volumen?
>
> Thanks & Best Regards,
> Luis
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Issue using Last Value Queue in Cluster

ldebello
Hi Justin,

I was thinking about your point regarding performance and my concern is not
regarding number of messages is more related to number of connections.

In our model you register to our service and you become a consumer in the
broker so per each registration we will have at least one connection in
production we are supporting this without using a broker and having
websockets but we want to move away from that model

That is the reason why we are trying to use cluster and other features
together





--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Reply | Threaded
Open this post in threaded view
|

Re: Issue using Last Value Queue in Cluster

jbertram
Just to clarify, did you conduct a load test of some kind which indicated a
single broker couldn't handle the connection load? If so, I'd be curious to
know the details of that test (e.g. hardware specs, OS, connection load,
failure mode, etc.).


Justin

On Wed, Dec 18, 2019 at 8:39 AM ldebello <[hidden email]> wrote:

> Hi Justin,
>
> I was thinking about your point regarding performance and my concern is not
> regarding number of messages is more related to number of connections.
>
> In our model you register to our service and you become a consumer in the
> broker so per each registration we will have at least one connection in
> production we are supporting this without using a broker and having
> websockets but we want to move away from that model
>
> That is the reason why we are trying to use cluster and other features
> together
>
>
>
>
>
> --
> Sent from:
> http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
>
>