mod_cluster Proxy: Deterministic failover algorithm discrepancy between undertow and httpd ------------------------------------------------------------------------------------------ Key: WFLY-10081 URL: https://issues.jboss.org/browse/WFLY-10081 Project: WildFly Issue Type: Bug Components: mod_cluster Affects Versions: 12.0.0.Final Reporter: Michal Karm Babacek Assignee: Radoslav Husar Labels: mod_cluster Deterministic failover as first implemented in Apache HTTP Server's mod_cluster module [MODCLUSTER-550] does a simple sequence of steps to pick a worker: * it gathers a list of valid candidates * it uses the currently handled session id string to calculate an integer value * it uses this integer value to do modulo to the number of valid candidates * result is an index to the list of valid candidates Both Apache HTTP Server and Undertow implementations stick to this algorithm. The discrepancy lies in calculating the integer value from session id string. h3. Apache HTTP Server mod_cluster implementation Simply adds up ordinals, [source|https://github.com/modcluster/mod_proxy_cluster/pull/8/files#diff-...] {code} int hash = 0; ... for (i = 0; session_id[i] != 0; ++i) { hash += session_id[i]; } mycandidate = workers[hash % workers_length]; {code} h3. Undertow mod_cluster proxy implementation For some unknown reason (to me), this implementation leverages Java's String hashCode method, {{sessionId.hashCode()}}, [source|https://github.com/undertow-io/undertow/blob/1.4.x/core/src/main/j...]: {code} int index = (int) (Math.abs((long) sessionId.hashCode()) % candidates.size()); Collections.sort(candidates); String electedRoute = candidates.get(index); {code}, you see, the hashCode on String does more than counting ordinals, it multiplies with a prime number, [source|http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/sha...]: {code} for (int i = 0; i < value.length; i++) { h = 31 * h + val[i]; } {code} h3. Call to action I would like to either to see the argumentation on why it is OK for these two implementations to be deterministically picking different workers, or I would like to have these implementations aligned. I don't have a preference as to whether C implementation should be altered after the Java one or vise versa. My only preference is that they must yield the same results unless there is a very good reason not to. WDYT?