[
https://issues.apache.org/jira/browse/KNOX-3058?focusedWorklogId=931033&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-931033
]
ASF GitHub Bot logged work on KNOX-3058:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Aug/24 22:13
Start Date: 20/Aug/24 22:13
Worklog Time Spent: 10m
Work Description: pzampino commented on code in PR #929:
URL: https://github.com/apache/knox/pull/929#discussion_r1724039838
##########
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:
Automated testing will be tricky given the small window of time when this is
an issue. I'm open to suggestions though.
When you ask "Does this get called for the first deployment...", what is
"this"? On first deployment, there had not been any opportunity for it to have
been marked as inactive, so I think the answer is "no".
The topology gets marked active upon activation (see
internalActivateTopology method). This is not connected to discovery because
we're dealing directly with topologies here. Discovery will have happened prior
to this, and the undeployment won't happen until the new version of the
topology is written out.
I thought about that, but
1. The source of the 404 responses is Jetty, so overriding them seems
appropriate to do with Jetty facilities.
2. It seems best to do it as close to the activation/deactivation logic as
possible.
Issue Time Tracking
-------------------
Worklog Id: (was: 931033)
Time Spent: 0.5h (was: 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: 0.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)
