On 2011-04-04, at 9:13 PM, Mike Schrag wrote: > given that this is a service call from a cron job, there's really no reason > to use a long response page (the cronjob probably doesn't care about the > response ... it's just kicking it off) ... just throw a runnable into an > ExecutorService thread pool, make a new eof stack, and go.
I'm not familiar with ExecutorService but a quick Google search shows it as an interface to split off and manage asynchronous threads? > > ms > > On Apr 4, 2011, at 9:02 PM, Kevin Hinkson wrote: > >> Thank you so much for your time guys. I'm digging into the LongRequest >> example to see how I can implement WOLongResponsePage. >> >> On 2011-04-04, at 8:53 PM, Chuck Hill wrote: >> >>> >>> On Apr 4, 2011, at 5:37 PM, Kevin Hinkson wrote: >>> >>>> Hi all, >>>> I am a bit puzzled about how WO handles concurrent requests. >>>> >>>> I have a request that can run for a very long time, let's say 30 minutes. >>> >>> That sounds more like a periodic task than a real request. >>> >>> >>>> After looking around at other posts, the options for allowing this to run >>>> without the adaptor and apache complaining after a minute or so are: >>>> >>>> * implement WOLongResponsePage >>>> * Adjust the adaptor timeout settings >>>> * make it run faster >>> >>> * Do what Mike said. Which in this case is The Right Answer. >>> >>> >>>> Since I could not make the data crunching any faster and I'm lazy, I opted >>>> to adjust the adaptor timeout settings. This worked fine I thought. >>> >>> That is not doing yourself any favors. That is just going to hide the >>> problem with your app gets overloaded and seriously annoy your users. >>> >>> >>>> I am also running my app with the argument >>>> -WOAllowsConcurrentRequestHandling=YES (among others settings) which I >>>> thought would mean that one instance can handle multiple incoming requests. >>> >>> Yes, but it does not make EOF multi-threaded. If your long request was >>> sending email instead of doing database access, then things would be >>> different. >>> >>> >>>> But that does not seem to be the case. My app is running with one local >>>> instance that should allow concurrent request handling but that one >>>> request (the long running one) blocks, preventing others from running >>>> (they just timeout). My solution has been to just add another instance and >>>> then schedule them to restart 12 hours apart. >>> >>> The preference is to run more than a single instance for load balancing, >>> fault tolerance, and scheduling. >>> >>> >>>> So, my questions. >>>> >>>> 1. Is changing the adaptor timeout setting the best option or is >>>> WOLongResponse inherently better in some way? >>> >>> See above. >>> >>> >>>> 2. What does WOAllowsConcurrentRequestHandling do or not do? Did I >>>> misunderstand this argument? >>> >>> It affects how HTTP requests are dispatched. It does not prevent >>> bottlenecks downstream in your code. >>> >>>> 3. Why do we have to schedule restarts of instances? I suspect it has to >>>> do with memory usage but I've never seen a clear answer on this. >>> >>> The main reason is to allow the JVM to return memory to the OS. It can >>> also help to coverup bugs in your code. >>> >>> >>> >>>> 4. How many instances should I really be running per app? Maybe some >>>> examples of how you guys handle deciding how many to run would be great. >>> >>> >>> I'd say a minimum of two and a maximum of how many are needed. If two >>> provides the response time you are looking for, then that is enough. Too >>> many wastes system resources. It is a balancing act. >>> >>> >>> Chuck >>> >>> -- >>> Chuck Hill Senior Consultant / VP Development >>> >>> Practical WebObjects - for developers who want to increase their overall >>> knowledge of WebObjects or who are trying to solve specific problems. >>> http://www.global-village.net/products/practical_webobjects >>> >>> >>> >>> >>> >>> >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> >> This email sent to msch...@pobox.com > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
