activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "clebert suconic (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (ARTEMIS-600) Enterprise message grouping
Date Wed, 10 Aug 2016 19:58:20 GMT

    [ https://issues.apache.org/jira/browse/ARTEMIS-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415909#comment-15415909
] 

clebert suconic commented on ARTEMIS-600:
-----------------------------------------

I really don't want to implement this. 

message grouping is already the kind of feature that is going around temporary queues, temporary
topics. 

To implement something like this we would have to break a lot of other cases... around Asynchronous
Queues.. etc...



I will close this as won't fix for now.

> Enterprise message grouping
> ---------------------------
>
>                 Key: ARTEMIS-600
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-600
>             Project: ActiveMQ Artemis
>          Issue Type: New Feature
>          Components: Broker
>    Affects Versions: 1.3.0
>            Reporter: Miroslav Novak
>            Priority: Critical
>
> 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
(v6.3.4#6332)

Mime
View raw message