Just wanted to note the problems we have with shared memory ...
Currently we presume that 'someone' will initialize the shared memory and setup all struct data before the first request. This is wrong presumption, cause shared memory on IIS is initialized on first request, and with multiple workers processes kicking on during burst load, that's a disaster. Solution (as I see it) 1. Instead linear alloc use key based slot memory. This will waste few bytes for some workers cause each allocation slot would need to be of the same size. (maximum size of any one structure, probably deducted manually) 2. On 'pull' always search by object name (calculate ID for speed) This means that pull will alloc object in shared memory if it doesn't exists This solves both reconfig and recycle 3. Make sure we push/pull only on config parameter change. Runtime params like lb_factors should depend on volatile. 4. Update sequence in shared memory only from jkstatus or from worker.properties reload. Ensure we pull only if behind shared memory sequence. The major design problem is how to calculate unique shared memory object ID. Think we can have multiple objects with the same name, so beside name we need type I suppose and then if we can have multiple name-type objects (eg. workers having the same name under different balancers) add something to that as well. Push/pull will go trough each slot in shared memory and seek for exact object. I know, not as performant, but we could add slot_id once resolved. In essence this would mean that shm_pull and shm_alloc will be one function and actual shared memory slot will be allocated on first use (for all web servers) Comments? Regards -- ^TM --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
