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.

Sign up for GitHub

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

Jump to bottom

fix #4884: using different threads for watch events #4900

Merged
merged 1 commit into from
Mar 2, 2023
Merged

fix #4884: using different threads for watch events #4900

merged 1 commit into from
Mar 2, 2023

Conversation

shawkins
Copy link
Contributor

@shawkins shawkins commented Feb 22, 2023 •
edited by manusa
Loading

Description

Fix #4884

This addresses #4884 for watch events. After looking over the ResourceEventHandler logic again, I remembered why this wasn't done initially - for most Informer processing this will introduce an extra / unnecessary thread hop. Removing the Informer SerialExecutor however is not possible, because there is still the resync to contend with and the list processing is handled in completion events that may be on the main or http client thread.

Similarly for any users that have taken responsibility for threading concerns, this wrapping will also be unnecessary.

Also the wrapping is (mostly) unnecessary for okhttp as it uses a thread per websocket - but does also use that thread to handle the ping/pong.

Alternatives to always wrapping would include using a Watcher method or annotation to declare whether async handling is needed, or a method like KubernetesClient.asyncWatcher(Watcher) that returns a wrapped Watcher.

@manusa @rohanKanojia do you want to make this behavior explicit or always make Watch handling async?

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • Feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change
  • Chore (non-breaking change which doesn't affect codebase;
    test, version modification, documentation, etc.)

Checklist

  • Code contributed by me aligns with current project license: Apache 2.0
  • I Added CHANGELOG entry regarding this change
  • I have implemented unit tests to cover my changes
  • I have added/updated the javadocs and other documentation accordingly
  • No new bugs, code smells, etc. in SonarCloud report
  • I tested my code in Kubernetes
  • I tested my code in OpenShift

@rohanKanojia
Copy link
Member

@shawkins : Sorry for the naive question, How is this PR related to #4802?

@shawkins shawkins changed the title fix #4802: using different threads for watch events fix #4884: using different threads for watch events Feb 28, 2023
@shawkins
Copy link
Contributor Author

@shawkins : Sorry for the naive question, How is this PR related to #4802?

Sorry, didn't realize I had linked to the wrong issue. Should be #4884

@sonarqubecloud
Copy link

sonarqubecloud bot commented Mar 2, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

96.0% 96.0% Coverage
0.0% 0.0% Duplication

@manusa manusa added this to the 6.5.0 milestone Mar 2, 2023
@manusa manusa merged commit dfa920e into fabric8io:master Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@manusa manusa manusa approved these changes

@rohanKanojia rohanKanojia rohanKanojia approved these changes

@oscerd oscerd Awaiting requested review from oscerd

@sunix sunix Awaiting requested review from sunix

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
6.5.0
Development

Successfully merging this pull request may close these issues.

WatchIT fails with vertx
3 participants
@shawkins @rohanKanojia @manusa