[jboss-jira] [JBoss JIRA] (WFLY-10081) mod_cluster Proxy: Deterministic failover algorithm discrepancy between undertow and httpd

[Radoslav Husar (JIRA)]

     [ https://issues.jboss.org/browse/WFLY-10081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar moved JBEAP-8965 to WFLY-10081:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-10081  (was: JBEAP-8965)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: mod_cluster
                           (was: Web (Undertow))
       Target Release:   (was: 7.backlog.GA)
    Affects Version/s: 12.0.0.Final
                           (was: 7.1.0.DR12)


> 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-b0880ea8cdee300885bd1c5ae7f4cebbR2333]
> {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/java/io/undertow/server/handlers/proxy/mod_cluster/ModClusterContainer.java#L430]:
> {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/share/classes/java/lang/String.java#l1452]:
> {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?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)