That means that each request consumes at least 1MB of memory, and it introduce a lot of contention.
On Thu, May 6, 2010 at 9:24 AM, Ken Egozi <[email protected]> wrote: > well, my suggestion was to avoid spawning a new thread for each request. > option 4 is much easier to handle, has less potential multi-threading > issues, is more robust and consume less resources. > > > On Wed, May 5, 2010 at 10:22 PM, jake <[email protected]> wrote: > >> Thanks for the input everyone, I'll probably go with Egozi's >> suggestion and try using multiple threads, I don't know if I need a >> queue yet since the number of requests is relatively low, I might have >> to when the actions starts picking up. Hopefully I won't kill my site >> by spawning too many threads. >> >> Thanks, >> Jake >> >> On May 4, 5:18 am, Jason Meckley <[email protected]> wrote: >> > 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]><castle-project-users%2Bun >> [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...הכנס >> הקהילתי הראשון למפתחי דוטנט - בואו בהמוניכם >> > >> > > -- >> > > 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 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]<castle-project-users%[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]<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]<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]. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
