How does the change tracking mechanism work? about winton.extensions.configuration.consul HOT 4 CLOSED

Hi @muratyuceer. That's a good question, but I believe the behaviour is correct. Consul supports long polling in order for consumers to detect changes. As described in that link, long polling works by sending in a blocking query that waits for either the value to change or PollWaitTime to be exceed, at which point it will return to the client immediately and the client must then determine whether it was a timeout or an actual update.

So you should always see changes reflected immediately (minus any network latency). PollWaitTime instead sets how long the request is allowed to "hang" for on the Consul side before it times out. Setting this low would cause a lot of network requests and re-connections between client and server. The maximum value is 10 minutes as if we left it unbounded Consul would never know when to evict unresponsive clients.

I hope that clears things up. Maybe the parameter would have been better named MaxPollWaitTime.

from winton.extensions.configuration.consul.

So the technique it uses is called long polling, here is a description.

TLDR; client (your code running this library) makes a HTTP request and the server keeps that connection alive until either the value changes or the wait time is reached. So if the value never changes it will make a new HTTP request every PollWaitTime seconds otherwise it will make a new HTTP request each time the value is updated.

from winton.extensions.configuration.consul.

I didn't know about this interesting method, thank you for the information.

from winton.extensions.configuration.consul.

Hi @muratyuceer. That's a good question, but I believe the behaviour is correct. Consul supports long polling in order for consumers to detect changes. As described in that link, long polling works by sending in a blocking query that waits for either the value to change or PollWaitTime to be exceed, at which point it will return to the client immediately and the client must then determine whether it was a timeout or an actual update.

So you should always see changes reflected immediately (minus any network latency). PollWaitTime instead sets how long the request is allowed to "hang" for on the Consul side before it times out. Setting this low would cause a lot of network requests and re-connections between client and server. The maximum value is 10 minutes as if we left it unbounded Consul would never know when to evict unresponsive clients.

I hope that clears things up. Maybe the parameter would have been better named MaxPollWaitTime.

Thank you for the response, what I'm really curious about is how changes made in Consul are instantly reflected in the application... does it open a connection like a WebSocket in the background? It's probably not sending http requests every second, is it?

from winton.extensions.configuration.consul.