[
https://issues.apache.org/jira/browse/KNOX-3041?focusedWorklogId=1031906&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031906
]
ASF GitHub Bot logged work on KNOX-3041:
----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jul/26 17:21
Start Date: 23/Jul/26 17:21
Worklog Time Spent: 10m
Work Description: hanicz merged PR #1317:
URL: https://github.com/apache/knox/pull/1317
Issue Time Tracking
-------------------
Worklog Id: (was: 1031906)
Time Spent: 0.5h (was: 20m)
> Load Balancer backend selection synchronization issue
> -----------------------------------------------------
>
> Key: KNOX-3041
> URL: https://issues.apache.org/jira/browse/KNOX-3041
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Affects Versions: 2.1.0
> Reporter: Istvan Toth
> Assignee: Tamás Hanicz
> Priority: Major
> Fix For: 3.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> I was trying to run a benchmark over Knox, with several Http client instances
> started at the same time on separate threads.
> I found that every single client was directed to the same backend, which was
> saved in the session, so instead of accessing each backend, every request was
> directed to a single one.
> While this was a benchmark/load test tool, any non-interactive client can
> exhibit similar behaviour, defating the point of load balancing.
> Looking at
> org.apache.knox.gateway.ha.dispatch.ConfigurableHADispatch.executeRequestWrapper(HttpUriRequest,
> HttpServletRequest, HttpServletResponse)
> , I think that the sitation could be improved by calling
> haProvider.makeNextActiveURLAvailable BEFORE the request is executed.
> It would be still racy, but the race window would be dramatically smaller,
> running some simple local code, which should be on the microsecond scale,
> instead of performing a full HTTP reqest, which is on on the millisecond
> scale at best.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
