On Apr 4, 2011, at 21:27, Mike Schrag <[email protected]> wrote:
> yeah .. it's preferable to use that over just creating your own thread (so it > can manage how many threads you'll end up with at once) ... > Ok. Thanks again. > On Apr 4, 2011, at 9:19 PM, Kevin Hinkson wrote: > >> >> 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 ([email protected]) >>>> Help/Unsubscribe/Update your Subscription: >>>> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >>>> >>>> This email sent to [email protected] >>> >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/mschrag%40pobox.com >> >> This email sent to [email protected] > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
