[
https://issues.apache.org/jira/browse/KNOX-3058?focusedWorklogId=931032&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-931032
]
ASF GitHub Bot logged work on KNOX-3058:
----------------------------------------
Author: ASF GitHub Bot
Created on: 20/Aug/24 22:05
Start Date: 20/Aug/24 22:05
Worklog Time Spent: 10m
Work Description: lmccay commented on code in PR #929:
URL: https://github.com/apache/knox/pull/929#discussion_r1724026595
##########
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:
Does this get called for the first deployment on the initial start as well?
When does it get marked as active again? Does it incorporate discovery at
all?
Should this be done outside of the TopologyService? Seems like state that
should be managed by that service maybe.
Issue Time Tracking
-------------------
Worklog Id: (was: 931032)
Time Spent: 20m (was: 10m)
> 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: 20m
> 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)
