Peters observation concerning mod_jk forced recovery

[Rainer Jung <ra...@kippdata.de>]

Thanks for the report:

The new forced recovery feature tried to do that in case all workers 
went into ERROR state in two places: after request processing and during 
maintenance.

After request processing it relied on a condition that evaluated to 
false in all cases, so it basically never happened there, only during 
maintenance.

I hope my three latest commits fixed it. So if all workers are really in 
error during request processing, the request gets a second chance on 
them, indepependently from the point in time when the workers went into 
error. If tomcat is still down/in error, after request processing all 
workers will end up being in error.

For the maintenance part, I changed it from checking during every 
process maintenance, to checking only during global maintenance. If the 
request part is correct, it should never be necessary during 
maintenance, since the request part already handles it, whenever it's 
necessary. Dropping the maintenance part might only result in slightly 
different logging messages and a different view in jkstatus. But even 
without the maintenance part, recovery should happen immediate, whenever 
a request comes in and all workers are in error.

Regards,

Rainer

Peter Rossbach wrote:
> Hi Mladen and Rainer,
> 
> sometimes I see a small time a strange artifact:
> 
> start apache
> look at jkstatus
>     all worker show state N/A
> all backend tomcats are stopped
> access a URL
> look at jkstatus
>     all worker show state ERR
> access URL again
>      all worker show state REC (very nice new feature)
> start tomcat
> access URL
>     one worker OK
>     other worker state REC
> stop tomcat
> access URL again
>      all worker show state REC (cool)
> 
> I thing first report is a bootstrap problem, but I can find it :-)
> 
> regards
> Peter
> 
> 
> Am 13.09.2006 um 16:07 schrieb Rainer Jung:
> 
>> In preparation of release 1.2.19 of tomcat-connnectors (including  
>> mod_jk) I made the actual HEAD of the code available for download  and 
>> testing under
>>
>> http://people.apache.org/~rjung/mod_jk-1.2.19-442987/
>>
>> This is not an official release, but another opportunity to give  the 
>> code a quick try before we cut the release.
>>
>> The release is being planned for tagging during saturday.
>>
>> Regards,
>>
>> Rainer
>>
>> Rainer Jung wrote:
>>
>>> Yes, I'm willing and I've got time to cut a release during the  weekend.
>>> I'll put a HEAD tarball on people.apache.org during the next hour  
>>> and announce that on tomcat-dev, so that interesting parties have  
>>> another chance of giving it a quick try (since wwe've got again a  
>>> lot of changes since the last quality check).
>>> Tagging will be done during Saturday. Is there a need to announce  
>>> precise timings, or are there no more pending changes?
>>> Regards,
>>> Rainer
>>> Mladen Turk wrote:
>>>
>>>> Hi,
>>>>
>>>> Seems we had a pretty long test window.
>>>> Can we schedule the release by the end of this week?
>>>> Rainer, are you still willing to act as the RM for 1.2.19?
>>>>
>>>> Regards,
>>>> Mladen.
>>>>
>>>> -------------------------------------------------------------------- -
>>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org