web-dev-qa-db-fra.com

Bonjour tout le monde dans zeppelin a échoué

Je viens d’installer Apache zeppelin (construit à partir de la dernière source de git repo) et j’ai constaté avec succès qu’il fonctionnait sur le port 10008. J'ai créé un nouveau carnet de notes avec une seule ligne de code.

val a = "Hello World!"

Et exécutez ce paragraphe et vu l'erreur ci-dessous

Java.net.ConnectException: connexion refusée à Java.net.PlainSocketImpl.socketConnect (Méthode native) à Java.net.AbstractPlainSocketImpl.doConnect (AbstractPlainSocketImpl.Java:350) à Java.net.AbstractPlainSocketImpl.connectToAddress (AbstractPlainSocketImpl.Java:206) à Java.net.AbstractPlainSocketImpl.connect (AbstractPlainSocketImpl.Java:188) sur Java.net.SocksSocketImpl.connect (SocksSocketImpl.Java:392) sur Java.net.Socket.connect (Socket.Java:589) à org.Apache.thrift.transport.TSocket.open (TSocket.Java:182) à l'adresse org.Apache.zeppelin.interpreter.remote.ClientFactory.create (ClientFactory.Java:51) à org.Apache.zeppelin.interpreter.remote.ClientFactory.create (ClientFactory.Java:37) à org.Apache.commons.pool2.BasePooledObjectFactory.makeObject (BasePooledObjectFactory.Java:60) à org.Apache.commons.pool2.impl.GenericObjectPool.create (GenericObjectPool.Java:861) à org.Apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.Java:435) à org.Apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObjectPool.Java:363) à org.Apache.zeppelin.interpreter.remote.RemoteInterpreterProcess.getClient (RemoteInterpreterProcess.Java:139) à org.Apache.zeppelin.interpreter.remote.RemoteInterpreter.init (RemoteInterpreter.Java:137) à org.Apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType (RemoteInterpreter.Java:257) à org.Apache.zeppelin.interpreter.LazyOpenInterpreter.getFormType (LazyOpenInterpreter.Java:104) à org.Apache.zeppelin.notebook.Paragraph.jobRun (Paragraph.Java:197) à org.Apache.zeppelin.scheduler.Job.run (Job.Java:170) à org.Apache.zeppelin.scheduler.RemoteScheduler $ JobRunner.run (RemoteScheduler.Java:304) à Java.util.concurrent.Executors $ RunnableAdapter.call (Executors.Java:511) à Java.util.concurrent.FutureTask.run (FutureTask.Java:266) à Java.util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.access $ 201 (ScheduledThreadPoolExecutor.Java:180) à Java.util.concurrent.ScheduledThreadPoolExecutor $ ScheduledFutureTask.run (ScheduledThreadPoolExecutor.Java:293) à Java.util.concurrent.ThreadPoolExecutor.runWorker (ThreadPoolExecutor.Java:1142) à Java.util.concurrent.ThreadPoolExecutor $ Worker.run (ThreadPoolExecutor.Java:617) à Java.lang.Thread.run (Thread.Java:745

Un indice?

Mon backend est spark 1.5 et j’ai vérifié par l’interface Web de l’interprète que zeppelin pointe vers la version correcte de spark et approproate spark.home.

apache-sparkapache-zeppelin
11
Bala

L'erreur peut également être attribuée à une erreur survenue pendant que Zeppelin essayait de créer l'interpréteur.

Zeppelin démarre l'interprète dans un processus différent et tente de se connecter à l'aide du protocole Thrift

Dans mon cas, je vois cette erreur en essayant d’attribuer 5 Go au pilote spark dans spark-defaults.confIl est résolu en commentant cette ligne (ou en affectant 4g ou moins) 

#spark.driver.memory              5g

Vous pouvez jeter un oeil à cette JIRA ZEPPELIN-305

MODIFIER:

Cette erreur peut être due à une raison quelconque empêchant le processus interpréteur Spark de démarrer . processus. Donner l'erreur "Port déjà utilisé"

Veuillez vérifier les journaux Zeppelin (ils sont par défaut dans ZEPPELIN_DIR/logs/pour voir ce qui se passe lorsque Zeppelin tente de démarrer Spark Interpreter.

5
user1314742

J'ai eu ce problème lorsque $SPARK_HOME n'était pas correctement défini

3
LK__

Une pile d’erreur telle que [1] ci-dessous pourrait signifier beaucoup de choses différentes… __ Zeppelin Server n’a pas pu se connecter à un interpréteur local, car il n’a pas démarré ou est mort. Il semble qu’un bogue Zeppelin n’arrive pas lorsque interpreter.sh se ferme sans créer un processus d’interprète Zeppelin, soumis https://issues.Apache.org/jira/browse/ZEPPELIN-1984 pour le suivre.

Dans tous nos cas avec différentes causes fondamentales, une erreur réelle ne pouvait être révélée Si vous ajoutiez 

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

pour $ ZEPPELIN_HOME/bin/interpreter.sh, un fichier /tmp/interpreter.sh-*.log vous montrera le problème.

[1]

ERROR [2017-01-18 16: 54: 38,533] ({pool-2-thread-2} NotebookServer.Java [afterStatusChange]: 1645) - Erreur org.Apache.zeppelin.interpreter.InterpreterException: org.Apache.zeppelin.interpreter.InterpreterException: org.Apache.thrift.transport.TTransportException: Java.net.ConnectException: connexion refusée à org.Apache.zeppelin.interpreter.remote.RemoteInterpreter.init (RemoteInterpreter.Java:232) à org.Apache.zeppelin.interpreter.remote.RemoteInterpreter.getFormType (RemoteInterpreter.Java:400) à org.Apache.zeppelin.interpreter.LazyOpenInterpreter.getFormType (LazyOpenInterpreter.Java:105) sur org.Apache.zeppelin.notebook.Paragraph.jobRun (Paragraph.Java:316) à org.Apache.zeppelin.scheduler.Job.run (Job.Java:176) à org.Apache.zeppelin.scheduler.RemoteScheduler $ JobRunner.run (RemoteScheduler.Java:329) à Java.util.concurrent.Executors $ RunnableAdapter.call (Executors.Java:471) à Java.util.concurrent.FutureTask.run (FutureTask.Java:262)

Modifier. Un autre moyen de révéler la véritable cause est de modifier log4j pour afficher le résultat du processus d'interprétation de l'étincelle, comme suggéré par Jeff dans ZEPPELIN-1984. Changez votre ZEPPELIN_HOME/conf/log4j.properies comme suit:

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

et redémarrez Zeppelin. Remarque: cela peut produire une journalisation excessive. Mon conseil initial d’ajouter quelques lignes à interpreter.sh ne nécessite pas le redémarrage de Zeppelin.

Également créé une demande d'extraction pour résoudre (partiellement) ce problème: https://github.com/Apache/zeppelin/pull/1921

Mise à jour du 24/01/2017. https://issues.Apache.org/jira/browse/ZEPPELIN-1984 est corrigé dans master et sera inclus dans la version 0.8 de Zeppelin. Deux corrections importantes font partie de ZEPPELIN-1984:

  • vous n'obtiendrez pas une "connexion refusée" si un processus d'interpolation ne peut pas démarrer;
  • Zeppelin montrerait la cause première (dans une sortie de paragraphe) quelle est la cause fondamentale.
1
Tagar

Avait le même problème quand $ YARN_QUEUE était mal défini

0
thepolina

J'ai eu exactement la même erreur lorsque j'ai essayé d'exécuter Zeppelin avec Spark dans le même conteneur de menu fixe sur une micro-instance dans Amazon ECS.

La source de l'erreur est visible dans le journal de sortie dans% ZEPPELIN_HOME%/logs/*. Out et il était indiqué que Zeppelin n'a pas pu démarrer l'interpréteur Spark en raison d'une mémoire insuffisante. J'ai donc déplacé mon image Docker vers l'instance avec davantage de mémoire.

0
Igor Bljahhin

J'ai corrigé ce bogue en changeant le modèle d'étrier en modèle d'étoile en client en fil tel qu'il était défini dans zepplin/conf/defalt.sh

0
Jary zhen

Cette question est ouverte depuis un an maintenant, pas sûr si la solution au problème a été réalisée. Récemment, je suis tombé sur une erreur similaire en utilisant Yarn-Spark sur Amazon EMR. Alors que je déboguais, je me rendais compte de ce qui suit et suggérerais aux gens d’essayer s’ils se trouvaient dans des chaussures similaires ( la solution est basée sur le DME, mais devrait être similaire sur d’autres offres )

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.

De la même manière, on devrait pouvoir faire fonctionner correctement zeppelin avec un SparkContext valide. J'espère que cela a été utile

0
Pramit

J'ai remarqué que l'URL qui indique d'étincelle n'était pas correct. Une fois, je l'ai corrigé, cela fonctionne bien. Merci quand même.

0
Bala

Dans mon cas, j'ai trois nœuds dans mon cluster. Bien que l'étincelle ait été installée dans trois d'entre eux, le zeppelin n'a été installé que sur l'un d'entre eux.

So In zeppelin Interpreter Menu -> Spark -> Éditer -> Propriétés -> Master

changer ce paramètre de yarn-client à local [*] a corrigé mon problème.

0
neverwinter

Dans mon cas, (project-root)/node_modules/zeppelin/spark-2.0.2-bin-hadoop2.7 n'a pas été installé, pour une raison inconnue. rm -rf node_modules; npm cache clear; npm i l'a corrigé.

0
christopherbalz