Synchronous watches

[bartebor]

As far as I understand Watch class code it works synchronously: it makes HTTP request to apiserver and only after receiving whole response it allows to iterate over received list of events.
This is not very useful; what we need is asynchronous mechanism allowing to receive events as soon as they are received.
I looked into WebSockets class which works in this manner, but it is quite low level and does not support event deserializing.
Do you plan to implement this?

[brendandburns]

That is not correct. Watch waits for complete JSON objects, but each event is a complete JSON object. You should receive them in real-time as they occur. Are you not seeing this?

[bartebor]

Thanks for your reply.
I did not receive objects in realtime as expected, I was just receving read timeout exceptions while waiting in Watch.createWatch().
It turned out that this bad behaviour is caused by enabled debugging (client.setDebugging(true)).
One can live without it, but we could state in documentation/examples that watches do not support debugging or have HttpLoggingInterceptor fixed to support this.

[brendandburns]

Thanks for the update. I'll see about fixing that.

[brendandburns]

Closing this since trying a watch with debugging turned on now prints a warning and throws.

[codefromthecrypt]

I will take a look at improving this, as I think I understand the issue. Basically, the default OkHttp interceptor is made for traditional request response. When we are using watches, the response has notable activity for each newline delimited chunk. So, it isn't that we don't want to see when the watch times out, it is that we also want to see progressive output meanwhile, for each entry in the response body.

[codefromthecrypt]

HttpLoggingInterceptor buffers the response body, not because there's no way to stream it, but because it is deemed out of scope for a development filter. I verified this remains the case in the emerging OkHttp 5, and personally agree with the default.

Also, as warned by @swankjesse, streaming events will result in interleaved bodies in logs. It is possible that watches are pinned to threads or coming from a narrow set of classes. This could mean some callers already have a way of disambiguating, but YMMV. In any case, this is an opt-in and we may want to warn in javadoc about this.

So, if we want to progress this, there are at least three ways out of this, and all would need the same consciousness about interleaved watch updates in logs.

1. cheap way: special case logging at Watch.next(), so that it is easy to see the raw event. Leave everything else alone.
2. keep the "debugging" mode http-only. Make our own HttpLoggingInterceptor which special cases our streaming protocol, basically newline based flushing to a log line.
3. change "debugging" mode to be a higher abstraction than HTTP and trace differently with normal logging.

For now, I'm going to set this down. Personally I might patch watch.next for sanity so I can see what the updates look like when I'm troubleshooting. If anyone wants a hand with anything like this let me know, or if you prefer to do the fun stuff and want a reviewer, you can ping me also!

[codefromthecrypt]

I raised something like option 1 #3121