I'd store the job in some form of a persistent queue (msmq, ESENT, RDBMS, filesystem, whatever), have SOMETHING (see below) process that offline, and move to "Done" queue. Then have another page serve the "Done" stuff to the users.
as for the offline processor - you have three main options: 1. spawn a thread for each "process" request - this could be dangerous from stability standpoint (threads can be aborted by the environment) and will probably create too many threads anyway 2. If you have access to the machine and can setup a scheduled task that process the queue - that's cool 3. Expose an endpoint in the web app, that will get pinged every X seconds from a scheduled task at a computer you CAN control, initiating "process up to Y items from the queue" on every call. 4. setup a single worker thread spawned on App_Start, that will wait for a ManualResetEvent or something from the queue operation to kick in. I'd avoid 1. 4. is pretty straightforward and self maintaining if you do the multithreading part well enough. Get someone who knows his way there for code review as it could turn to nasty stuff easily. 2. is the most scalable option, but you need to make sure the scheduled task (or windows service, whatever) do not get stuck, gets restarted if it's blown away or something, etc. 3. is pretty easy, but is does require some other machine to ping the app, and you're back the need to make sure this runs even when you're on vacation or something. On Tue, May 4, 2010 at 5:50 AM, John Simons <[email protected]>wrote: > Jake, > > This is the way I previously dealt with this kind of situation: > - On the controller action method *spawn* another thread and do the report > generation there (see note about this) or if you have the resources, do it > out of iis process. > - Tell the user that the report is being generated (wait 10min blah blah > ...) and maybe provice a url to the user to retrieve the report or email the > user the url once report has been created. > - If the report is not user specific, provide a page with a list of > generated reports. > > Regarding *spawn* another thread in iis process, be aware that when an iis > app pool refresh occurs, spawn threads are aborted and it could leave your > report generation in an unknown state hence the reason to do it out of iis > process. > > Let me know if you need more details. > > Cheers > John > > ------------------------------ > *From:* jake <[email protected]> > *To:* Castle Project Users <[email protected]> > *Sent:* Tue, 4 May, 2010 10:20:17 AM > *Subject:* Job processing with monorail > > I have a page that generates a PDF report and serves it in the > response. Overtime, the report has gotten more and more complex to > the point that it sometimes takes a while to generate. I'd like to > create a job processing class that I can use so that when users kick > off the process I can just tell them to check back in 5 mins when it's > ready. It's inevitable that the report will start timing out because > of the amount of content the customer wants. What would be the best > way to tackle this, using Monorail of course? I'd like to keep all > the code in the web app if I could. > > Thanks, > Jake > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to castle-project-users+ > [email protected]. > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > > > > > -- > You received this message because you are subscribed to the Google Groups > "Castle Project Users" group. > To post to this group, send email to [email protected] > . > To unsubscribe from this group, send email to > [email protected]<castle-project-users%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/castle-project-users?hl=en. > -- Ken Egozi. http://www.kenegozi.com/blog http://www.delver.com http://www.musicglue.com http://www.castleproject.org http://www.idcc.co.il - הכנס הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם -- You received this message because you are subscribed to the Google Groups "Castle Project Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
