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

[nklasens]

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]

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]

"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]

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]

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());
    }
}

}