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