alphazero / jredis

Java Client and Connectors for Redis
http://code.google.com/p/jredis/
Apache License 2.0
315 stars 136 forks source link

Construct clients (JRedis*Client, JRedis*Service) without immediate connect #21

Open nklasens opened 14 years ago

nklasens commented 14 years ago

It would be nice to be able to create clients without Exceptions when the Redis Server is not available. I can not start my web application and initialize a client class for singleton usage at startup when the server is not available.

The org.jredis.ri.alphazero.connection.ConnectionBase has a constructor with a boolean connectImmediately, but this is not inherited by the subclasses. I added these constructors to the connection classes to be able to create a client and connect at a later stage.

For Example I added this public AsynchConnection(ConnectionSpec connectionSpec, boolean isShared, boolean connectImmediately) throws ClientRuntimeException, ProviderException { super(connectionSpec, connectImmediately); }

This is a quick solution, but it would be even nicer if the Service code deals with the case that the Redis Server is not available.

alphazero commented 14 years ago

Hi, not sure about this. As you noted, a simple wrapper is basically what is required and its not clear what the service would 'provide' if your server is down. Should it continually try and finally get a connection? In effect, the end result is that you will get an exception when you try to ask the service to do something.

alphazero commented 14 years ago

"I can not start my web application and initialize a client class for singleton usage at startup when the server is not available."

Sorry, I missed this. Let me think about it. Thanks for pointing out the issue.

/R

alphazero commented 14 years ago

Alright: http://gist.github.com/480022

I don't know the ETA on this but its clearly doable and at this point I'm inclined to think it is the way to go forward.

There are two ways to play the downtime parameter. One would be in an asynch queuing architecture (which would be a pretty good fit) and the value a function of the queue size. And the other with the normal Req/Resp sync semantics -- e.g. container service - and here the macDowntime is the maximum latency you are willing to tolerate once per every redis.conf::timeout cycle.

nklasens commented 14 years ago

Sounds like you are coming up with a more complicated approach then I did. Changes like the following are already good enough for me

public class JRedisAsynchClient extends JRedisFutureSupport {

/**
 * @param connectionSpec
 */
public JRedisAsynchClient (ConnectionSpec connectionSpec, boolean connectImmediately) {
    // note: using a shared connection mod
    connectionSpec.isReliable(true);
    connection = new AsynchConnection(connectionSpec, true, connectImmediately);
}

public boolean isActive() {
    return connection.isActive();
}

}

public class AsynchConnection {

private AtomicBoolean firstConnect = new AtomicBoolean(false);

public AsynchConnection(ConnectionSpec connectionSpec, boolean isShared, boolean connectImmediately) throws ClientRuntimeException,
        ProviderException {
    super(connectionSpec, connectImmediately);
    tryFirstConnect();
}

public boolean isActive() {
    if (! firstConnect.get()) {
        tryFirstConnect();
    }

    return isConnected();
}

private void tryFirstConnect() {
    try {
        connect();
        firstConnect.set(true);
    } catch (IllegalStateException e) {
        // some other thread already connected
        firstConnect.set(true);
    } catch (ClientRuntimeException e) {
        Log.error(e.getMessage());
    }
}

}