Transparently handle session terminations during long-polling between Proxy and Broker

[TKussel]

If the long-polling of tasks or results is disrupted by session terminations (e.g. caused by latency spikes), the proxy client is not informed of that connection loss. An alternative, transparent long-polling mechanism could look like the following:

The long polling wait_time is set as a maximum wait time. If no wait_time is given, a sensible default cap is chosen (e.g. 1 minute). The proxy chooses a lower wait time for repeated long-polls to the broker, up to the chosen maximum time. The timeout for that connection is chosen using a learning mechanism analyzing previous requests (and optionally an echo endpoint in the broker) and converging to an optimal time.

In case of a fast, unimpeded connection, the result is returned – as expected by the application – as fast as it is available in the broker or at least partially after wait_count. In case of a broken session, the connection is transparently reinitialized by the proxy.

[lablans]

Check if this is still required with the SSE interface #105