Eoghan,Right, my concern is whether same client consumes response message. >From you example I see how I could supply different selector prefixes for different cluster nodes.
Then, down to single node scale, is it safe to use static response queue, if the same client is used from within different concurrent threads? (<jaxws:client/> creates a singleton, not a prototype, right?) Thanks for response, Pavel On Wed, Mar 10, 2010 at 3:31 PM, Eoghan Glynn <[email protected]> wrote: > > so that right consumer will create the right response? > > Did you mean, so that the appropriate client (which sent the corresponding > request message) with itself consume the response message? > > The problematic case would occur if more than one of the clients are > concurrently making invocations, then there'd be a non-deterministic race > condition as to which of these clients consumed the first response message > put on the shared queue. > > So you'd at least need the CXF JMS client's message listener to constrain > message selection so as to ensure that it only receives responses > corresponding to requests issued by that same client. I think you could > probably achieve this via the conduit selector prefix mechanism, something > like: > > <jms:clientConfig conduitSelectorPrefix="replicated_client1:" > useConduitIdSelector="true"/> > > where the prefix is unique for each client. > > Cheers, > Eoghan > > > > On 10 March 2010 12:43, Pavel <[email protected]> wrote: > > > Hi, > > > > Is it possible for multiple CXF web service clients to use same static > > request and reply queues? I mean would they work correctly in a clustered > > configuration, so that right consumer will create the right response? > > > > ===== > > Today we do clustering in a similar way, but using temp queues. This > works > > fine until network or ActiveMQ goes down for while. While one of the > > directions is to look into AMQ itself, we'd like to see if static > response > > queues also possible. > > > > Thanks, > > Pavel > > >
