Open GoogleCodeExporter opened 8 years ago
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);
Original comment by jamiemcc...@gmail.com
on 26 Sep 2011 at 4:18
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.
Original comment by mikewie...@gmail.com
on 28 Sep 2011 at 10:48
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
Original comment by gml...@gmail.com
on 29 Sep 2011 at 12:11
@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.
Original comment by jamiemcc...@gmail.com
on 30 Sep 2011 at 9:08
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.
Original comment by mikewie...@gmail.com
on 30 Sep 2011 at 10:34
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
: )
Original comment by jamiemcc...@gmail.com
on 4 Oct 2011 at 12:46
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.
Original comment by mikewie...@gmail.com
on 4 Oct 2011 at 11:27
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.
Original comment by ingen...@gmail.com
on 16 Oct 2011 at 1:55
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)?
Original comment by eger.p.e...@gmail.com
on 1 Nov 2011 at 6:38
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,
Original comment by ad...@nedelcu.net
on 28 Apr 2014 at 6:27
check out the latest versions, you have addListener callbacks on there!
Original comment by michael....@gmail.com
on 5 May 2014 at 6:15
Original issue reported on code.google.com by
jamiemcc...@gmail.com
on 26 Sep 2011 at 4:15