Callback support about spymemcached HOT 11 OPEN

It's worth adding that this interface could also deal with cancellations and 
exceptions, so something like:

Cancellable asyncGet(final String key, CallbackOrError<Object> callback);

I'm going to leave this as "New" since I think it is a good feature request, 
but I don't see it making it into the API any time soon. We have actually been 
thinking of trying to remove api calls from MemcachedClient somehow as opposed 
to adding more. If you need this functionality though you can easily get it by 
extending MemcachedClient and adding function signatures that will allow you to 
pass Callbacks. This should be really easy to do in Spy 2.8+.

If there is major support for this feature we will reconsider it.

public class foo {


  static class Cls1{}
  static class Cls2 extends Cls1{}

  public Cls1 foo(){ return null; }
  public Cls2 foo(){ return null; }

}


When i try to compile this i get this error

andrei /tmp>  javac foo.java 
foo.java:9: foo() is already defined in foo
  public Cls2 foo(){ return null; }

This is what you are doing
How did you compile your 2.7.1 jar? I want to try to build it myself

I just downgraded to 2.7 because I can not use 2.7.1 with servlet

@mikew

Thanks for the response. They don't need to be methods on Memcached client if 
it's possible to get it by extending Memcached client or leveraging some 
backing class.

Great to hear. As I said you can extend MemcachedClient to do this. If you look 
at the code in MemcachedClient this should be pretty straightforward. Each 
function that corresponds to a memcached operation creates a callback in the 
function. So basically you just need to remove the code that creates the 
callback and then make a function signature that allows you to pass in your own.

Would you be interested in a contribution of this code to the spymemcached 
project? (If so, I'll flesh it out more than I was going to, add more comments 
and not rely on any of our internal classes). No obligation to take it, either 
: )

If we decided to add support for passing callbacks then we wouldn't add it 
until at least a 3.0 release where we would do a major overhaul of the user 
facing api's as well as some major internal changes. Your welcome to post a 
patch here and when we begin working on 3.0 we will certainly consider the 
changes, but there are no guarantees that something like this will make it in. 
Again the reason here is to try to shrink the api instead of making it larger.

I think a patch against 2.x would be considered as well, will review with Mike.

Marking as accepted rather than new, since it has been reviewed.

I'm extremely interested in this as well, as I am attempting to integrate 
spymemcached as the caching layer for a fully non-blocking messaging server 
which is not possible with the current Future<> implementation. Looking at git 
head, it seems that pretty much every operation that returns a value would need 
to be subclassed and implemented to expose this callback behaviour (and in 
fact, the internal Callback stuff is very close to what would be desired for a 
real interface). I appreciate keeping an API small small, perhaps *Async and 
*Callback can be factored into delegating specializations, EG 
BasicMemcachedClient (blocking) -> AsyncMemcachedClient (Future<>s) -> 
CallbackMemcachedClient (Callback based)?

Folks, please consider adding this.

For example I created a wrapper around SpyMemcached for exposing a Scala 
specific interface (i.e. an API that uses scala.concurrent.Future). 
Unfortunately, the only way to get a value out of a java.util.concurrent.Future 
is to do constant pooling on Future.isDone() ... that sucks and basically 
Java's Future is next to useless because of the need to do a blocking get() to 
get the value.

And so I did what is basically described in this ticket - I took a look at the 
internals of MemcachedClient and extended the functionality therein. However I 
had to do workarounds for things that didn't work out so well and my 
implementation is now tied with certain implementation details that I feel 
shouldn't be there. For example I don't care about or understand 
CASResponse.OBSERVE_ERROR_XXX status codes, which were added between version 
2.8.x and 2.11.x, plus I had to have my own timeout procedure and marking a 
connection on Spy's end as timedout or expired is error-prone.

A higher-level API with callbacks would ensure that the code my Scala API is 
based on doesn't break. It would be a win for SpyMemcached too for having more 
reach. Scala developers want to use Scala's Futures (which rock btw) and other 
Scala abstractions.

The project is here (currently stuck on version 2.8.4 because I have to ensure 
first that I don't introduce bugs in the migration to 2.11.1): 
https://github.com/alexandru/shade/

The dirty internals usage are here: 
https://github.com/alexandru/shade/blob/master/src/main/scala/shade/memcached/in
ternals/SpyMemcachedIntegration.scala

SpyMemcached is awesome, but exposing callbacks in the higher-level API would 
make it even more awesome.

Cheers,

check out the latest versions, you have addListener callbacks on there!