activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan Yeats (JIRA)" <>
Subject [jira] [Commented] (ARTEMIS-600) Enterprise message grouping
Date Sat, 04 Feb 2017 19:48:52 GMT


Ryan Yeats commented on ARTEMIS-600:

I'm glad I saw this ticket before I started using this feature more, if its not going to be
fully supported then I would at least like the drawbacks documented along with this feature
so everyone knows to use temporary queues instead. This feature isn't perfect in activemq
either if the traffic isn't balanced it doesn't self rebalance but I found it useful and I
don't see how temporary queues cover all the use cases for this.

> Enterprise message grouping
> ---------------------------
>                 Key: ARTEMIS-600
>                 URL:
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 1.3.0
>            Reporter: Miroslav Novak
>            Priority: Critical
>             Fix For: 2.0.0
> Message grouping in Artemis is squishy as almost anything can break it at this moment.
*Drawbacks in current design:*
> * Consumers must be connected before messages are send to cluster
> * If producers sends message to cluster and there is no consumer in cluster then message
is stuck on this node. Consumer which later connects to another node in cluster does not receive
this message.
> * If server in cluster is shutdown then all message grouping breaks and no other node
in cluster is able to receive message (not even on other queues)
> * There is issue that backup for remote grouping handler does not take duties after failover.
> * If consumer is closed then no other consumer is chosen
> *Suggested improvements:*
> * Decision to which consumer to route a message, will not be made during send time in
case that there is no consumer. 
> * Consumers do not have to be connected when messages are sent to cluster.
> * Message grouping will allow to cleanly shutdown server without breaking message ordering/grouping.
Connected consumers will be closed. Another consumer in cluster will be chosen.
> * Futher If any consumer is closed then another consumer will be chosen. 
> * Allow to configure dispatch delay to avoid situation that first connected consumer
in cluster gets assigned all message groups. Delay will wait for other consumers to connect
so message groups are equally distributed. (we can consider setting minimum consumer number)

This message was sent by Atlassian JIRA

View raw message