tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "GOMEZ Henri" <>
Subject RE: Jk2: scoreboard format and semantics.
Date Mon, 22 Apr 2002 09:30:07 GMT

Henri Gomez                 ___[_]____
EMAIL :        (. .)                     
PGP KEY : 697ECEDD    ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6 

>-----Original Message-----
>From: []
>Sent: Friday, April 19, 2002 10:34 PM
>To: List Tomcat-Dev
>Subject: Jk2: scoreboard format and semantics.
>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' ) 
>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. 

Why not just use native read/write on int/strings ?

Do you think we should share these shared informations with 
others apps/modules ?

>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 )

ok, a tomcat started on another boxes, but that we want to add to
the list of known workers will be handled by jk_status/jk_control ?

>- an admin tool ( either C or an ant bean using the lib ) to
>register workers on different machines ( jk_status worker can 
>do that too ).

ok, so jk_status became jk_control or jk_admin in that case.
No more just a read-only task ?

>Comments ? Other ideas ? 

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message