-
Henri Gomez ___[_]____
EMAIL : [EMAIL PROTECTED] (. .)
PGP KEY : 697ECEDD ...oOOo..(_)..oOOo...
PGP Fingerprint : 9DF8 1EA8 ED53 2F39 DC9B 904A 364F 80E6
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>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' )
>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.
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 )
ok
>- 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 jkjni.so 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: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
