Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a convenient way to make sure a SharedIndexInformer is done watching #4794

Closed
rdesgroppes opened this issue Jan 25, 2023 · 2 comments · Fixed by #4796
Closed

Add a convenient way to make sure a SharedIndexInformer is done watching #4794

rdesgroppes opened this issue Jan 25, 2023 · 2 comments · Fixed by #4796
Milestone

Comments

@rdesgroppes
Copy link

rdesgroppes commented Jan 25, 2023

Is your enhancement related to a problem? Please describe

Right now, the only way to make sure a SharedIndexInformer is done watching is by polling:

  boolean isWatching();

SharedIndexInformer exposes a way to get notified when a stop has been requested:

  CompletionStage<Void> stopped();

... but, as of version 6.4.0, the watch is likely to be still running after completion:

  public void stop() {
    stopFuture.complete(null);
[...]
    stopWatcher();
  }

Describe the solution you'd like

Either:

  1. make above stop blocking
  2. or call stopFuture.complete(null) from within:
  private synchronized void stopWatcher() {
    Optional.ofNullable(watchFuture).ifPresent(theFuture -> {
      watchFuture = null;
      theFuture.cancel(true);
      theFuture.whenComplete((w, t) -> {
        if (w != null) {
          stopWatch(w);
        }
      });
    });
  }
  1. or expose something like:
  CompletionStage<Void> doneWatching();

Describe alternatives you've considered

            while (informer.isWatching()) {
                LOGGER.warn("Informer still watching after shutdown...");
                // pause thread...
            }

Additional context

No response

@shawkins
Copy link
Contributor

the watch is likely to be still running after completion

Is the high-level issue that event processing continues after the stop call and the future is completed? Or just that you expect the websocket to be closed when the future completes? It would be straight-forward to ensure event processing has stopped by adding a check of the stopped future in ReflectorWatcher.eventReceived.

@rdesgroppes
Copy link
Author

rdesgroppes commented Jan 26, 2023

Is the high-level issue that event processing continues after the stop call and the future is completed? Or just that you expect the websocket to be closed when the future completes?

Actually both, as far I'm concerned.

shawkins added a commit to shawkins/kubernetes-client that referenced this issue Jan 26, 2023
manusa pushed a commit to shawkins/kubernetes-client that referenced this issue Feb 1, 2023
@manusa manusa added this to the 6.5.0 milestone Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants