That's a difficult and critical issue. The scoreboard is needed to allow the loadbalancing to react to changes in the workers. It is also help with runtime configuration of jk in multi-process servers.
The problem is obviously how to implement it without mutexes ( or with minimal use of interprocess synchronization ). The first proposal is based on the model used by Apache and jserv. 1. Each worker will get it's own 'slot'. Each slot and the jk_shm_head will get a 'version' ( or 'serial' ) field. 2. Whenever a worker ( tomcat ) is created, we create a slot - this operation requires inter-process locking ( for the unlikely but possible case 2 tomcat instances will start at the same time ). 3. Any change in the slots will result in incrementing ( or just changing ) the version in the slot and in the head. 4. jk_worker_lb will just monitor the int field in the head. If a change is detected ( from the previous value ) - it'll walk all fields and update the worker map. The same process could work for doing updates in the uriMap and other config changes - but later. My current understanding is that this model will does not require extra synchronization or even atomic operations on read ( i.e. in the critical path ). Even if we read the version while changing - what we care is if the value is different from the last one we read. ( atomic operations are usually expensive - and not trivial on MP systems ). The creation or change in slots will require synchronization. The 'bad' thing that can happen is a process reading the slot while we change it. My initial thinking was that we could have a 'changing' field in the slot - but I don't think we can have guarantee of the order of the writes. But a simple CRC of the data would work - the reader will copy the slot, then do a CRC. If it doesn't match, it'll either keep the old data or try again. The information in the slot will include the worker id ( used in the 'session id' or jvmRoute ), information about the channels it supports ( host:port, unix domain, etc ), state. To keep things simple and use existing code, I think we should use the current marshalling/demarshalling code ( ajp13 ) to store/get informations from each slot. To keep things simple, we should start with fixed-size slots. The shm scoreboard will be updated by: - the lb worker ( when it detects that a worker is down ) - a tomcat process when it starts and auto-register itself ( including the case of Apache multi-process where VMs are created with each process ) - an admin tool ( either C or an ant bean using the jkjni.so lib ) to register workers on different machines ( jk_status worker can do that too ). Comments ? Other ideas ? Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
