Hi Steve, I am not sure that a polling is a good solution.
Here are some additional details: The server indeed keeps the getValue call blocking for a given delay (configurable). After this delay the call returns. (The client calls timeout is also set to a configurable delay. But indeed no timeout will occur.) But other operations (control for example) might also take some time to proceed. The problem is that the client application has to exit at some time. Therefore, the client require a way to stop the ongoing operation calls in order to exit smoothly (as fast as possible). Finally, time consuming control operations for example could not be implemented through pooling... Nevertheless, the problem of repeated "instant" polling is that it will generate useless network traffic + consume resources just to know that there is nothing to get... The purpose of this application is to be efficient at runtime, without using complex mechanisms (architecture) to allow a simple client application stop. Thus, is there a way to stop an operation call at Axis level ? Thanks for your help Regards, Olivier Montabert -----Original Message----- From: Steve Loughran [mailto:[EMAIL PROTECTED] Sent: Monday, January 31, 2005 10:09 PM To: axis-dev@ws.apache.org Subject: Re: Client operation call interrupt - IMPORTANT Montabert, Olivier wrote: > Hi, > > I have the following architecture: > > Axis client stub ------ Axis server skeleton > > The client calls a synchronous operation on > the server. Let's call this operation getValue. > The server implementation of this getValue > operation is blocking until a value is available. > > This blocking call has to be interrupted in > some situations, like a client application exit. > > I see two solutions to stop (interrupt) this > client operation invocation: > - Set a timeout (different from -1) on the > client stub. > But in this case the Server has to detect > when a client operation call timed-out in > order to stop its processing and to prevent > a value loss. > > - Set an infinite timeout (-1) on the client > Stub. > In this case the client must be able to > interrupt this call. I dont think you should be blocking forever waiting for responses. not only do you consume resources client and server side, but things like proxies may have their own logic and break the connection after a period of time. And you'd consume sockets per held-connection on the proxy, which inherently has to share all its limited #of ports amongst all callers. Better to do an API with polling. -steve
