Mailing-List: contact dev-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Developers List" <dev@tomcat.apache.org>
Received-SPF: neutral (athena.apache.org: local policy)
Message-ID: <47834A87.8010506@apache.org>
Date: Tue, 08 Jan 2008 11:03:51 +0100
From: Mladen Turk <mturk@apache.org>
User-Agent: Mozilla
MIME-Version: 1.0
To: Tomcat Developers List <dev@tomcat.apache.org>
Subject: Re: svn commit: r609757 - in /tomcat/connectors/trunk/jk/native:
 apache-1.3/mod_jk.c apache-2.0/mod_jk.c
 common/jk_service.h		 common/jk_util.c
 iis/jk_isapi_plugin.c netscape/jk_nsapi_plugin.c
References: <20080107194150.47D581A9850@eris.apache.org>
 <478294C6.6040004@apache.org> <4782B9D9.5060007@kippdata.de>
 <47832266.7070101@apache.org> <47832BBF.3050200@kippdata.de>
In-Reply-To: <47832BBF.3050200@kippdata.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Rainer Jung wrote:
> Mladen Turk wrote:
>> Rainer Jung wrote:
>>>
>>> Does that make sense for you?
>>>
>>
>> Yes it does. The most important is that if
>> there was no retries set for ajp worker, it gets copied
>> from lb worker.
> 
> In fact we don't copy (this is not new), because the retries for an lb 
> has a different functional meaning than for an lb sub worker. If an ajp 
> worker (main worker or lb sub worker) doesn't have a retries set, it 
> gets the default value JK_RETRIES (=2).
> 

Hmm, I think the elected worker in mod_jk was setting the service's
retries, and then service was setting particular real workers retries.

I'm almost sure each worker inherited the retries from
lb (at least it should).

Regards,
Mladen

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