-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Allow watching resources over HTTP if watching using websocket fails #652
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
Conversation
8ac44d0
to
bf34108
Compare
bf34108
to
00b78c7
Compare
Will fix tests shortly. |
ok to test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we get a test in for this too? @iocanel Thoughts on using the mock test server for this?
return watch; | ||
} catch (MalformedURLException e) { | ||
throw KubernetesClientException.launderThrowable(e); | ||
} catch (KubernetesClientException ke) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we check the type of the exception? For example, there would be no point in falling back to HTTP watch in e.g. auth error. Perhaps we should only fall back if we receive a 200 instead of a 101 for example?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, added a check for ke.getCode()
to be 200.
} catch (KubernetesClientException ke) { | ||
WatchHTTPManager watch = null; | ||
try { | ||
watch = new WatchHTTPManager( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Simply return new WatchHTTP....
response = clonedClient.newCall(request).execute(); | ||
BufferedSource source = response.body().source(); | ||
while (!source.exhausted()) { | ||
String message = source.readUtf8LineStrict(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is each event new line separated then? Not chunked response? I haven't looked to be sure but will trust you :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, the chunk size is sent at first, but does not correspond to the event boundaries. The newlines are reliable separators.
Thanks for this PR. It's looking good, I like the approach, just some minor questions and we need a test too if possible. |
Oh and this breaks some tests too - see build logs please. |
af183ee
to
9262d47
Compare
9262d47
to
edd59d5
Compare
@jimmidyson @iocanel PTAL. Addressed comments, added tests. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for the tests!
When I try this locally, I get a 5 second delay between 200 response from websocket watcher request and the HTTP watcher kicking in:
Any ideas why? |
[merge] |
@iocanel I was waiting for feedback on #652 (comment)... |
@jimmidyson: you've approved the request though. |
I aborted the job on jenkins until you get feedback. |
@iocanel That is a good point. I had approved the code review, but was testing locally before merging. I will ensure from now on that review approval means a complete yes, not just code review approval. Sorry for the misunderstanding! |
Thanks for the quick review. A 5 second delay seems quite substantial, and I don't remember running into this. I'll look into it shortly. |
@foxish Yeah it was unexpected, it could be environmental but I'm not sure how. Let me know if you have any ideas. |
@jimmidyson It seems like the websocket call takes ~5 seconds to fail. The delay comes from the |
OK so sounds like we need to address the websocket timeout separately. Getting back a 200 should prevent the websocket from trying to connect and immediately return. @foxish Would you have time to look at that fix? I'm happy to merge this in & get a fix in for that in a separate PR. |
That sounds good. I'll send a follow-up PR for the fix. Would cutting a release be possible sometime early next week? We'd like to use these changes in our Spark integration efforts. |
We can do the release as soon as we have the fix for the delay. |
[merge] thanks @foxish! |
Falling back to using persistent HTTP Get.
The code could be DRYer. Getting this out there to get some initial opinions.
@iocanel @jimmidyson @iyanuobidele