Ayende - you can't say "That" without stating what "that" means :)
On Thu, May 6, 2010 at 9:57 AM, Ayende Rahien <aye...@ayende.com> wrote: > 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 <egoz...@gmail.com> 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 <jak...@gmail.com> 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 <jasonmeck...@gmail.com> 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 <egoz...@gmail.com> 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 < >>> johnsimons...@yahoo.com.au>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 <jak...@gmail.com> >>> > > > *To:* Castle Project Users <castle-project-users@googlegroups.com> >>> > > > *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 >>> castle-project-users@googlegroups.com >>> > > > . >>> > > > To unsubscribe from this group, send email to castle-project-users+ >>> > > > unsubscr...@googlegroups.com. >>> > > > 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 >>> castle-project-users@googlegroups.com >>> > > > . >>> > > > To unsubscribe from this group, send email to >>> > > > castle-project-users+unsubscr...@googlegroups.com<castle-project-users%2bunsubscr...@googlegroups.com><castle-project-users%2Bun >>> subscr...@googlegroups.com> >>> > > > . >>> > > > 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 >>> castle-project-us...@googlegroups.com. >>> > > To unsubscribe from this group, send email to >>> castle-project-users+unsubscr...@googlegroups.com<castle-project-users%2bunsubscr...@googlegroups.com> >>> . >>> > > 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 >>> castle-project-us...@googlegroups.com. >>> > To unsubscribe from this group, send email to >>> castle-project-users+unsubscr...@googlegroups.com<castle-project-users%2bunsubscr...@googlegroups.com> >>> . >>> > 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 >>> castle-project-us...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> castle-project-users+unsubscr...@googlegroups.com<castle-project-users%2bunsubscr...@googlegroups.com> >>> . >>> 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 >> castle-project-us...@googlegroups.com. >> To unsubscribe from this group, send email to >> castle-project-users+unsubscr...@googlegroups.com<castle-project-users%2bunsubscr...@googlegroups.com> >> . >> 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 castle-project-users@googlegroups.com > . > To unsubscribe from this group, send email to > castle-project-users+unsubscr...@googlegroups.com<castle-project-users%2bunsubscr...@googlegroups.com> > . > > 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 castle-project-us...@googlegroups.com. To unsubscribe from this group, send email to castle-project-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/castle-project-users?hl=en.
