Fixed bug in max reconnection delay initialization.

[rgorodischer]

This change fixes the following bug in max reconnect delay initialization:

The 'maxDelay' parameter is used to be set in seconds (but if it was specified in milliseconds, the things would be even worser). Currently, it's transformed during initialization with TimeUnit.SECONDS.toMillis.
It means that the specified value is multiplied by 1000 in constructor.
And then it appears in this code snippet from method 'queueReconnect':

long delay = (long) Math.min(maxDelay, Math.pow(2,
node.getReconnectCount())) * 1000;
long reconnectTime = System.currentTimeMillis() + delay;

As you can see, it's multiplied by 1000 second time here, what is obviously causes 1000 times longer delay then the user expects.

[jhbae]

I think this should be milliseconds.

Because, in this commit, you just used f.getMaxReconnectDelay()
and as you may already know maxDelay is applied to calculate delay as follows.

long delay = (long) Math.min(maxDelay, Math.pow(2, node.getReconnectCount()) * 1000); long reconnectTime = System.currentTimeMillis() + delay;

As we can see above, delay will be just added to currentTimeMillis()
and the value 1000 is multiplied only to Math.pow(2, node.getReconnectCount()) not to maxDelay.

So I think it should be milliseconds as originally it was.

[caoziwen]

although maxDelay is in millisecond, maxDelay = TimeUnit.SECONDS.toMillis(f.getMaxReconnectDelay()); MaxReconnectDelay should be in second

[anand5au]

DefaultConnectionFactory javadoc also says the value should be in seconds.
https://github.com/couchbase/spymemcached/blob/master/src/main/java/net/spy/memcached/DefaultConnectionFactory.java#L108

[caoziwen]

I think it should be in second