Marshall Schor (JIRA) <uima-dev@incubator.apache.org> wrote: > >>>> are there use cases where the remote delegate would be able to get > requests from the remote broker, but possibly not be able to send it > replies? (e.g., due to firewall issues?) > >>>Yes, when the client is behind a firewall, but the remote delegate > [service] and it's broker are outside the firewall. This is one of the > motivations for always allocating the reply queue on the service's broker > (the other main one being to eliminate the need for a colocated broker to > instantiate a local reply queue, again something not possible with many JMS > implementations). > > Well, I meant the other way 'round. So let me try again - are there use > cases where the remote broker serves the remote delegate new work OK, but > for some reason can't host the reply queue?
Let's assume there is a case where the total size of in-transit request + reply messages for a single service are too big for a single broker; the AMQ answer would be to implement distributed queues. See http://activemq.apache.org/how-do-distributed-queues-work.html Putting reply queues on the client will burden every client with an extra memory requirement, and will require that memory planning for each client take into consideration all of its remote delegates. >>>>>There should only ever be one listener pulling messages off of the > reply queue. > >>>It is sometimes desirable to have more than one thread doing > deserialization of reply messages, which is the original point of this > issue. > > Yes, true - I meant one listener process (perhaps with mutliple threads > though). So there's no need to worry about "load balancing" due to prefetch > > 0 - or is there? Not sure how these threads for multiple concurrent > listeners interact with prefetch. Right, no load balancing issue for a reply queue. Eddie
