activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Bertram <jbert...@apache.com>
Subject Re: Temporary Branch for ARTEMIS-780
Date Tue, 15 Nov 2016 04:00:27 GMT
> It'd be good to get an understanding about how this affects the overall roadmap of Artemis.

This is really just another step in Artemis' evolution to becoming a more well-rounded multi-protocol
broker by allowing a broader range of messaging semantics to be more easily configured.  The
document that Martyn attached to ARTEMIS-780 describes all this pretty thoroughly although
anybody whose used the broker for long has likely noticed the limitations this work is attempting
to address (e.g. the requirement to use "jms.queue." or "jms.topic" when communicating between
protocols even when neither of those protocols is JMS).


> If I read the code changes correctly, you're essentially adding config options that indicate
a destination has multiple subscribers.

Actually the existing configuration schema already supported mapping multiple queues to an
address (i.e. "subscribers" to a "destination").  From a user's point of view the changes
are more about allowing easy configuration of both pub-sub and point-to-point semantics along
with removing the address prefix restriction imposed by the JMS implementation.


> I have cases where I may have a single client representing multiple physical servers.
 Is that going to be possible still if I have infrequently accesses clients?

Can you elaborate on this a bit more?  What protocol are you using?  What are the clients
doing exactly?  What's the use-case?  The more specific you can be the better.


> ...the ticket's state doesn't seem to match the current wip.

Can you clarify what you mean here?  How does the "ticket's state" not match the current work-in-progress
on the ARTEMIS-780 branch?



Justin

----- Original Message -----
From: "John D. Ament" <johndament@apache.org>
To: dev@activemq.apache.org
Sent: Thursday, November 10, 2016 8:29:16 PM
Subject: Re: Temporary Branch for ARTEMIS-780

On Thu, Nov 10, 2016 at 8:51 AM Justin Bertram <jbertram@apache.com> wrote:

> I think the JIRA itself pretty well sums it up -
> https://issues.apache.org/jira/browse/ARTEMIS-780.
>
>
I suspect you have a lot more context to this than is really stated in the
ticket.  Its not a bad thing, but imagine those who are outside trying to
make sense of this.

The ticket describes a potential problem - how topics are implemented in
Artemis as basically special queues based on the subscribers (queue per
subscriber).

It'd be good to get an understanding about how this affects the overall
roadmap of Artemis.  If I read the code changes correctly, you're
essentially adding config options that indicate a destination has multiple
subscribers.  I'm mostly curious after looking at it around how pubsub
messaging operates.  I have cases where I may have a single client
representing multiple physical servers.  Is that going to be possible still
if I have infrequently accesses clients?

More than anything its pure curiosity about how something might be working
that is on going, especially when the ticket's state doesn't seem to match
the current wip.

John


>
> Justin
>
> ----- Original Message -----
> From: "John D. Ament" <johndament@apache.org>
> To: dev@activemq.apache.org
> Sent: Thursday, November 10, 2016 7:21:35 AM
> Subject: Re: Temporary Branch for ARTEMIS-780
>
> Hmm so I missed this the first go around.  The note from Justin made me
> take a look.
>
> What exactly is ARTEMIS-780?  Whats the idea behind it?
>
> John
>
> On Tue, Oct 18, 2016 at 2:56 PM Martyn Taylor <mtaylor@redhat.com> wrote:
>
> > All,
> >
> > I'm starting to look at the improvements around the addressing model
> > (ARTEMIS-780) there's going to be a fair amount of change involved that
> may
> > break certain parts of the broker (at least until it's fully completed).
> >
> > For this reason, I've created a separate branch "ARTEMIS-780" to house
> > changes until it's ready to merge on master.  It also means that others
> can
> > work on sub tasks in parallel.  I'll ensure the branch is deleted once
> the
> > work is merged onto master.
> >
> > Thanks all
> > Martyn
> >
>

Mime
View raw message