> Another solution would be to calculate some sort > of checksum on each session id received for a vm that is > no longer on the air. Then modulo that number by the number of > available tc instances in the cluster, and route the request to the > the jth server in the cluster (where j is the calculated modulo). > This would spread the load without requiring anyone to start > maintaining copious session routing tables. I don't know what > you'd do if the number of available tc's changes.
You implicitly make the assumption that in a setup with several frontend Apache servers they all use the same workers and that there is an order relationship between those. Choosing the jth worker only makes sense if the workers are in the same order on all mod_jk configs. You could very well have a setup where a load balancing equipment first routes a request according to a client ip for example to a given Apache server, being in a 'GOLD' customer all my requests are forwarded to a fast Apache with fast workers. Now if I am a 'COPPER' customer my requests will be routed to the slower Apache server using slower workers. The 'GOLD' setup has fail-over, that is the slow workers can handle the requests coming from the 'GOLD' Apache but 'COPPER' clients get no fail-over. The modulo trick is really tricky in such a setup. > Another solution would be to send a cookie back to the > client that contains the new jvmrouting info. But, that only > works for clients that allow cookies. If the webapp uses URL rewriting where needed, the new value containing the new jvmroute can very well be included where it belongs (in all encoded URLs). The problem I see can arise is the atomicity of the setting of the new value. Somehow we need a 'lock' in the cluster of workers so that the first one to receive old session ID S1 will turn it into S2 and all subsequent requests for S1 will also turn it into S2, even if one of those requests is dispatched to a worker which would, if it had received the first request with S1, have turned it into S3. The mapping S1->S2 should be kept for the life of the session, so are possible further mappings, S1->S3 and/or S2->S'3, etc, should further workers fail. Mathias. > Another solution would be to choose a new 'owner', and > store this mapping (of session id to owner vm) in a hashtable. > Then, in subsequent requests, do a hashtable lookup to find > the owner vm. Solutions that require a large routing table > are probably not desirable, but would probably result in the > greatest flexibility. Yep, sort of what I talked about in my previous paragraph, but I would see this mapping stored among the workers, not in Apache modules. > Tom Drake Mathias. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
