Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <46A7B550.3060309@kippdata.de>
Date: Wed, 25 Jul 2007 22:40:48 +0200
From: Rainer Jung <rainer.jung@kippdata.de>
User-Agent: Thunderbird 2.0.0.5 (Windows/20070716)
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: mod_jk error detection
References: <1185371238.3751.32.camel@jarjar.trnswrks.com>
 <46A76570.9090401@kippdata.de>
 <1185389351.27635.11.camel@jarjar.trnswrks.com>
	 <46A7ABCE.2080801@kippdata.de>
 <1185395117.27635.29.camel@jarjar.trnswrks.com>
In-Reply-To: <1185395117.27635.29.camel@jarjar.trnswrks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Scott McClanahan wrote:
> Thanks, so much! I'd like to continue this thread a bit more because of
> helpful I think it will be for everyone using mod_jk.
> 
>> That one, reply_timeout, is not really meant for high speed detection. 
>> Usually you've got an ap, that every now and then needs 10 or 20 seconds 
>> for an answer and you don't like to disable a worker automatically 
>> because of those rare events. So normally one sets reply_timeout to 1, 2 
>> or 3 minutes.
> 
> I don't understand what besides a timed out CPING/CPONG message would
> render a backend tomcat disabled, especially in a default config since
> reply_timeout is 0.

Default config: no CPing/CPong. But: after some time the TCP stack will 
give up, when there is a network problem, or the backend is no longer 
listening. So this case will even be handled in a default config, but 
depending on the exact network situation, the error detection might take 
a long time.

n case your backend simply eats your requests, but doesn't produce 
answers, you will very fast eat up all connections and threads and the 
whole system will hang - without configured timeouts.

BTW: there is also a non-default config to make a worker fail on several 
received HTTP status codes, "fail_on_status".

>> We have to strongly make a difference between retries of a non-lb worker 
>> and of a load balancer worker. A normal worker has a simple retry 
>> procedure, independant of the fact, if it is used directly or as part of 
>> an lb. If it detects an error it uses another pool connection and by 
>> default tries once more.
> 
> If that happens does the real worker officially change to an error state
> which would subsequently kick off the retry logic of the load balancer
> worker?

Without an lb a worker does not have an error state. It will be 
continuously reused. Only an lb uses error states and temporarily 
disables a failed worker. Even an lb will continuously reuse a worker, 
if there is no other worker to failover.

>> The maintenance uses a real request and handles it as if the backend 
>> wouldn't have failed. If you enabled CPing/CPong this means, that it 
>> would detect a still broken backend early and transparently send the 
>> request to another member. Because no part of the request (the CPing 
>> doesn't count) already has been send, the failover to another member 
>> happens independently of recovery_options (i.e. even with 
>> recovery_options 3).
> 
> Is the request used to test the health of the backend tomcat whichever
> one comes first after a global maintenance run even if it has been
> previously serviced by another healthy tomcat?  Is this request attempt
> to a once errant worker only to test its healthiness and not to actually
> have it fulfill the request?  I would hope it is only to test the health
> of the backend tomcat and even if it is now willing to accept
> connections, the request goes to whatever tomcat has been previously and
> successfully responding to the session.

No, the first new request accepted by the web server and mapped to the 
lb will be used (at least if it is free to be routed to any worker. If 
the request belongs to a session located on another backend and the 
default config with sticky sessions is active, it will of course be send 
to its correct backend). It is a real user request. If the backend 
works, OK. If it doesn't accept the request, we can still send it to 
some other worker. If the backend accepts the requests, but processing 
fails, depending on recovery_options the user gets an error.

>> If you like to improve the page about load balancing or the timeouts 
>> page, or you want to add some parts about retries and recovery: 
>> contributions are welcome.
> 
> After, we are done discussing I might have some recommendations.  Again,
> you've been great.

Thanks. At least we improve the knowledge inside the mailing list archive.

Regards,

Rainer

---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org