any time I need offline processing I use a windows service with a service bus communicating between the web and service. I favor Rhino.ServiceBus, but I hear NServiceBus and MassTransit have the same feature set.
On May 4, 2:07 am, Ken Egozi <[email protected]> wrote: > 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/bloghttp://www.delver.comhttp://www.musicglue.comhttp://www.castleproject.orghttp://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 > athttp://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]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
