There is fixed the issue of reconnection. autoConnectMs was changed…

[vnabiev]

… by ReconnectionPolicy.

WsProvider couldn't reconnect to the web socket if it was closed - future whenConnected wasn't being completed when socket closes that blocked reconnection.

[kalaninja]

Suggested change

	// nothing to reset

[kalaninja]

Since there might be different policies for different reasons, the name might become confusing. What do you think about reconnectWith()?

[vnabiev]

I don't see any problem. I think in that case it might be achieved by using overloads. Your proposal is also ok for me.

[kalaninja]

Backoff doesn't tell me anything about the algorithm being used. How about ExponentialReconnectionPolicy?

[vnabiev]

The policy allows to use a constant time backoff also that's why I called it like this. I think "exponential backoff" is more common name so will rename to ExponentialBackoffPolicy or ExponentialBackoffReconnectionPolicy.

[kalaninja]

As far as I can see negatives and numbers less than one are allowed, which might result in a tricky behavior. Is it intentional?

[vnabiev]

Negatives are not allowed there. I left an opportunity to use numbers less than one intentionally, but probably it doesn't make much sense.

[kalaninja]

I don't see the context being used anywhere. Also probably the policy should be affected by the reason of disconnection.

[vnabiev]

Sorry, I didn't get your point.

[kalaninja]

I think this method implies that the policy is stateful. I can suggest doing it a little different. The policy holds an algorithm, which generates a schedule providing you with next timeslots. If you need to reset you just generate a new schedule.

public interface ReconnectionPolicy {
    interface ReconnectionSchedule {
        long getNextDelay();
        TimeUnit getTimeUnit();
    }

    ReconnectionSchedule getSchedule();
}

[kalaninja]

Also, it probably might be better if a consumer can tell the schedule which time units it wants to see the results in instead of being made to use time units predefined by the author of the policy.
long getNextDelay(TimeUnit timeUnit)

[vnabiev]

Thank you for these suggestions!
With regard to the proposal to use long getNextDelay(TimeUnit timeUnit), in general it won't work. E.g., let's assume somebody sets delay as "30 seconds", but a consumer of the policy requests in minutes so they would get "0 minutes" instead of the correct value. I would use the class Duration, however it's not convenient for scheduling. I agree that to have a stateless policy is more preferable, but the suggested solution is not so flexible, e.g. for decorating the policy. I decided to change the signature a little. A policy initializes and provides a required context (the method is requested before the first connection or when connection reestablished), which will be passed to the one after every failure.