You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Martyn Taylor <mt...@redhat.com> on 2016/10/18 18:56:35 UTC
Temporary Branch for ARTEMIS-780
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
Re: Temporary Branch for ARTEMIS-780
Posted by Martyn Taylor <mt...@redhat.com>.
Hi John,
Apologies for not getting to this sooner, I have taken some time out to
write up more background , problems and what the proposal is. I'll add it
to the JIRA as soon as I'm done. The crux of this change is adding the
ability to define various destination types / behaviours (things like being
able to define a non shared subscription queue for example) in a single
unified way in core vs on a per protocol basis (like with JMS). The fact
that adding common behaviours like simple pub/sub in the protocol modules,
and having no way (other than JMS which has it's own issues) to allow a
user to define a pub/sub endpoint has been a real issue.
This would also involve moving the current JMS way of doing things, to the
new model. And is actually the main bulk of the work. As It turns out.
the current JMSisms have leaked into many areas of the core engine and
other protocols, trying to remove it has been a pain. I already had an
idea that this would be the case, hence the branch., but turned out to be a
lot more that I had expected
Re: Your use case, just to assure you, the idea is not to remove any of the
existing core concepts, everything you can do now, you'll continue to be
able to do after the change. There might be some slight configuration
changes in the new scheme to expose new functionality and move away from
the specific JMS stuff, but I'm going to provide a tool for migrating
configurations (the changes aren't big, just the exposing of the new
addressing model and removal of the JMS specifics).
I look forward to talking to you more on the JIRA. I also like to hear use
cases from Artemis users :) so I'd be interested to hearing more about what
your doing. It might be that these changes make things a bit easier for
you.
Cheers
Martyn
Re: Temporary Branch for ARTEMIS-780
Posted by Justin Bertram <jb...@apache.com>.
> 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" <jo...@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 <jb...@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" <jo...@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 <mt...@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
> >
>
Re: Temporary Branch for ARTEMIS-780
Posted by "John D. Ament" <jo...@apache.org>.
On Thu, Nov 10, 2016 at 8:51 AM Justin Bertram <jb...@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" <jo...@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 <mt...@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
> >
>
Re: Temporary Branch for ARTEMIS-780
Posted by Justin Bertram <jb...@apache.com>.
I think the JIRA itself pretty well sums it up - https://issues.apache.org/jira/browse/ARTEMIS-780.
Justin
----- Original Message -----
From: "John D. Ament" <jo...@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 <mt...@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
>
Re: Temporary Branch for ARTEMIS-780
Posted by "John D. Ament" <jo...@apache.org>.
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 <mt...@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
>