I looked at WS-Addressing and got all the headers and stuff correct but I don't quite get how the delayed response would come back to the client. Is the client 'faking' an indefinite timeout or is something else suppose to happen? The facts of me not understanding this yet and that it needed to be done yesterday evening made me choose for option 2 at this moment, but I will probably go for WS-Addressing when I have it working since that would make working with asynchronous calls a lot easier. The configuration was as easy as expected. Great stuff guys! Will PHP and .NET clients be able to work with WS-Addressing? Anyone know issues with that?
Ronald dkulp wrote: > > > > Couple options: > > 1) Use a WS-Addressing decoupled endpoint for the response. The server > would > then basically send it back on a decoupled channel when it's ready. > > 2) Increase the timeout on the client side. We default it to 60 seconds, > but > it's easily configured (or even turned off). > > 3) Use a more "callback" pattern where the client creates an endpoint to > get > the response, sends the endpoint reference with the request, then waits. > Quite a bit more work and essentially does what the case 1 above does. > > Dan > > > On Thursday 09 October 2008 10:27:42 am Ronald Pieterse wrote: >> Hello. >> >> In my service doing some time consuming stuff (reading email and handling >> them) thus the connection is timing-out before I can start sending the >> response. What way would I need to walk to keep the connection open? Is >> there any way CXF can help in this? >> >> Thnx, >> Ronald > > > > -- > Daniel Kulp > [EMAIL PROTECTED] > http://dankulp.com/blog > > -- View this message in context: http://www.nabble.com/How-to-handle-a-large-response-object-or-attachment-with-CXF--tp19900120p19932789.html Sent from the cxf-user mailing list archive at Nabble.com.
