Subject: Re: mod_jk - fail_on_status per LB, not per worker 2007-10-04 - By James Masson
Back
Hi Rainer,
thanks for the advice - I think we'll stick with the current
configuration, as people here seem to understand it quite well. I don't
really like the idea of having to custom tweak things like the time-outs
on connection pools, for every entry, just because we're trying to make
mod_jk do something it wasn't designed to do.
Hopefully this enhancement will make it onto your to-do list at some
point. I'll be patient, if you need any help in testing this, let me know...
regards
James Masson
Rainer Jung wrote:
> No easy idea. At the moment, fail_on_status is only for workers, and
> not for workers in mounts.
>
> If you want to go the worker way, there are some simple tricks to not
> make it to complicated:
>
> - you can use the reference-attribute, to use worker templates. That
> way each worker only needs to config lines, that are individual for
> the worker. Worker templates also work hierarchical, so you can have a
> very general setup, then some additional things for alle workers
> belonging to some app etc. and finally the things for individual workers.
>
> - If you use multiple workers per Tomcat (e.g. worker=webapp), then to
> keep stickyness, you don't use the automatic worker name = jvmRoute.
> Instead you add the route attribute to the workers, giving multiple
> workers (webapps) the same route. This could again be done in a
> template via a reference.
>
> - make sure, that you use the idle timeout mechanisms of the
> connection pools, because each webapp-lb will have it's own connection
> pool to the target Tomcat (and each connection needs a thread inside
> the target Tomcat). Look at
>
> http://tomcat.apache.org/connectors-doc/generic_howto/timeouts.html
>
> - If you use fail_on_status, you want to ensure, you are using version
> 1.2.25. fail_on_status is relatively new, and we had some fixes in the
> latest versions. At the moment, there is no known bug about it.
>
> - Unfortunately there's a bug with "reference" and debug log level for
> JK in 1.2.25 (the bug really only shows up with debug log level, but
> then the web server immediately crashes during startup). The fix is in
> trunk, but not yet released.
>
> It might be nice to think deeper about how to structure the objects
> around lb/workers on the one side, and mounts on the other side. At
> the moment we can only manage mounts or lbs or workers, but not an lb
> or worker in a mount.
>
> Regards,
>
> Rainer
>
> James Masson wrote:
>> Hi list,
>>
>> I have a fully working mod_jk High-Availability Tomcat environment at
>> the moment, and I'm looking to start catching web-app failures, as well
>> as Tomcat server failures.
>>
>> At the moment, the service looks like this:
>>
>> Two Alteon hardware load balancers
>> feeding
>> Two mod_jk apache servers
>> feeding
>> Four Tomcat 5.5 servers
>>
>> I have at least six applications running on each identical Tomcat
>> instance, with the incoming connections balanced equally between the
>> four Tomcat servers.
>>
>> The config is set up like this.
>>
>> worker.list=app1,app2,app3,app4,app5
>>
>> worker.tomcat1.port=8009
>> ...
>> worker.tomcat2.port=8009
>> ...
>> worker.tomcat3.port=8009
>> ...
>> worker.tomcat4.port=8009
>>
>> worker.app1.type=lb
>> worker.app1.balance_workers=tomcat1,tomcat2,tomcat3,tomcat4
>>
>> worker.app2.type=lb
>> worker.app2.balance_workers=tomcat1,tomcat2,tomcat3,tomcat4
>>
>> etc.
>>
>>
>> The applications themselves will return a 500-error if they encounter an
>> internal failure. I want to be able to detect this, and redirect around
>> the failing application instance.
>>
>> I'm aware I can do this for the tomcat server worker, but using the
>> fail_on_status directive will take an entire server out of the cluster.
>> Using fail_on_status , there's a possibility that one misbehaving
>> web-app can destroy the whole environment!
>>
>> Is there a way I can use mod_jk to redirect around a failed application
>> only, instead of taking out an entire server? Or am I misinterpreting
>> something?
>>
>> I think this is possible if I create an AJP worker for each web-app on
>> each server - but that config will be ridiculously complex, and I'll
>> likely have problems with jvmRoute variables, and such.
>>
>> Any ideas?
>>
>> thanks
>>
>> James Masson
>
> -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
> To start a new topic, e-mail: users@(protected)
> To unsubscribe, e-mail: users-unsubscribe@(protected)
> For additional commands, e-mail: users-help@(protected)
>
>
> __ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ______
> This e-mail has been scanned for viruses by MessageLabs.
**********************************************************************
Confidentiality : This e-mail and any attachments are intended for the
addressee only and may be confidential. If they come to you in error you must
take no action based on them, nor must you copy or show them to anyone. Please
advise the sender by replying to this e-mail immediately and then delete the
original from your computer.
Opinion : Any opinions expressed in this e-mail are entirely those of the
author and unless specifically stated to the contrary, are not necessarily
those of the author?s employer.
Security Warning : Internet e-mail is not necessarily a secure communications
medium and can be subject to data corruption. We advise that you consider this
fact when e-mailing us.
Viruses : We have taken steps to ensure that this e-mail and any attachments
are free from known viruses but in keeping with good computing practice, you
should ensure that they are virus free.
Inspired Gaming (UK) Limited
Registered in England No 3565640
Registered Office 3 The Maltings Wetmore Road, Burton On Trent, Staffordshire
DE14 1SE
__ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ _____
This message has been checked for all known viruses by the MessageLabs Virus
Control Centre.
-- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ------
To start a new topic, e-mail: users@(protected)
To unsubscribe, e-mail: users-unsubscribe@(protected)
For additional commands, e-mail: users-help@(protected)
|
|
