Long polling

[ahavriluk]

Hi!

We are implementing a bundle server with long polling.
In OPA we have this parameter: 'bundles[_].polling.long_polling_timeout_seconds'.
By looking in the OPA code we have learned that having that parameter != nil enables long poling and the parameter itself is sent in the prefer header. For example: prefer:"modes=snapshot,delta;wait=15".

Is it used by OPA for anything else? (We couldn't determine any effect of it on OPA long poling functionality).

What does the bundle server suppose to do with that parameter? Is it a timeout for a bundle server to send 304 response back if no new version of bundle is available?

Thank you!

[ashutosh-narkar]

What does the bundle server suppose to do with that parameter?

When OPA sends a long poll request to the server, it defers its response until an update is available or timeout has occurred. In case of a timeout, the server responds with a 304 Not Modified response. More info here.

[ahavriluk]

Thank you for replying, I have read the documentation. It is not clear to me what time out we are talking about here in case of long polling. OPA never times out and can wait for a differed response from OPA bundle forever and the long_polling_timeout_seconds value doesn't affect it.

[ashutosh-narkar]

The timeout refers to the max time server has to send a response to OPA. If long polling is enabled the ResponseHeaderTimeout on the client transport is cleared.

[ahavriluk]

If long polling is enabled the ResponseHeaderTimeout on the client transport is cleared.
Yes, obviously.

Here is my understanding of long poling protocol, correct me if I am wrong:

1. OPA sends a request to OPA bundle server with prefer header: prefer:"modes=snapshot,delta;wait=<long_polling_timeout_seconds>"
2. The bundle server has to parse the prefer header and pull the wait time. It suppose to wait up the wait parameter value amount of time before either sending a new bundle or 304 response. The reason we have to send 304 response periodically is because the network players in the middle between OPA bundle server and OPA may timeout the connection. More details here: Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP
3. If OPA receives a new bundle it applies it and sends a new request. If 304 is received the OPA updates the headers in the cached response with their corresponding values from the 304 (Not Modified) response (whatever that means).

[ashutosh-narkar]

This is correct. On 3, OPA will periodically reach out.

It suppose to wait up the wait parameter value amount of time before either sending a new bundle or 304 response.

I think if the server can respond before the wait time if it has an update available.

[ahavriluk]

I think if the server can respond before the wait time if it has an update available.
yes. I didn't describe it correctly.
Thank you for your help!