With the default code generation (as it is in the ws-addressing sample), the client waits for the server to send response in the replyTo channel. I want my client to be non-blocking, BUT to ensure the request has been accepted on the server via the HTTP 20x transport-level response.
Maybe this is not a valid requirement, as this relies on transport-level HTTP response code to check for the message to have been accepted by the server, so this is not transport agnostic as ws-addressing may expect. If I was using a strict one-way transport (SMTP) I would have no way to get acceptance notification... I should change to 2 one-way services (on for request to server, on for callback), but this requires to split the WSDL and to change responsabilities on each parts : who is the maintainer of the data schema ? Nicolas. 2008/8/19 Adrian Corcoran <[EMAIL PROTECTED]> > I think that the important bit here is > > "I've tested the CXF ws-addressing example, and configured it for > asynchronous code generation" > > Why do you need to client call to be asynchronous? You are submitting an > asynchronous request and expecting to get back a 202 ( or should it be 204) > immediately - in essence a void doSomething() call. > > The next call is a callback from the server to the client when the > processing is complete. > > These are straight synchronous calls from the client point of view - 2 > separate calls, but the server is working in an asynchronous manner. > > On Tue, Aug 19, 2008 at 10:20 AM, Eoghan Glynn <[EMAIL PROTECTED] > >wrote: > > > nicolas de loof wrote: > > > >> Hello, > >> > >> I have a requirement to setup a WS client to do some asynchronous call, > >> based on ws-addressing : the idea is to set the "replyTo" wsa property > so > >> that the client just send the request and just wait for the HTTP 202 > >> (accepted), and not for the entire response that will come far latter. > >> > >> I've tested the CXF ws-addressing example, and configured it for > >> asynchronous code generation - this works fine, but I'm not convinced my > >> client waited for the HTTP 202 transport-level reponse, and have no idea > >> how > >> I could check this. > >> > > > > > > One way to test it would be to inject a sleep into the server-side > dispatch > > of the partial respones (i.e. the 202). > > > > You could do this by implementing a very simple interceptor that did > > nothing expect sleep for say 10 seconds. Add this interceptor to the out > > chain on the server side. Then it would be immediately apparent whether > the > > client runtime is blocking until the 202 arrives. > > > > Alternatively run the server under the control of a debugger, and place a > > break point in > org.apache.cxf.ws.addresssing.ContextUtils.rebaseResponse(). > > If you delay before resuming execution, again it should be apparent > whether > > the client runtime is waiting for the 202. > > > > BTW if your server is running standalone, for example the ws_addressing > > demo server launched from ant, its easy to attach to this JVM from > Eclipse > > in order to debug. Just add something like the following properties to > the > > server launch: > > > > -Xdebug -Xnoagent -Djava.compiler=NONE > > -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=5005 > > > > /Eoghan > > > > > > Could someone confirm this, and give me an idea how to implement this > >> half-asynchronous scenario : > >> > >> client > >> | ------------------------> Request <wsa:replyTo="X"> > >> | Server > >> | <------------- HTTP 202 accepted ---------------- | > >> | > >> does some other work (asynchronously) | process... > >> | > >> | <------------- Response ------------------------- | > >> AsyncHandler<Response> > >> | ------------- HTTP 200 -------------------------> | > >> > >> > >> Cheers, > >> > >> Nicolas > >> > >> > > ---------------------------- > > IONA Technologies PLC (registered in Ireland) > > Registered Number: 171387 > > Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland > > >
