mod_cluster Proxy: Deterministic failover algorithm discrepancy between undertow and httpd

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.

Apache HTTP Server mod_cluster implementation

Simply adds up ordinals, source

int hash = 0;
...
for (i = 0; session_id[i] != 0; ++i) {
    hash += session_id[i];
}
mycandidate = workers[hash % workers_length];

Undertow mod_cluster proxy implementation

For some unknown reason (to me), this implementation leverages Java's String hashCode method, sessionId.hashCode(), source:

int index = (int) (Math.abs((long) sessionId.hashCode()) % candidates.size());
Collections.sort(candidates);
String electedRoute = candidates.get(index);

,
you see, the hashCode on String does more than counting ordinals, it multiplies with a prime number, source:

for (int i = 0; i < value.length; i++) {
    h = 31 * h + val[i];
}

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?