Hi Christian,

So when you say that you have to write the client in a really asynchronous
way are you saying you don't really think that there is a way that this can
be done using CXF?

Thanks,
 Adrian

On Sun, Dec 7, 2008 at 8:21 PM, Christian Schneider <[EMAIL PROTECTED]
> wrote:

> 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
>
>

Reply via email to