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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>