Skip to content
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

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

Open
nklasens opened this issue Jul 14, 2010 · 4 comments

Comments

@nklasens
Copy link

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
Copy link
Owner

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
Copy link
Owner

"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
Copy link
Owner

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
Copy link
Author

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

}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants