twitter
retrying in storehaus should be a little more configurable
The recent addition of retry-able stores was nice but I think the way a client wants to retry should be a little more configurable.
Some interfaces where retry apis shine are
- twitter util zoo keeper's retry policy
- dispatch reboot's retries
I talked to @n8han, the author of dispatch, about extracting his interface which seems to be the most generic and he said it'd be cool. I hate to see this kind of thing be reinvented in multiple contexts so I created a standalone retry library based on the one in reboot.
The problems I face now are
-
the retry lib is based on scala's future interface, only available in 2.9.3 and 2.10+. Storehaus is published for 2.9.2 and 2.10 which means if I wanted to adapt this interface to storehaus I could only do it in modules published for 2.10.
-
The retry lib works with scala futures while storehaus is based on twttr futures. Scala's interface looks like it stole a lot from twitter so a bijection between the two should
hopefullybe the fix but I'd had to figure out a good way of handling the 2.9.2 case. -
The retry lib needs to emulate sleeping asynchronously to simulate a
pausebetween retries. Dispatch reboot uses netty's hashwheel timer to put a block of code on a timer. Twitter defines its own Timer interface. ( The zookeeper lib uses this ). In order to integrate a generic retry lib, a common retry interface would be required. This should not be hard. Potentially something like this should suffice. -
Is storehaus open to non-twitter published dependencies? Since the retry library is outside the twitter lib lifecycle it could go in its own module storehaus. I publish everything to maven central so resolving should not be an issue.
In response to 4, we generally are but in the case of reboot's retries, I'd like to avoid the LGPL dependency. https://github.com/dispatch/reboot/blob/master/LICENSE.txt
wouldn't be an issue. I plan on making retry a standalone lib using MIT then contributing a patch back to dispatch that depends on this.
We've been making a push to upgrade to 2.10 internally -- I'm really looking forward to being able to make changes like this.
Until we can get that done, it sounds like it would be best to keep this in a submodule that builds for 2.10 (and 2.9.3?) only. I'm excited about making this work.
