-
Notifications
You must be signed in to change notification settings - Fork 3.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
support asynchronous calls to redis #241
Comments
Is it likely to be available soon? I'm on the verge of implementing it myself as I need asynchronous calls for performance reasons. |
Hopefully it will be available very soon. On Tue, Aug 21, 2012 at 9:34 AM, DivineTraube [email protected]:
|
That sounds good. I could wait for up to four weeks. Is it likely to be finished in that time frame? |
I think we should have something releasable next week. If you can test it On Tue, Aug 21, 2012 at 11:15 AM, DivineTraube [email protected]:
|
I will be happy to do that. |
Is it testable by now? |
Hey DivineTraube, I did a simple async implementation, does that do what you are looking for? https://github.com/samhendley/jedis/commits/version_tests |
Any updates? |
Anything new and exciting here with async jedis? |
👍 |
With the recent release of Java 8,n being able to have async operations with Redis would be awesome. Any updates ? |
Any progress on async jedis? |
Hello all! I have requested for switching Jedis IO to NIO. #647 Btw, I'm beginner of NIO and async, I wish to know your client code example for make decision of way of supporting async. Thanks in advance! |
That's good news thanks ! For client code, you should have a look to https://github.com/sdeleuze/opensnap/tree/master/opensnap-server/src/main/java/opensnap Since Jedis should run from at least JDK 1.6, providing a custom completable future is the best option I think. Please have a look to https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/MongoFuture.java and https://github.com/mongodb/mongo-java-driver/blob/3.0.x/driver/src/main/org/mongodb/connection/SingleResultCallback.java Please note they use clearly separated classes (and even module) in order to avoid polluting synchronous one. java.util.concurrent.Future is not interesting to support since it only allow async blocking implementations. On the API side, the main point is to use a callback with an interface with only 1 method in order to make it possible to use lambda for people using Java 8. I will be happy to update my OpenSnap example with any alpha level release of async Jedis in order to send you feedbacks. |
Those are great tips! Thanks a lot! And yes, any feedback is super On Sun, May 25, 2014 at 7:52 PM, Sébastien Deleuze <[email protected]
|
is it available? |
now jedis support async pubsub? any help? |
@Nurnabi It isn't available and it doesn't support pubsub yet. |
Do you have any planing date/month for 3.0.0 ? |
We will support async feature for sure. I believe we still don't have a schedule date, we want to do it as fast as
|
Rather than just Async, a Stream based API like MongoDB or CouchBase are developing would be even more powerful. See http://blog.couchbase.com/why-couchbase-chose-rxjava-new-java-sdk for more details ... |
@sdeleuze Could you give a hand to show some implementations? Thanks in advance! |
@sdeleuze |
@HeartSaVioR Glad you like it. In term of API, some possible use cases for streams (
You can see an example of converting Netty data pipeline to RxJava here (using what RxJava call a |
Exposing just a Reactive Streams based API, like Mongo is currently doing, could also make sense. |
@HeartSaVioR is looking at an interesting direction, RxJava is great, couchbase client is using it and performance is great. |
@ivansanchezvera |
I broadly agree with @sdeleuze that Futures are, unfortunately, largely useless in applications where non-blocking is required as well as asynchronicity. For instance, on a platform such as Vert.x, one cannot block the thread under any circumstances, and polling is drastically suboptimal, so callbacks (with the library itself using async techniques to avoid blocking) is required. Of course the Vert.x guys made their own implementation, so you could use that for inspiration, but it'd be nice to have a generic client. |
This shouldn't be too tricky to do. The hardest part is you need to delegate a thread to consuming the server responses and feeding them into the futures you returned to your clients. Here is a snippet that uses an underlying Pipeline client that actually has alot of what we need other than a "pump thread". This isn't quite what we want since the subscribe method here will block waiting for each response. I don't have time to actually implement and test the full fledged version but I could provide guidance on how it can be implemented. (Or possibly if I get real bored one evening it might get done). public interface RxRedisCommands {
Observable<Long> append(String key, String value);
Observable<String> get(String key);
Observable<Long> incr(String key);
}
class RxJedisClient implements RxRedisCommands {
private final Pipeline pipeline;
private volatile boolean keepRunning;
private final AtomicLong outstandingResponses = new AtomicLong();
public RxJedisClient(Pipeline client) {
this.pipeline = client;
new Thread(new Runnable() {
@Override
public void run() {
while (keepRunning) {
try {
while (outstandingResponses.get() > 0) {
pipeline.sync();
}
synchronized (outstandingResponses) {
while (outstandingResponses.get() == 0) {
outstandingResponses.wait();
}
}
} catch (Exception e) {
throw new RuntimeException(e);
}
}
}
});
}
public void destroy(){
keepRunning = false;
synchronized (outstandingResponses) {
notify();
}
}
protected <T> Observable<T> getObservable(final Response<T> response) {
Observable<T> lr = Observable.create(new Observable.OnSubscribe<T>() {
@Override
public void call(Subscriber<? super T> subscriber) {
subscriber.onNext(response.get());
subscriber.onCompleted();
}
});
outstandingResponses.incrementAndGet();
synchronized (outstandingResponses) {
notify();
}
return lr;
}
public Observable<Long> append(String key, String value) {
return getObservable(pipeline.append(key, value));
}
@Override
public Observable<String> get(String key) {
return getObservable(pipeline.get(key));
}
@Override
public Observable<Long> incr(String key) {
return getObservable(pipeline.incr(key));
}
} |
@samhendley Hey, thanks for guiding! |
I personally haven't been sold that I look forward to seeing this applied to that PR. |
Also have a look to this issue (ReactiveX/RxJava#1594) that intend to provide a promise like type in RxJava (a strong need from my POV). |
@xetorthio what's the time dose asyncJedis RELESE ? |
##does it work ansync Jedis client? |
English not my primary language, but i try my best clearly describe this question.I use vertx build a async mirco service. Vertx throw an “Thread Block" exception. I submit this exception details ,hope to help yours solve this problem.
the code:
log details
|
I also hope async redis would be available soon. |
Let's continue the discussion here: #713 |
No description provided.
The text was updated successfully, but these errors were encountered: