[
https://issues.apache.org/jira/browse/KNOX-3058?focusedWorklogId=931147&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-931147
]
ASF GitHub Bot logged work on KNOX-3058:
----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Aug/24 13:17
Start Date: 21/Aug/24 13:17
Worklog Time Spent: 10m
Work Description: pzampino commented on code in PR #929:
URL: https://github.com/apache/knox/pull/929#discussion_r1725038551
##########
gateway-server/src/main/java/org/apache/knox/gateway/GatewayServer.java:
##########
@@ -962,10 +985,32 @@ private void processApplicationPathAliases(File warDir,
Topology topology) {
});
}
+ private void addInactiveTopology(final String topologyName) {
+ synchronized (inactiveTopologies) {
+ inactiveTopologies.add(topologyName);
+ }
+ }
+
+ private void removeInactiveTopology(final String topologyName) {
+ synchronized (inactiveTopologies) {
+ inactiveTopologies.remove(topologyName);
+ }
+ }
+
+ private boolean isInactiveTopology(final String topologyName) {
+ boolean result = false;
+ synchronized (inactiveTopologies) {
+ result = inactiveTopologies.contains(topologyName);
+ }
+ return result;
+ }
+
private synchronized void internalDeactivateTopology( Topology topology ) {
Review Comment:
Concerning the point about initial deployments, we could/should immediately
mark topologies as inactive on deployment initiation, and then mark them as
active upon completion. I believe this would further minimize the potential for
clients to receive a 404 response for a "deployed" topology.
Issue Time Tracking
-------------------
Worklog Id: (was: 931147)
Time Spent: 1.5h (was: 1h 20m)
> Avoid 404 When Topology Is Being Redeployed
> -------------------------------------------
>
> Key: KNOX-3058
> URL: https://issues.apache.org/jira/browse/KNOX-3058
> Project: Apache Knox
> Issue Type: Improvement
> Components: Server
> Reporter: Philip Zampino
> Assignee: Philip Zampino
> Priority: Major
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> While a topology is being redeployed, if it is requested, the client receives
> an HTTP 404 response. Most clients will not retry when receiving a 404, so
> the interaction will fail.
> If Knox were to respond with a more retry-friendly response (e.g., HTTP 503),
> then clients could overcome these small windows of unavailability with
> retries.
> The difficult part may be distinguishing topology removal from topology
> inactivity. I think a deleted topology should still result in a 404.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
