[
https://issues.apache.org/jira/browse/KNOX-3058?focusedWorklogId=931143&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-931143
]
ASF GitHub Bot logged work on KNOX-3058:
----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Aug/24 13:06
Start Date: 21/Aug/24 13:06
Worklog Time Spent: 10m
Work Description: pzampino commented on code in PR #929:
URL: https://github.com/apache/knox/pull/929#discussion_r1725022591
##########
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:
I'm not convinced that the state should be part of the TopologyService. The
TopologyService has more to do with handling topology artifacts than actual
deployment/activation. It seems to me that the responsibility for
deployment/activation is handled by GatewayServer. I think managing this active
state in the TopologyService would broaden the window of time during which
clients would unnecessarily receive a 503 response where they would have
previously not received a 404 response. The 404 responses would not occur until
the app was actually deactivated.
Issue Time Tracking
-------------------
Worklog Id: (was: 931143)
Time Spent: 1h 10m (was: 1h)
> 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: 1h 10m
> 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)
