Re: Concurrent Requests, Number of Instances & Scheduling
Re: Concurrent Requests, Number of Instances & Scheduling
- Subject: Re: Concurrent Requests, Number of Instances & Scheduling
- From: Philippe Rabier <email@hidden>
- Date: Tue, 05 Apr 2011 10:27:28 +0200
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@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden