Disconnessione casuale dal nodo principale NoNodeAvailableException utilizzando Elastic Cloud/Found

Question

Uso il cloud elastico (ex found) con shield e il client di trasporto java. L'app che comunica con ES funziona su heroku. Sto eseguendo uno stress test su un ambiente di staging con un nodo

{ 
    "cluster_name": ..., 
    "status": "yellow", 
    "timed_out": false, 
    "number_of_nodes": 1, 
    "number_of_data_nodes": 1, 
    "active_primary_shards": 19, 
    "active_shards": 19, 
    "relocating_shards": 0, 
    "initializing_shards": 0, 
    "unassigned_shards": 7, 
    "delayed_unassigned_shards": 0, 
    "number_of_pending_tasks": 0, 
    "number_of_in_flight_fetch": 0 
} 

All'inizio tutto funziona perfettamente. Ma dopo un po 'di tempo (3-4 minuti) comincio a ricevere degli errori. Ho impostato il livello di registro per rintracciare e questi sono gli errori Sono stato sempre (ho sostituito con ... tutto ciò che è irrilevante.

org.elasticsearch.client.transport.NoNodeAvailableException: None of the configured nodes were available: [[...][...][...][inet[...]]{logical_availability_zone=..., availability_zone=..., max_local_storage_nodes=1, region=..., master=true}] 
    at org.elasticsearch.client.transport.TransportClientNodesService$RetryListener.onFailure(TransportClientNodesService.java:242) 
    at org.elasticsearch.action.TransportActionNodeProxy$1.handleException(TransportActionNodeProxy.java:78) 
    at org.elasticsearch.transport.TransportService$3.run(TransportService.java:290) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
    at java.lang.Thread.run(Thread.java:745) 
Caused by: org.elasticsearch.transport.SendRequestTransportException: [...][inet[...]][indices:data/read/search] 
    at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:286) 
    at org.elasticsearch.shield.transport.ShieldClientTransportService.sendRequest(ShieldClientTransportService.java:41) 
    at org.elasticsearch.action.TransportActionNodeProxy.execute(TransportActionNodeProxy.java:57) 
    at org.elasticsearch.client.transport.support.InternalTransportClient$1.doWithNode(InternalTransportClient.java:109) 
    at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:205) 
    at org.elasticsearch.client.transport.support.InternalTransportClient.execute(InternalTransportClient.java:106) 
    at org.elasticsearch.client.support.AbstractClient.search(AbstractClient.java:334) 
    at org.elasticsearch.client.transport.TransportClient.search(TransportClient.java:416) 
    at org.elasticsearch.action.search.SearchRequestBuilder.doExecute(SearchRequestBuilder.java:1122) 
    at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:91) 
    at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:65) 
    ... 
Caused by: org.elasticsearch.transport.NodeNotConnectedException: [...][inet[...]] Node not connected 
    at org.elasticsearch.transport.netty.NettyTransport.nodeChannel(NettyTransport.java:936) 
    at org.elasticsearch.transport.netty.NettyTransport.sendRequest(NettyTransport.java:629) 
    at org.elasticsearch.transport.TransportService.sendRequest(TransportService.java:276) 
    ... 

Queste sono le mie proprietà

settings = ImmutableSettings.settingsBuilder() 
     .put("client.transport.nodes_sampler_interval", "5s") //Tried it with 30s, same outcome 
     .put("client.transport.ping_timeout", "30s") 
     .put("cluster.name", clusterName) 
     .put("action.bulk.compress", false) 
     .put("shield.transport.ssl", true) 
     .put("request.headers.X-Found-Cluster", clusterName) 
     .put("shield.user", user + ":" + password) 
     .put("transport.ping_schedule", "1s") //Tried with 5s, same outcome 
     .build(); 

I 'ho anche impostare per ogni query che faccio:

max_query_response_size=100000 
timeout_seconds=30 

sto usando ElasticSearch 1.7.2 e Shield 1.3.2 con corrispondenti (stessa versione) i clienti, Java 1.8.0_65 sulla mia macchina - Java 1.8.0_40 sul nodo.

Avevo gli stessi errori senza uno stress test, ma gli errori si sono verificati in modo molto casuale, quindi ho voluto riprodurli. Ecco perché sto eseguendo questo in un singolo nodo.

ho notato un altro errore nei miei ceppi

2016-03-07 23:35:52,177 DEBUG [elasticsearch[Vermin][transport_client_worker][T#7]{New I/O worker #16}] ssl.SslHandler (NettyInternalESLogger.java:debug(63)) - Swallowing an exception raised while writing non-app data 
java.nio.channels.ClosedChannelException 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:433) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.close(AbstractNioWorker.java:373) 
    at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.read(NioWorker.java:93) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.process(AbstractNioWorker.java:108) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:337) 
    at org.elasticsearch.common.netty.channel.socket.nio.AbstractNioWorker.run(AbstractNioWorker.java:89) 
    at org.elasticsearch.common.netty.channel.socket.nio.NioWorker.run(NioWorker.java:178) 
    at org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) 
    at org.elasticsearch.common.netty.util.internal.DeadLockProofWorker$1.run(DeadLockProofWorker.java:42) 
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 

discussioni Hot

0.0% (111.6micros out of 500ms) cpu usage by thread 'elasticsearch[...][transport_client_timer][T#1]{Hashed wheel timer #1}' 
10/10 snapshots sharing following 5 elements 
    java.lang.Thread.sleep(Native Method) 
    org.elasticsearch.common.netty.util.HashedWheelTimer$Worker.waitForNextTick(HashedWheelTimer.java:445) 
    org.elasticsearch.common.netty.util.HashedWheelTimer$Worker.run(HashedWheelTimer.java:364) 
    org.elasticsearch.common.netty.util.ThreadRenamingRunnable.run(ThreadRenamingRunnable.java:108) 
    java.lang.Thread.run(Thread.java:745) 

Dopo aver letto questo http://blog.trifork.com/2015/04/08/dealing-with-nodenotavailableexceptions-in-elasticsearch/ sono arrivato a capire un po 'meglio come l'intera opera di comunicazione. Non ho ancora provato questo, ma credo che il problema risieda qui. Il problema è che, anche se confermo che il problema è chiuso alle connessioni di query, come posso gestirlo? Tieni la configurazione così com'è e ricollegati? Disabilito keepAlive? Se sì, dovrei preoccuparmi di qualcos'altro?

Answer 1

Citando questo link: https://discuss.elastic.co/t/nonodeavailableexception-with-java-transport-client/37702 da Konrad Beiske

vostra applicazione potrebbe essere risolvendo l'indirizzo IP al momento del boot. L'ELB può cambiare l'ip in qualsiasi momento. Per la massima affidabilità , l'applicazione deve aggiungere tutti gli IP dell'ELB al client e periodicamente controllare le modifiche al servizio DNS.

Il timeout della connessione dei nostri ELB è di 5 minuti.

seguito dovrebbe aiutare a risolvere il problema:

Creazione di un nuovo TransportClient per ogni richiesta non è l'ideale in quanto implicherà una nuova stretta di mano di connessione per ogni richiesta e questo male il tuo tempo di reazione. È possibile disporre di un pool di TransportClients se si preferisce lo , ma è molto probabilmente un overhead non necessario poiché il client è thread-safe.

Il mio suggerimento è quello di creare un servizio Singleton piccolo che verifichi periodicamente le modifiche al servizio DNS e aggiunga eventuali nuovi IP al client di trasporto esistente. In teoria potrebbe essere così ingenuo come come l'aggiunta di tutti gli IP rilevati ogni volta che viene controllato mentre il client di trasporto eliminerà gli indirizzi duplicati ed eliminerà anche i vecchi indirizzi non più raggiungibili.