> 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" <[email protected]> To: [email protected] 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 <[email protected]> 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" <[email protected]> > To: [email protected] > 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 <[email protected]> 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 > > >
