ClassNotFound error when starting the storm starter topology in local mode (Win10, OS X)

I am trying to debug the Storm topology (on Storm v 1.0.0) under windows through:

TopologyBuilder builder = new TopologyBuilder(); builder.setSpout("spout", new RandomIntegerSpout()); builder.setBolt("partialsum", new StatefulSumBolt("partial"), 1).shuffleGrouping("spout"); builder.setBolt("printer", new PrinterBolt(), 2).shuffleGrouping("partialsum"); builder.setBolt("total", new StatefulSumBolt("total"), 1).shuffleGrouping("printer"); Config conf = new Config(); conf.setDebug(false); LocalCluster cluster = new LocalCluster(); StormTopology topology = builder.createTopology(); cluster.submitTopology("test", conf, topology); 

And get the following error (WordCount / Exclamation / Stateful or other topologies from a storm starter - it does not matter):

 java.lang.RuntimeException: java.lang.ClassNotFoundException: org.apache.storm.daemon.acker at org.apache.storm.utils.Utils.javaDeserialize(Utils.java:181) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.utils.Utils.getSetComponentObject(Utils.java:430) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.task$get_task_object.invoke(task.clj:74) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.task$mk_task_data$fn__66.invoke(task.clj:177) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.util$assoc_apply_self.invoke(util.clj:930) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.task$mk_task_data.invoke(task.clj:170) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.task$mk_task.invoke(task.clj:181) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.executor$mk_executor$fn__6149.invoke(executor.clj:371) ~[storm-core-1.0.0.jar:1.0.0] at clojure.core$map$fn__4553.invoke(core.clj:2622) ~[clojure-1.7.0.jar:?] at clojure.lang.LazySeq.sval(LazySeq.java:40) ~[clojure-1.7.0.jar:?] at clojure.lang.LazySeq.seq(LazySeq.java:49) ~[clojure-1.7.0.jar:?] at clojure.lang.RT.seq(RT.java:507) ~[clojure-1.7.0.jar:?] at clojure.core$seq__4128.invoke(core.clj:137) ~[clojure-1.7.0.jar:?] at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30) ~[clojure-1.7.0.jar:?] at clojure.core.protocols$fn__6506.invoke(protocols.clj:101) ~[clojure-1.7.0.jar:?] at clojure.core.protocols$fn__6452$G__6447__6465.invoke(protocols.clj:13) ~[clojure-1.7.0.jar:?] at clojure.core$reduce.invoke(core.clj:6519) ~[clojure-1.7.0.jar:?] at clojure.core$into.invoke(core.clj:6600) ~[clojure-1.7.0.jar:?] at org.apache.storm.daemon.executor$mk_executor.invoke(executor.clj:372) ~[storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.worker$fn__6779$exec_fn__3235__auto__$reify__6781$iter__6786__6790$fn__6791.invoke(worker.clj:634) ~[storm-core-1.0.0.jar:1.0.0] at clojure.lang.LazySeq.sval(LazySeq.java:40) ~[clojure-1.7.0.jar:?] at clojure.lang.LazySeq.seq(LazySeq.java:49) ~[clojure-1.7.0.jar:?] at clojure.lang.RT.seq(RT.java:507) ~[clojure-1.7.0.jar:?] at clojure.core$seq__4128.invoke(core.clj:137) ~[clojure-1.7.0.jar:?] at clojure.core$dorun.invoke(core.clj:3009) ~[clojure-1.7.0.jar:?] at clojure.core$doall.invoke(core.clj:3025) ~[clojure-1.7.0.jar:?] at org.apache.storm.daemon.worker$fn__6779$exec_fn__3235__auto__$reify__6781.run(worker.clj:634) ~[storm-core-1.0.0.jar:1.0.0] at java.security.AccessController.doPrivileged(Native Method) ~[?:1.8.0_65] at javax.security.auth.Subject.doAs(Subject.java:422) ~[?:1.8.0_65] at org.apache.storm.daemon.worker$fn__6779$exec_fn__3235__auto____6780.invoke(worker.clj:606) ~[storm-core-1.0.0.jar:1.0.0] at clojure.lang.AFn.applyToHelper(AFn.java:178) ~[clojure-1.7.0.jar:?] at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.7.0.jar:?] at clojure.core$apply.invoke(core.clj:630) ~[clojure-1.7.0.jar:?] at org.apache.storm.daemon.worker$fn__6779$mk_worker__6874.doInvoke(worker.clj:580) [storm-core-1.0.0.jar:1.0.0] at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.7.0.jar:?] at org.apache.storm.daemon.supervisor$fn__7647.invoke(supervisor.clj:1200) [storm-core-1.0.0.jar:1.0.0] at clojure.lang.MultiFn.invoke(MultiFn.java:251) [clojure-1.7.0.jar:?] at org.apache.storm.daemon.supervisor$get_valid_new_worker_ids$iter__7208__7212$fn__7213.invoke(supervisor.clj:380) [storm-core-1.0.0.jar:1.0.0] at clojure.lang.LazySeq.sval(LazySeq.java:40) [clojure-1.7.0.jar:?] at clojure.lang.LazySeq.seq(LazySeq.java:49) [clojure-1.7.0.jar:?] at clojure.lang.RT.seq(RT.java:507) [clojure-1.7.0.jar:?] at clojure.core$seq__4128.invoke(core.clj:137) [clojure-1.7.0.jar:?] at clojure.core$dorun.invoke(core.clj:3009) [clojure-1.7.0.jar:?] at clojure.core$doall.invoke(core.clj:3025) [clojure-1.7.0.jar:?] at org.apache.storm.daemon.supervisor$get_valid_new_worker_ids.invoke(supervisor.clj:367) [storm-core-1.0.0.jar:1.0.0] at org.apache.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:428) [storm-core-1.0.0.jar:1.0.0] at clojure.core$partial$fn__4527.invoke(core.clj:2492) [clojure-1.7.0.jar:?] at org.apache.storm.event$event_manager$fn__909.invoke(event.clj:40) [storm-core-1.0.0.jar:1.0.0] at clojure.lang.AFn.run(AFn.java:22) [clojure-1.7.0.jar:?] at java.lang.Thread.run(Thread.java:745) [?:1.8.0_65] 

This behaves as if the jar file did not work in the working directory of the workers. But according to the comment ";; in local mode there is no jar" in Nimbus.clj , this does not seem to be wrong. In version 0.10.0, this problem does not occur . Any ideas?

The problem occurs when I try to start debugging in Intellij using the maven-exec plugin with the following command line configuration (for example, recommended here ):

 compile exec:java -Dstorm.topology=org.apache.storm.starter.WordCountTopology 

from the directory where the POM topology file is located.

UPD : the problem is definitely caused by the absence of any (topological or storm) classes for the workflow when it is initialized. (An attempt by both WordCount and exclamation topologies illustrates this). Games with the coverage of the “storm core” and intuitive profile in the POM-s topology yielded nothing.

+7
java intellij-idea maven-plugin apache-storm
source share
2 answers

I ran my LocalCluster with sbt run , if I run it using java -jar fatjar.jar , everything works fine. While I'm going to work with Intellij, sorting the classpath, I don’t know why sbt behaves strangely when resolving the classpath. Anyone who has any information, please comment!

+4
source share

I found some solution: using the standard Idea startup ideas and functions, Idea works well for explicit Java topologies. But only until execution starts some shell scripts (for example, splitsentece.py). Then it fails with no exception found, so compilation without maven does not seem to be fully functional

+1
source share

All Articles