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?
Regards,
Pavel
On 12/04/2017 00:32, Alessio Soldano wrote:
> Il 11/04/2017 18:28, Pavel Bucek ha scritto:
>> Hi Alessio,
>>
>> yes, they are.
>>
>> ScheduledExecutorService will be used for scheduling reconnects
>> (that's [2])
> mmh... are you planning to add some additional doc / example on this?
>
>> and provided executor service will be passed to RxInvokerProvider,
>> which is [1].
>>
>> I guess you refer to methods rx(ExecutorService) and rx(...,
>> ExecutorService) - they were removed, so there is no need to handle
>> "priorities". (We don't need them any more, since you can set
>> executor service in ClientBuilder).
> Ok, this is fine, I've implemented a prototype of this and it makes
> sense now, thanks.
>
> Cheers
> Alessio