bigdata4u / spymemcached

Automatically exported from code.google.com/p/spymemcached
0 stars 0 forks source link

Incorrect delay logic in MemcachedConnection#queueReconnect(MemcachedNode) method #85

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago

Currently, the delay calculation in the queueReconnect method looks like 
this:
long delay=Math.min((100*qa.getReconnectCount()) ^ 2, MAX_DELAY);

The "^" is a XOR bitwise operation instead of Math.pow(...) if that was what 
you were thinking about.

http://github.com/dustin/java-memcached-
client/blob/5ca04897525922d1f200b44f57e5edfdc4b324ed/src/main/java/net/spy/m
emcached/MemcachedConnection.java#L420

Original issue reported on code.google.com by greg...@gmail.com on 25 Aug 2009 at 12:43

GoogleCodeExporter commented 8 years ago
This is one suggestion for the change:
  long delay = (long) (Math.pow(8, qa.getReconnectCount()) * Math.random())

Original comment by greg...@gmail.com on 25 Aug 2009 at 4:32

GoogleCodeExporter commented 8 years ago
I plotted a few and I kind of like:

    // ^ means pow here, 1000 converts it to millis

    y = min(30, 2^x) * 1000

This curve doesn't seem too step, but does terminate at 30s.

Original comment by dsalli...@gmail.com on 6 Sep 2009 at 7:37

GoogleCodeExporter commented 8 years ago
sounds good, the only thing w/ this is that once you've reached reconnect count 
greater than 4 -- it's becomes a constant 30sec until the node returns back to 
life.  

it'll be great if MAX_DELAY was configurable.  

Original comment by greg...@gmail.com on 7 Sep 2009 at 4:48

GoogleCodeExporter commented 8 years ago
Great.  I just committed the new formula and a configurable max delay.  I think 
I'll
finalize 2.4 with this stuff.

Original comment by dsalli...@gmail.com on 13 Oct 2009 at 8:45