jk2: reconfig ( again )

[co...@covalent.net]

I'm starting to have doubts about the current shm-based 
reconfiguration of workers.

The solution is inspired from jserv - the scoreboard stores
that status of each worker, when an apache instance detects
 the worker is down it'll update the shmem and everyone will
know about this.

That works fine in jk2 - in addition you can add workers,
enable/disable workers from CLI.

There are few problems:
- the original attempt was to use JNI to allow java to
configure that. There are numerous problems with that - 
especially on JDK1.4. 

- the model is hard to extend - I would like to be able to
reconfig all components, not only workers.

- if we use NIO to modify the config, we run into byte ordering
issues. As a solution I used AJP-encoding for the shmem segments,
but that's making the code more complex than it should be.

- one of my goals was to abstract the config - and possibly allow
a pluggable config source. The shm will make this more difficult.

There is one other system that uses a similar aproach - 
Ksycoca, the new KDE configuration system. In this case, all
text-based configs are read and a binary file is generated, with
each process using the binary file. But even there, the config
changes are made to the (ini) config files. 


If we don't find a better idea, I would like to roll back the 
worker config and use a simpler aproach:

1. All config changes are made to the original config source
( curently workers2.properties file )

2. For each change, you must increment the 'ver' attribute
of the changed object. ( or use a timestamp ). A config tool
can easily automate this, but it's not very difficult for
manual config.

3. We need a way to 'signal' that the config changed. 
We still need shm because we have multiple processes and all
should get the information at the same time, and with minimal
overhead. But only one int field must be modified, and we have
more choices:
- NIO/JNI with a java program.
- a simple C program that just increment the shm location
- jkstatus can check the file timestamp ( so after 
editing the file you would access /jkstatus ). Or use a 
dedicated worker.
- we can check the timestamp periodically.

Besides rolling back the current solution, we only need some
enhancements in jk_config to get this working. 

Any better idea ? 

Costin



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>