For any ASP.Net programmers out there, I’m looking for a design pattern or sample code for the following problem. If nobody has any ASP.Net references, I’ll be glad to take any ASP references and port them.
The website we’re building is used to trigger managerial/network admin batch processes that run on the server farm and take anywhere from 10 seconds to 10 minutes to execute. We’d like the user page to have a submit button that starts the batch process and then the server will come back with some sort of continuously-updating progress display.
The coordination to launch the out-of-process batch thread is easy. My challenge is obtaining status updates back, feeding those updates to the browser and displaying them in something that looks halfway decent. Another challenge is serverside and clientside timeouts; I’m still experimenting with caching the callback or sync object across page views. That may or may not pan out. I’m trying to avoid bumping the server timeout to 10 minutes; I’d prefer something that amounts to polling at 15 second intervals but I’m not sure who should be driving the poll, client or server.
One last thing: I’d like to avoid client side code as much as possible.
Anybody got any pointers? Google wasn’t helping, largely because I wasn’t able to distill the question sufficiently.
Without client-side code, you have to rely on server push, which isn’t supported in most browsers. In the systems I’ve done, the polling you describe is driven by client-side code, sometimes Javascript in the HTML page displayed in the browser, but more often in a little Java applet because this makes the timing, polling, and error handling much more robust. You could do the same with any kind of embedded component or client-side code that allows you to issue an HTTP query.
You provide some process on the server that can respond to status queries. The details of that depend on what your server-side process is doing and how you can measure or mark progress, but basically this is just an ASP page that will take a process identifier as input and respond with status info. The client-side code can then query this page as needed to update the client display.
This architecture is thin on details and probably pretty obvious, but the client-side implementation is pretty simple and the server-side depends on the details of your server-side process.
Best way to do this is to send the user to a status page after submitting the process. In the Page_Load of the status page, check the status; if Done, go to the Done page. If not, output the current status. i.e. :
Then, put a Refresh button on the page, which just does a postback; and lastly, put a meta-refresh header so the page automatically reloads every n seconds or so.
You already have your answer, but to get out of the box:
You are describing an asynchronous process. An asynchronous process ideally should communicate through an asynch channel. The most common asynch channel available to humans: email.
Your solution is certainly one way to do it, but it’s by no means the best. The OP’s situation is under specified to detemine which of a myriad possible solutions is best. In many cases, a “click here to check status” or a meta refresh is too course-grained or unacceptable for a number of other reasons. In many cases, some PHB may require a moving blue bar to indicate progress regardless of whether that’s useful to the user. In other cases, the server-side process may take so long that the user can’t be expected to leave their machine on, much less leave the same browser window refreshing (not the case for the OP, but in general).
Not knocking your solution, just your use of “best”.