Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: pass (athena.apache.org: domain of adrian.corcoran@gmail.com
 designates 64.233.182.184 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=OKwG5P7/0ZW3+ONk8MW4ZbtuVSZYQXpZxaCmOs5tcmP4RoV+xiHoBsYiVSuHD803Xk
         UjfAfp2CK8PDarQbqqIH1ZGkV2u/bSiET+PcxYQiomJjwni1YOtisiYCbo0IPf+nJpjE
         B1J2Rpf94Jsfhl666DaBi76K76qIfoaBO5Eyw=
Message-ID: <f4248a250812070704q6b0f9fd6xbd590b5f18efc1cf@mail.gmail.com>
Date: Sun, 7 Dec 2008 15:04:07 +0000
From: "Adrian Corcoran" <adrian.corcoran@gmail.com>
To: users@cxf.apache.org
Subject: Re: jms client restart
In-Reply-To: <493A4127.1090400@die-schneider.net>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_56386_23682833.1228662248014"
References: <20853766.post@talk.nabble.com>
	 <493A4127.1090400@die-schneider.net>

------=_Part_56386_23682833.1228662248014
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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 <chris@die-schneider.net
> wrote:

> Hi Adrian,
>
> as far as I know it is not possible to continue a synchronous request after
> a client restart. I use synchronous calls only for read requests. In this
> case I set a timeout for the message so it gets discarded after some time.
>
> If you call a write operation it is perhaps best to do it completely
> asynchronous by using a one way service for the call to the operation. The
> reponse could then be sent to another one way service that listens on a
> topic. The client can then "offer" this service to listen for the response.
>
> Perhaps it is also possible to change cxf in a way to support this
> scenario. We had a similar case in the company I work for. We went with the
> solution above but it is quite complicated. Perhaps we can support the same
> level of security with some changes in CXF. Since some time CXF supports
> asynchronous calls to a request / reply service. If it really does not
> matter which instance of a client receives the response we could turn of the
> correlation id checking. So the scenario would look like this:
>
> - Client send a request with an asynch frontend and gives a permanent reply
> queue
> - Client goes down
> - Server replies on the reply queue. The reply message should have no
> timeout in this case
> - Client comes up again
> - Client receives the reply on the reply queue. Since correlation checking
> is turned off it processes the reply
> - The reply handler of the asnyc frontend is called with the reply
>
> What do you think?
>
> Greetings
>
> Christian
>
> Adrian C schrieb:
>
>> Hi,
>>
>> I have question about hows best to deal with a client application
>> restarting
>> while waiting to receive a response.
>>
>> Here's the scenario - a client application is invoking a synchronous web
>> services over JMS. If the client is restarted or crashed after a request
>> has
>> been send to the broker how should the client pick up the message once the
>> client restarts?
>>
>> Would is be possible to store the correlation id of the message once
>> dispatched & persist this. If the client restarts and there are
>> outstanding
>> correlation ids then it must poll for these messages - however how would
>> one
>> get CXF to process this message as the response to the original request?
>>
>> I am sure this is an issue that others have faced or perhaps I am missing
>> something.
>>
>> Thanks,
>>
>>
>>
>
>
> --
>
> Christian Schneider
> ---
> http://www.liquid-reality.de
>
>

------=_Part_56386_23682833.1228662248014--