2013-12-11 15 views
6

Ho due nodi C * 2.0.2 in un DC (con una configurazione predefinita in cassandra.yaml) e uno spazio tasti con RF = 2. Due client sono collegati a questo controller con un driver Java 1.0 Datastax. I client leggono e scrivono i dati da/a C * con CL = ONE senza errori. Ma quando ho chiuso un nodo verso il basso entrambi i clienti a ottenere una quantità enorme di eccezioni:Cassandra NoHostAvailableException mentre è ancora attivo il nodo

com.datastax.driver.core.exceptions.NoHostAvailableException: 
All host(s) tried for query failed (no host was tried) 

Dopo quel gruppo di eccezioni clienti continuano a lavorare con successo con un altro nodo che rimane ancora in vita. Cosa devo fare per non ricevere alcuna NoHostAvailableException perché esiste almeno un nodo attivo alla volta e CL = ONE viene utilizzato?

UPDATE: Quando ho chiuso uno dei due nodi a volte vedo la seguente eccezione nel mio ceppo di applicazione:

[Reconnection-1] [ERROR] [Control connection] Cannot connect to 
any host, scheduling retry 

Perché entrambi i nodi non sono disponibili se chiudo un solo verso il basso? Il secondo è ancora vivo in questo momento e posso collegarmi ad esso con cqlsh.

+0

Mi dispiace che la mia risposta non sia stata d'aiuto. Hai provato a attivare la registrazione di traccia per com.datastax.driver.core.RequestHandler? Sembra che quando si spegne il primo nodo, il secondo viene espulso dal pool per qualche motivo. La traccia di stack delle eccezioni registrate nel metodo RequestHandler.logError() ("Errore durante la ricerca di bla-bla-bla") potrebbe aiutare a scoprirlo. – Wildfire

+0

Lo proverò, grazie. – tilex

risposta

0

Se si esegue una richiesta con CL = ONE, il driver tenta di interrogare solo un singolo nodo. Quindi, se la richiesta a quel nodo fallisce (o il nodo non è disponibile), l'eccezione viene lanciata immediatamente. Questo comportamento è controllato da com.datastax.driver.core.policies.RetryPolicy specificato durante la creazione di Cluster.

Direi che uno RetryPolicy che fa un conteggio fisso dei tentativi di riprova si adatterebbe alle vostre esigenze. Sfortunatamente, Cassandra Driver 1.0.3 non lo ha raggruppato (non sono sicuro che le versioni successive lo facciano). Ancora, potrebbe essere implementato in questo modo:

public class MyRetryPolicy implements RetryPolicy { 

    final int attempts; 

    public MyRetryPolicy(int attempts) { 
     this.attempts = attempts; 
    } 

    @Override 
    public RetryDecision onReadTimeout(Query query, ConsistencyLevel cl, int requiredResponses, int receivedResponses, boolean dataRetrieved, int nbRetry) { 
     return (nbRetry >= attempts) ? RetryDecision.rethrow() : RetryDecision.retry(cl) 
    }   

    ... <onWriteTimeout & onUnavailable methods with similar implementation> 
} 

Non sono sicuro se MyRetryPolicy(2) sarà sufficiente, dato che non ho scavare in interni driver che profonda. Probabilmente verrà effettuato un altro tentativo di inviare la stessa richiesta allo stesso host. Si può provare MyRetryPolicy(10), dovrebbe ridurre almeno in modo significativo il numero di errori.

Se alcuni errori rimangono ancora (come 1 su 1000), può valere la pena di guardare com.datastax.driver.core.ConvictionPolicy, trovare i suoi utilizzi e indagare ulteriormente.

+1

Custom 'RetryPolicy' è la prima cosa che ho provato ma nessuno dei suoi metodi di callback viene chiamato quando viene lanciato' NoHostAvailableException'. – tilex

Problemi correlati