WebService and Polling

Question

Hi,

I'd like to implement a WebService containing a method whose reply will be delayed for less than 1 second to about an hour (it depends if the data is already cached or neeeds to be fetched).

Basically my question is what would be the best way to implement this if you are only able to connect from the client to the WebService (no notification possible)?

AFAIK this will only be possible by using some kind of polling. But polling is bad and so I'd rather like to avoid using it. The other extreme could be to just let the connection stay open as long as the method isn't done. But i guess this could end up in slowing down the webserver and the network. I considerd to combine these two technics. Then the client would call the method and the server will return after at least 10 seconds either with the message that the client needs to poll again or the actual result.

What are your thoughts?

Answer 1

You probably want to have a look at comet

Answer 2

I think that for something which could take an hour to respond a web service is not the best mechanism to use.

Why is polling bad? Surely if you adjust the frequency of the polling it won't be so bad. Prehaps double the time between polls with a max of about five minutes.

Answer 3

Some web services I've worked with return a "please try again in " xml message when they can't respond immediately. I realise that this is just a refinement of the polling technique, but if your server can determine at the time of the request what the likely delay is going to be, it could tell the client that and then forget about it, leaving the client to ask again once the polling interval has expired.

Answer 4

There are timeouts on IIS and client - side, which will prevent you from leaving the connection open. This is also not practical, because resources/connections are blocked on the server.

Why do you want the user to wait for such a long running task? Let them look up the status of the operation somewhere.

Answer 5

I would suggest a sort of intelligent polling, if possible:

• On first request, return a token to represent the request. This is what gets presented in future requests, so it's easy to check whether or not that request has really completed.
• On future requests, hold the connection open for a certain amount of time (e.g. a minute, possibly specified on the client) and return either the result or a result of "still no results; please try again at X " where X is the best guess you have about when the response will be completed.

Advantages:

• You allow the client to use the "hold a connection open" model which is relatively expensive (in terms of connections) but allows the response to be served as soon as it's ready. Make sure you don't hold onto a thread each connection though! (And have some kind of time limit...)
• By saying when the client should come back, you can implement a backoff policy - even if you don't know when it will be ready, you could have a "backoff for 1, 2, 4, 8, 16, 30, 30, 30, 30..." minutes policy. (You should potentially check that the client isn't ignoring this.) You don't end up with masses of wasted polls for long misses, but you still get quick results quickly.