camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Carman <ja...@carmanconsulting.com>
Subject Re: [DISCUSS] Reusing Exclusive ReplyTo Queue..
Date Thu, 14 Jul 2016 11:49:09 GMT
They would be node-specific reply queues. No selectors necessary. Selectors
are slow. I'm not asking if I should do it. I'm asking the group if they
see any reason why we have to restrict Exclusive reply queues to one per
destination. I'm looking into patching the code, but if anyone sees an
issue with it, I won't bother.
On Thu, Jul 14, 2016 at 2:32 AM Siano, Stephan <stephan.siano@sap.com>
wrote:

> What's wrong with using selectors? You are using a shared queue for
> different endpoints, so in my opinion that's a very good reason for using a
> selector. How do you want to dispatch your reply messages to different
> endpoints without selectory?
>
> -----Original Message-----
> From: James Carman [mailto:james@carmanconsulting.com]
> Sent: Mittwoch, 13. Juli 2016 13:11
> To: dev@camel.apache.org
> Subject: Re: [DISCUSS] Reusing Exclusive ReplyTo Queue..
>
> Shared uses selectors. There's no reason to use selectors in my case
>
> On Wed, Jul 13, 2016 at 6:31 AM Siano, Stephan <stephan.siano@sap.com>
> wrote:
>
> > If you want to share a replyTo queue the replyToType is Shared, not
> > Exclusive, so this should already be supported, or do I geth something
> > wrong here?
> >
> > -----Original Message-----
> > From: James Carman [mailto:james@carmanconsulting.com]
> > Sent: Dienstag, 12. Juli 2016 15:47
> > To: dev@camel.apache.org
> > Subject: Re: [DISCUSS] Reusing Exclusive ReplyTo Queue..
> >
> > I am not talking about using a Shared reply queue.  I'm talking about
> using
> > Exclusive.  The idea would be to be able to send messages, using a
> > ProducerTemplate or something, like this:
> >
> > jms:queue:foo?replyToType=Exclusive&replyTo=REPLIES&concurrentConsumers=5
> > jms:queue:bar?replyToType=Exclusive&replyTo=REPLIES&concurrentConsumers=5
> >
> > Right now, this doesn't work.  Is there any reason folks can think of
> that
> > we wouldn't or couldn't support such a thing?
> >
> >
> > On Tue, Jul 12, 2016 at 1:50 AM Siano, Stephan <stephan.siano@sap.com>
> > wrote:
> >
> > > Hi James,
> > >
> > > I am not sure whether I understand the context. Are you talking about
> > > request/reply over JMS with the camel-jms component?
> > >
> > > In that case the replyToDestinationSelectorName parameter might help
> you
> > > with shared reply to queues. I actually do not see any impact that may
> > have
> > > on transactions. I haven't tried that out myself, though.
> > >
> > > Best regards
> > > Stephan
> > >
> > > -----Original Message-----
> > > From: James Carman [mailto:james@carmanconsulting.com]
> > > Sent: Montag, 11. Juli 2016 16:29
> > > To: dev@camel.apache.org
> > > Subject: [DISCUSS] Reusing Exclusive ReplyTo Queue..
> > >
> > > Right now, you must have a unique reply to queue for each destination.
> > > Would there be any impact of allowing folks to use a single reply to
> > queue
> > > for all destinations?  For example, suppose I want to use an
> "Exclusive"
> > > reply to queue per node within my cluster, but I want all replies (for
> > all
> > > routes) to go to REPLY_TO.<hostname>.  Would this impact transactions?
> > Is
> > > this doable?
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message