Hi David,

done ;)

It would be nice, if you could test SVN trunk. I also added some small documentation parts. The new attribute is called "jvm_route" and it also has been included into the status worker.

If you've never built mod_jk from the repository: there is no "configure" in the repository. You need to call buildconf.sh first, which uses autoconf to generate "configure" from "configure.in".

Cheers,

Rainer

[EMAIL PROTECTED] wrote:
Actually that's the other way my colleague and I came up with.  It seems a
little clumsier, but will work for us.

I'll see, what I can do ...
Thanks.  What kind of timeframe are we looking at?

cheers,

David



|---------+---------------------------->
|         |           Rainer Jung      |
|         |           <[EMAIL PROTECTED]|
|         |           >                |
|         |                            |
|         |           05/16/2006 02:34 |
|         |           PM               |
|         |           Please respond to|
|         |           "Tomcat          |
|         |           Developers List" |
|         |                            |
|---------+---------------------------->
  
>------------------------------------------------------------------------------------------------------------------------------|
  |                                                                             
                                                 |
  |       To:       Tomcat Developers List <dev@tomcat.apache.org>              
                                                 |
  |       cc:                                                                   
                                                 |
  |       Subject:  Re: JKStatus Bug?                                           
                                                 |
  
>------------------------------------------------------------------------------------------------------------------------------|



Hi David,

no internally it works like that: an lb worker has an internal
representation of the status of it's balanced workers. This is created
during initialization, so each lb worker has his own view of the
balanced workers. They don't share any information, like disable/stop,
error or usage counters/load (and that's something I want to keep).

The alternative approach I was thinking about is giving each (non-lb)
worker an optional attribute "jvmroute". The attribute is never used
except when the worker is being configured as a balanced worker for a
load balancer.

If a load balancer looks for the config of it's balanced workers, it
checks for the attribute "jvmroute". If it exists, it uses this name for
stickyness. If it does not exist, it uses the name of the worker.

The change is completely compatible with existing configs. In your case,
you would configure one worker pr tomcat target *and* per lb. Say you've
got TC1 and TC2 as tomcats and LB1 and LB2 as lbs. Then you configure 4
workers:

worker.lb1tc1.type=ajp13
worker.lb1tc1.host=HOST_OF_TC1
...
worker.lb1tc1.jvmroute=TC1
worker.lb1tc1.disabled=WHATEVER

... 2 further workers ...

worker.lb2tc2.type=ajp13
worker.lb2tc2.host=HOST_OF_TC1
...
worker.lb2tc2.jvmroute=TC2
worker.lb2tc2.disabled=WHATEVER

and two lb workers:

worker.lb1.type=lb
worker.lb1.balanced_workers=lb1tc1,lb1tc2

worker.lb2.type=lb
worker.lb2.balanced_workers=lb2tc1,lb2tc2

That way you can configure all attributes of the balanced workers per lb
and the implementation changes are far less risky. I'll see, what I can
do ...

Rainer

[EMAIL PROTECTED] wrote:
Hi Rainer,

Thanks for the reply.

As far as configuration change suggestions, how about making things more
fine-grained, so you can specify the worker within the balancer - eg:

    worker.adminloadbalancer.BLUFF.disabled=1

Presumably something like that is happening within jkstatus?

cheers,

David
x54680


|---------+---------------------------->
|         |           Rainer Jung      |
|         |           <[EMAIL PROTECTED]|
|         |           >                |
|         |                            |
|         |           05/16/2006 01:36 |
|         |           PM               |
|         |           Please respond to|
|         |           "Tomcat          |
|         |           Developers List" |
|         |                            |
|---------+---------------------------->

------------------------------------------------------------------------------------------------------------------------------|

  |
|
  |       To:       Tomcat Developers List <dev@tomcat.apache.org>
|
  |       cc:
|
  |       Subject:  Re: JKStatus Bug?
|
------------------------------------------------------------------------------------------------------------------------------|



Hi,

it's true, that jkstatus doesn't persist changes. There is no
functionality there to write a workers.properties (it's somewhere near
the end of the TODO).

Concerning disabled: Yes, disabled at the moment is an attribute
belonging to a worker and when using stickyness for any jvmRoute you can
only have one worker.

So if you want to use a worker in several balancers with different
enable/disable or start/stop values, the workers.properties gives you no
way to configure that.

Any ideas how such a configuration could look like? If the idea looks
good, i might implement :)

In case you only have further user questions, please proceed on
[EMAIL PROTECTED]

Concerning improvment of configuration syntax in workers.properties this
thread is right.

Regards,

Rainer

P.S.: local_worker and local_worker_only does no longer exist since some
thime before 1.2.15. The attributes are being ignored.

[EMAIL PROTECTED] wrote:
Hi,

We're using 3 load-balancers to seperate our requests up (client and
admin
etc.) and numerous tomcat servers (we're running Apache in front).

We need to be able to disable servers on a load-balancer level - so I
need
to disable 2 of the 3 load balancers on a particular server, say.  We
can
do this fine using the jkstatus page, but when the machines are
restarted,
the changes don't seem to have been persisted.

And it seems that workers.properties is not fine-grained enough to
handle
this?

Our setup is below...

Any ideas how to get around this?

cheers,

David


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to