activemq-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Work logged] (ARTEMIS-2265) Support Federated Queues and Addresses
Date Thu, 07 Mar 2019 12:59:00 GMT

     [ https://issues.apache.org/jira/browse/ARTEMIS-2265?focusedWorklogId=209560&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-209560
]

ASF GitHub Bot logged work on ARTEMIS-2265:
-------------------------------------------

                Author: ASF GitHub Bot
            Created on: 07/Mar/19 12:58
            Start Date: 07/Mar/19 12:58
    Worklog Time Spent: 10m 
      Work Description: cshannon commented on issue #2573: ARTEMIS-2265 Support Federated
Queues and Addresses
URL: https://github.com/apache/activemq-artemis/pull/2573#issuecomment-470515574
 
 
   +1 for some of Gary's suggestions, they sound like a good idea as future enhancements.
 Maybe we can look at making the transport configurable, etc.
   
   I am very willing to help out with enhancements as this feature is very exciting.  I had
actually been experimenting with enhancing clustering the past few months trying to add features
or tweak it a bit but I have always thrown it away as I was never happy with how it turned
out.  Supporting dynamic bridges like 5.x seems like a great solution because often my thoughts
were "ok how can I make clustering act more like 5.x " :)
   
   What I found, at least for my use case coming from a 5.x setup, is that a clustering setup
makes the most sense from the standpoint of high availability and failover as the brokers
can be configured to act as a master/slave setup and being tightly coupled on startup and
configuration is fine as you want the brokers to act as a pair, especially in the replication
case. This setup isn't really ever dynamic so there's no issue like there would be with establishing
bridges dynamically.
   
   So thanks again @michaelandrepearce for getting this started.  This is really going to
be a great feature and will I think really help the adoption of people from 5.x who are used
to bridging brokers together in the 5.x way and want to continue that without setting up clustering.
(Such as myself :) )
   
 
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 209560)
    Time Spent: 4h 20m  (was: 4h 10m)

> Support Federated Queues and Addresses
> --------------------------------------
>
>                 Key: ARTEMIS-2265
>                 URL: https://issues.apache.org/jira/browse/ARTEMIS-2265
>             Project: ActiveMQ Artemis
>          Issue Type: Improvement
>            Reporter: Michael Andre Pearce
>            Priority: Major
>          Time Spent: 4h 20m
>  Remaining Estimate: 0h
>
> Currently Artemis supports linking of brokers via clustering that are within the same
DC or AZ. 
> It is not sensible to form clusters though over high latency or unreliable networks,
e.g. WAN, cross-region in cloud, hybrid on-off premise etc.
> Bridges exist, but these are static.
> In ActiveMQ5 there was a concept of Network of Brokers, and like wise in RabbitMQ there
is a concept of Federation, both of these try an deal with this issue.
>  
> This is to implement similar functionality in Artemis.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Mime
View raw message