I gonna give you some piece of code in a separate email. But you have to read the documentation a little bit.
Philippe On 5 avr. 2011, at 03:19, 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/prabier%40me.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]
