Il 12/04/2017 08:42, Pavel Bucek ha scritto:
>
> Hello Allesio,
>
> I was not planning to do additional examples, but it can be done.
>
> The whole idea behind that is based on SseEventSource feature, see
> SseEventSource.Builder:
>
> /** * Set the initial reconnect delay to be used by the event source.
> * <p>* Note that this value may be later overridden by the SSE
> endpoint using either a {_at_code retry} SSE event field * or <tt>HTTP
> 503 + {_at_value javax.ws.rs.core.HttpHeaders#RETRY_AFTER}</tt>mechanism
> as described * in the {_at_link SseEventSource} javadoc. * * @param delay
> the default time to wait before attempting to recover from a
> connection loss. * @param unit time unit of the reconnect delay
> parameter. * @return updated event source builder instance. */ public
> abstract Builder reconnectingEvery(long delay, TimeUnit unit);
>
> To properly support that, we need to have a way how to schedule next
> reconnect, if not done immediately.
>
> The client runtime can use that pool to schedule internal tasks as
> well - it can server as a timeout keeper and other internal
> implementation related features/details.
>
> Does that sound resonable?
>
Yes, thanks.
Cheers
Alessio