Ich versuche, die JIT-Kompilierung in clojure zu verwenden, um Mapper- und Reducer-Klassen on-the-fly zu generieren. Diese Klassen werden jedoch vom JobClient nicht erkannt (dies ist die übliche ClassNotFoundException).
Wenn ich AOT kompilieren Mapper, Reducer und Tool, und den Job mit RunJar ausführen, scheint alles in Ordnung. Nach einem Blick durch die Quelle scheint es, dass es das Jar entpackt und einen benutzerdefinierten URLClassLoader erstellt, mit dem es die "Main" -Implementierung lädt. Was ich nicht sehe, ist, wie das jar über Knoten verteilt ist oder wie es in einem Cluster mit einem Knoten verwendet wird.
Jede Hilfe wäre sehr willkommen!
Wenn wir das JAR eines Jobs übergeben, wird es zuerst vom Jobtracker in das Staging-Verzeichnis kopiert, das in den Eigenschaften konfiguriert ist. Und wenn ein Tasktracker den Job (vom Scheduler ofc) zugewiesen bekommt, kopiert er aus dem Staging-Verzeichnis und führt ihn aus.
Wenn Sie ein externes Jar zur Ausführung geben möchten, können Sie dies mit der Funktion Distributed Cache von Hadoop tun.
Clojure hat etwas gemeinsam mit anderen Java-Skriptmethoden wie Beanshell, Groovy und Ant ..., wenn Sie beim Ausführen des Skripts die Classloading-Funktionen der Skriptsprache verwenden, wenn Ihr Skript es startet -koppelt sich vom Standard-Classloader und dann läuft Ihre JVM auf dem benutzerdefinierten Classloader für die Skript-Engine. Ich habe keine Ahnung, was Ihren Fehler verursacht, aber Sie sollten bedenken, dass, wenn Sie irgendetwas in Ihrem Skript tun, das einen benutzerdefinierten Klassenlader dazu bringen würde, den JVM-Standard-Classloader zu verlassen, dann könnte es ein paar Dinge erklären.
Nach meiner Erfahrung konnte ich diese Probleme nicht lösen, und so musste ich beispielsweise bei Beanshell aufhören, die Classloader-Optionen zu verwenden und meinen gesamten Klassenpfad in der Befehlszeile angeben, die die JVM startet. Auf diese Weise wusste ich, dass das Skript den Standard-Classloader verwendete und dass alle Klassen gefunden wurden.
Ein anderes Beispiel mit:
Klassen / groovig / A.groovy
Klassen / groovig / B.groovy
%Vor%GroovyClassLoader lädt Groovy Klasse B nicht. Diese Art von Sache kann auch reproduziert werden, indem versucht wird, einen JDBC-Treiber mit classForName aus einem benutzerdefinierten Classloader (nicht dem Standard-Classloader) zu laden.