retrying in storehaus should be a little more configurable

[softprops]

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

1. 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.

2. 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 hopefully be the fix but I'd had to figure out a good way of handling the 2.9.2 case.

3. The retry lib needs to emulate sleeping asynchronously to simulate a pause between 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.

4. 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.

[caniszczyk]

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

[softprops]

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.

[sritchie]

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.

[sritchie]

@softprops, we're all upgraded to 2.9.3 if you want to take this on.

[softprops]

sign me up! I'll see if I can start on that this weekend.