Server Side code Pushing Data to client Browser while current thread is busy Comet (programming)

Question

Hello Friends,

I am writing one simple web page with bunch of textboxes and a button control. Now when user finished editing the values on this text boxes user has to click the button and this button invoke heavily process intensive algorithm on server side code based on the data received from client (Textboxes)

And it could some time takes up to 30 to 45 minutes to complete the whole operation so the current thread is still inside the button click event handler function.

That background task only provides one event, and the web page subscribes to it to get some text data after each stage of processing

I was wandering if there is any way I can keep user up-to-date with what is the current progress on that background task. I have div element to print the current status information

So I am looking for some sort of reverse mechanism then "get" and "post".

I have read some articles on the Comet (programming) but I can't find any easy or definitive answer

Thanks in advance

Answer 1

Perhaps the simplest way is to submit the job, and get an id back via a straightforward page POST. That id corresponds to the long running job on the server side.

The returned page can then automatically refresh via the HTTP meta refresh mechanism, and the server can return status etc. in the refreshed page. The page will continually refresh with the id every (say) 30s until the job is complete.

It's a brute-force mechanism, but it's straightforward. Plus it has the advantage of allowing the user to bookmark the page and go away/come back. Given that your job is running for 30/45 mins, that could be important.

Answer 2

You are on the right track with 'Comet' (aka Ajax-Push or reverse-Ajax) - Comet is essentially an umbrella term for the ability for the server to 'push' something back to the client without the client triggering the event. Some Ajax frameworks are starting to build this in, and it is not something i would suggest trying to implement yourself close to the metal, because there are a lot of different things to consider (different webapp servers, threading models, etc). You can see that StackOverflow has some of this functionality, when it notifies you of a new answer coming in if you are writing one yourself for a given question.

Now all that being said, in your case, given the length of time of the server side processing, I would agree with Brian's answer that you should give the running job an id and use a more simple refresh mechanism to check it. If you wanted to add the look and feel of a server side push, you could query the server via standard ajax on an interval to check if the job is done rather than a simple refresh, and change the page when it is done through that Ajax call. If your job is able to report progress, then standard ajax could refresh your div with that progress, and there is no need for a server side push.

Answer 3

I agree completely with Brian Agnew's suggestion, with one possible improvement. Since you're essentially doing server-push operations, it might be worth considering a comet server. Now, I say that with a caveat - if you're really only managing jobs that complete every 30-45 minutes, then it may well be overkill. However, it has the advantage that you can push the results to the user when they've completed, and if the user is not longer connected, you can do something different (such as send them a notification email).