2015-09-23 6 views
11

ho zeppelin apache appena installato (costruito da sorgenti più recenti da git repo) e ha visto con successo è installato e funzionante in porto 10008. Ho creato un nuovo taccuino con una sola riga di codiceCiao mondo in zeppelin falliti

val a = "Hello World!" 

ed eseguire questo punto e ha visto l'errore sotto

java.net.ConnectException: Connection refused a java.net.PlainSocketImpl.socketConnect (metodo natale) a java.net.AbstractPlainSocketImpl.doConnect (AbstractPlainSock etImpl.java:350) a java.net.AbstractPlainSocketImpl.connectToAddress (AbstractPlainSocketImpl.java:206) a java.net.AbstractPlainSocketImpl.connect (AbstractPlainSocketImpl.java:188) a java.net.SocksSocketImpl.connect (SocksSocketImpl.java:392) a java.net.Socket.connect (Socket.java:589) a org.apache.thrift.transport.TSocket.open (TSocket.java:182) a org.apache.zeppelin. interpreter.remote.ClientFactory.create (ClientFactory.java:51) a org.apache.zeppelin.interpreter.remote.ClientFactory.create (ClientFactory.java:37) a org.apache.commons.pool2.BasePooledObjectFactory. makeObject (BasePooledObjectFactory.java:60) a org.apache.commons.pool2.impl.GenericObjectPool.create (GenericObjectPool.java:861) a org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:435) a org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.java:363) a org.apache.zeppelin.interpreter.remote.RemoteInterpreterProcess.getClient (RemoteInterpreterProcess.java:139) a org.apache. zeppelin.interpreter.remote.RemoteInterpreter.init (RemoteInterpreter.java:137) a org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType (RemoteInterpreter.java:257) alle org.apache.zeppelin.interpreter.LazyOpenInterpreter.getFormType (LazyOpenInterpreter.java:104) a org.apache.zeppelin.notebook.Paragraph.jobRun (Paragraph.java:197) a org.apache.zeppelin.scheduler.Job .run (Job.java:170) a org.apache.zeppelin.scheduler.RemoteScheduler $ JobRunner.run (RemoteScheduler.java:304) a java.util.concurrent.Executors $ RunnableAdapter.call (Executors.java: 511) a java.util.concurrent.FutureTask.run (FutureTask.java:266) a java.util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.access $ 201 (ScheduledThreadPoolExecutor.java:180) a java.util.concurrent. ScheduledThreadPoolExecutor $ ScheduledFutureTask.run (ScheduledThreadPoolExecutor.java:293) a java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.java:1142) a java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.java:617) a java.lang.Thread.run (Thread.java:745

Qualsiasi indizio?

Il mio backend è spark 1.5 e ho verificato tramite interfaccia web dell'interprete che lo zeppelin punta alla giusta versione di spark e approproate spark.home.

+1

La tua scintilla sta funzionando? – Reactormonk

risposta

0

Ho notato che l'URL che punta alla scintilla non era corretto.Una volta, l'ho corretto, funziona bene. Grazie comunque.

5

L'errore può essere rilevato anche a causa di un errore verificatosi durante il tentativo di Zeppelin di creare l'interprete.

Zeppelin avvia l'interpretter in un processo diverso e tenta di connettersi ad usare Thrift protocollo

Nel mio caso io ho questo errore quando si cerca di assegnare 5 GB per il driver scintilla scintilla defaults.conf Si è risolto quando commentando questa linea (o assegnare 4g o meno)

#spark.driver.memory    5g 

Si potrebbe avere uno sguardo a questo JIRA ZEPPELIN-305

EDIT:

Questo errore può essere causato da qualsiasi motivo che impedisca l'avvio del processo dell'interprete Spark. Recentemente, l'ho capito quando ho provato ad aggiungere le opzioni JMX a ZEPPELIN_JAVA_OPTS, il che fa sì che il processo dell'interprete utilizzi la stessa porta JMX del processo Zeppelin. Dare la "Porta già in uso" Errore

Si prega di controllare i registri Zeppelin (di default sono in ZEPPELIN_DIR/logs/per vedere cosa sta succedendo quando Zeppelin si tenta di avviare Spark Interpreter

3

Ho avuto questo problema quando $SPARK_HOME non è stato impostato correttamente

0

ha avuto lo stesso problema quando $ YARN_QUEUE è stato impostato in modo errato

1

Questa domanda è stato aperto da un anno, non so se la soluzione al problema è stato realizzato. Recentemente, mi sono imbattuto in un errore simile utilizzando Yarn-Spark su Amazon EMR. Come ho effettuato il debug, ho realizzato quanto segue, e w ould suggerire alle persone di provare se si trovano in scarpe simili (soluzione è basata su EMR, ma dovrebbe essere simile su altre offerte)

1. kill -9 `ps -ef | grep zeppelin | grep -v grep | awk '{print $2}'`(*will make sure zombie processes are taken care of*) 
2. kill -9 `ps -ef | grep hadoop-yarn-resourcemanager | grep -v grep | awk '{print $2}'` 
3. sudo /sbin/restart hadoop-yarn-resourcemanager 
4. At times, simply starting the resource-manager does not start the name-node `sudo start hadoop-hdfs-namenode` 
5. sudo /usr/lib/zeppelin/bin/zeppelin-daemon.sh start 
6. Use telnet to make sure that the default ports are open for required service. 

Allo endo stesso, si dovrebbe essere in grado di ottenere zeppelin in esecuzione correttamente con uno SparkContext valido. Spero che questo sia stato utile

0

Nel mio caso, (project-root)/node_modules/zeppelin/spark-2.0.2-bin-hadoop2.7 non è stato installato, per qualche motivo sconosciuto. rm -rf node_modules; npm cache clear; npm i risolto.

1

Una pila di errori come [1] di seguito potrebbe significare un sacco di cose diverse. Il server Zeppelin non ha potuto connettersi a un interprete locale, perché non è stato avviato o è morto. Sembra un bug Zeppelin in quanto non può essere catturato quando interpreter.sh viene chiuso senza creare un processo interprete di Zeppelin, inviato https://issues.apache.org/jira/browse/ZEPPELIN-1984 per tracciarlo.

In tutti i nostri casi con diverse cause alla radice, vero errore è stato solo rivelabile se si desidera aggiungere

LOG="/tmp/interpreter.sh-$$.log" 
date >> $LOG 
set -x 
exec >> $LOG 
exec 2>&1 

a $ ZEPPELIN_HOME/bin/interpreter.sh così allora un /tmp/interpreter.sh-* il file .log ti mostrerebbe un problema reale.

[1]

ERRORE [2017/01/18 16: 54: 38.533] ({pool-2-thread-2} NotebookServer.java [afterStatusChange]: 1645) - Errore org .apache.zeppelin.interpreter.InterpreterException: org.apache.zeppelin.interpreter.InterpreterException: org.apache.thrift.transport.TTransportException: java.net.ConnectException: Connection refused a org.apache.zeppelin.interpreter.remote .RemoteInterpreter.init (RemoteInterpreter.java:232) all'indirizzo org.apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType (RemoteInterpreter.java:400) all'indirizzo org.apache.zeppelin.interpreter.LazyOpenInterpreter.getFormType (LazyOpenInterpreter.java : 105) in org.apache.zeppelin.notebook.Paragraph.jobRun (Paragraph.java:316) in org.apache.zeppelin.scheduler.Job.run (Job.java:176) presso org.apache.zeppelin .scheduler.RemoteScheduler $ JobRunner.run (RemoteScheduler.java:329) a java.util.concurrent.Executors $ RunnableAdapter.call (Executors.java:471) a java.util.concurrent.FutureTask.run (FutureTask.java:262)

Modifica. Un altro modo per svelare la vera causa di root è cambiare log4j per vedere l'output del processo di interprete spark, come suggerito da Jeff in ZEPPELIN-1984. Modificare le ZEPPELIN_HOME/conf/log4j.properies come segue:

log4j.rootLogger = INFO, dailyfile 

log4j.appender.stdout = org.apache.log4j.ConsoleAppender 
log4j.appender.stdout.layout = org.apache.log4j.PatternLayout 
log4j.appender.stdout.layout.ConversionPattern=%5p [%d] ({%t} %F[%M]:%L) - %m%n 

log4j.appender.dailyfile.DatePattern=.yyyy-MM-dd 
log4j.appender.dailyfile.Threshold = DEBUG 
log4j.appender.dailyfile = org.apache.log4j.DailyRollingFileAppender 
log4j.appender.dailyfile.File = ${zeppelin.log.file} 
log4j.appender.dailyfile.layout = org.apache.log4j.PatternLayout 
log4j.appender.dailyfile.layout.ConversionPattern=%5p [%d] ({%t} %F[%M]:%L) - %m%n 

log4j.logger.org.apache.zeppelin.interpreter.InterpreterFactory=DEBUG 
log4j.logger.org.apache.zeppelin.notebook.Paragraph=DEBUG 
log4j.logger.org.apache.zeppelin.scheduler=DEBUG 
log4j.logger.org.apache.zeppelin.livy=DEBUG 
log4j.logger.org.apache.zeppelin.flink=DEBUG 
log4j.logger.org.apache.zeppelin.spark=DEBUG 
log4j.logger.org.apache.zeppelin.python=DEBUG 
log4j.logger.org.apache.zeppelin.interpreter.util=DEBUG 
log4j.logger.org.apache.zeppelin.interpreter.remote=DEBUG 
log4j.logger.org.apache.zeppelin.interpreter.remote.RemoteInterpreterServer=DEBUG 

e riavviare Zeppelin. Nota: potrebbe produrre una registrazione eccessiva. Il mio consiglio originale di aggiungere poche righe a interpreter.sh non richiede il riavvio di Zeppelin.

anche creato richiesta di pull a (parzialmente) risolvere questo problema: https://github.com/apache/zeppelin/pull/1921

Aggiornamento 2017/01/24. https://issues.apache.org/jira/browse/ZEPPELIN-1984 è fisso in master e non sarà incluso nella versione Zeppelin 0.8. Due importanti correzioni sono parte di ZEPPELIN-1984:

  • non si otterrebbe "connection refused" Whan un processo interpter non può iniziare;
  • Zeppelin mostrerebbe la causa principale (in un output di paragrafo) qual è la causa principale.
0

Ho risolto questo bug con il cambiamento del filo-cluster scintilla modle a filo-client come seted in zepplin/conf/defalt.sh

0

Ho ottenuto esattamente lo stesso errore quando ha cercato di correre con Zeppelin Spark nello stesso container docker su micro instance in Amazon ECS.

L'origine dell'errore è visibile nel log di output in% ZEPPELIN_HOME%/logs/*. Out e si diceva che Zeppelin non è riuscito ad avviare l'interprete Spark a causa della poca memoria. Così ho spostato la mia immagine Docker sull'istanza con più memoria.

0

Nel mio caso, ho tre nodi nel mio cluster. Anche se in tre di essi è stata installata una scintilla, lo zeppelin è stato installato solo su uno di essi.

So In zeppelin Interprete Menu -> Spark -> Modifica -> Proprietà -> Master

cambiare il parametro da filo-client a locale [*] fisso il mio problema.