Hi Adrian,
the case with multiple clients on the same queue can even be a big
advantage if you use it correctly. If a client A sends the request and
you do not need any context to process the reply then client B can pick
up from this point. I think in many cases this is not very difficult to
achieve and it gives you real fault tolerance and scalability on the
client.
When a context is needed the client can save it to a database before
doing the request.
I have already proposed a correlation handling that is independent from
the transports. This could then also support persistence. The problem is
though that the context a client needs to continue processing when a
reply is received can be more than the CXF Exchange that can be
retrieved with the correlation id. In any case it will not be possible
to simply do an synchronous call if you want to be able to restart the
client after the request has been sent. So I guess in most cases you
simply have to write the client in a really asynchronous way and do
correlation handling in the application layer.
Greetings
Christian
Adrian Corcoran schrieb:
Hi Christian,
Thanks for the reply! Yes this is along the lines of what I was thinking
that this could work - would be great this was in 2.1.4. But as you say the
issue with this is if there are multiple clients feeding off the same reply
queue.
Would it also be possible to supply CXF with a list of outstanding
correlation ids to process on start-up? Is there a way that we can do this
in CXF at the moment?
Perhaps even the implementation behind the storage of correlations ids could
be abstracted out so that by default CXF would use in process correlation id
store and if anyone wanted to get into persistence (XA transactions and all
that fun) they could write their own implemenation?
Any thoughts?
On Sat, Dec 6, 2008 at 9:08 AM, Christian Schneider <[EMAIL PROTECTED]
wrote:
--
Christian Schneider
---
http://www.liquid-reality.de
