On Fri, 2014-01-31 at 16:13 -0800, Justin wrote:
> Good Evening,
>
> I'm working on a communication framework build on Qpid and I have two issues
> that I'm having difficulty solving:
>
> 1. I need to be able to support the one-to-many messaging paradigm, but my
> current setup isn't doing this. Specifically, I have one application
> publishing commands to a queue with an address like:
>
> applicationCommand / applicationName ; { create: always, node:{ type: queue,
> durable: true }}
>
> This command is intended for only a single instance of a single application,
> however right now it seems only the first instance of that application ever
> gets this message (first as in, the first one to grab it from the queue). If
> it isn't the right instance, the command never gets to the right place. I
> know that I could add additional data to the subjectto avoid this problem,
> but is we have other scenarios where queue'd data needs to get to multiple
> receivers. Is this possible somehow? I couldn't find anything in x-declare,
> but perhaps I missed it.
You could declare a topic rather than a queue and use topic matching in
the subscriptions + set the routing key when sending the message to make
sure the message goes to the right application.
>
> 2. When my applications are destructing, if some thread has a fetch() call
> in progress with an infinite timeout, I cannot get that thread to end. My
> research seemed to show that calling close() on the session object should
> abort a fetch() call, but I am not seeing this work. Is there something else
> I should be doing or some other mechanism to force a fetch() call to return
> prematurely?
>
> Thanks!
> Justin Scaduto
>
>
>
>
> --
> View this message in context:
> http://qpid.2158936.n2.nabble.com/2-Client-Question-Multiple-Receivers-Aborting-fetch-tp7603800.html
> Sent from the Apache Qpid developers mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
