We were able to quickly get a Storm cluster running in our test
environment yesterday, and have successfully run Java-only test
topologies.
However, submitting the word-count example gave us the error below
(full error at bottom of this message):
===
java.lang.RuntimeException: java.lang.RuntimeException:
java.io.IOException: Cannot run program "/usr/bin/python" (in
directory "/ebs_data/storm/data/stormdist/word-count-4-1316610254/resources"):
java.io.IOException: error=2, No such file or directory
[snip]
===
/ebs_data/storm/data/ is our 'storm.local.dir'.
On investigation, it seems that 'resources' in
'stormdist/word-count-4-1316610254/' does not exist. I presume that
'resources' should have been extracted from the JAR file (confirmed
that it does exist in the JAR - I'm able to extract it manually) to
provide splitsentence.py and storm.py.
I'm using the File | Export | ... JAR File method in Eclipse
(remembering to include the resources).
Any thoughts on whether this is a problem with our JAR file creation
(in which case - what's the best way to do it?) or something wrong on
our production setup?
A
====
The full error:
2011-09-21 13:21:54 worker [ERROR] Error on initialization of server mk-worker
java.lang.RuntimeException: java.lang.RuntimeException:
java.io.IOException: Cannot run program "/usr/bin/python" (in
directory "/ebs_data/storm/data/stormdist/word-count-4-1316610254/resources"):
java.io.IOException: error=2, No such file or directory
at clojure.lang.LazySeq.sval(LazySeq.java:47)
at clojure.lang.LazySeq.seq(LazySeq.java:56)
at clojure.lang.RT.seq(RT.java:450)
at clojure.core$seq.invoke(core.clj:122)
at clojure.core$dorun.invoke(core.clj:2450)
at clojure.core$doall.invoke(core.clj:2465)
at backtype.storm.daemon.worker$fn__2916$exec_fn__837__auto____2917.invoke(worker.clj:169)
at clojure.lang.AFn.applyToHelper(AFn.java:180)
at clojure.lang.AFn.applyTo(AFn.java:151)
at clojure.core$apply.invoke(core.clj:540)
at backtype.storm.daemon.worker$fn__2916$mk_worker__3058.doInvoke(worker.clj:78)
at clojure.lang.RestFn.invoke(RestFn.java:483)
at backtype.storm.daemon.worker$_main.invoke(worker.clj:254)
at clojure.lang.AFn.applyToHelper(AFn.java:174)
at clojure.lang.AFn.applyTo(AFn.java:151)
at backtype.storm.daemon.worker.main(Unknown Source)
Caused by: java.lang.RuntimeException: java.io.IOException: Cannot run
program "/usr/bin/python" (in directory
"/ebs_data/storm/data/stormdist/word-count-4-1316610254/resources"):
java.io.IOException: error=2, No such file or directory
at backtype.storm.task.ShellBolt.initializeSubprocess(ShellBolt.java:83)
at backtype.storm.task.ShellBolt.prepare(ShellBolt.java:89)
at backtype.storm.daemon.task$fn__2867.invoke(task.clj:456)
at clojure.lang.MultiFn.invoke(MultiFn.java:194)
at backtype.storm.daemon.task$mk_task.invoke(task.clj:275)
at backtype.storm.daemon.worker$fn__2916$exec_fn__837__auto____2917$iter__2962__2966$fn__2967$fn__2968.invoke(worker.clj:169)
at backtype.storm.daemon.worker$fn__2916$exec_fn__837__auto____2917$iter__2962__2966$fn__2967.invoke(worker.clj:169)
at clojure.lang.LazySeq.sval(LazySeq.java:42)
... 15 more
Caused by: java.io.IOException: Cannot run program "/usr/bin/python"
(in directory "/ebs_data/storm/data/stormdist/word-count-4-1316610254/resources"):
java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:460)
at backtype.storm.task.ShellBolt.initializeSubprocess(ShellBolt.java:74)
... 22 more
Caused by: java.io.IOException: java.io.IOException: error=2, No such
file or directory
at java.lang.UNIXProcess.<init>(UNIXProcess.java:148)
at java.lang.ProcessImpl.start(ProcessImpl.java:65)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:453)
... 23 more
That's what it looked like... I'll run a couple of experiments
tomorrow now we have ant generating jars.
It wasn't, but it is now. I've restarted the supervisors and
redeployed the topology - same problem. Manually executing the unzip
command as the same user as the supervisor creates the resources
directory as expected and the topology is able to start, so the
problem must lie with executing unzip within the supervisor.
> Also, can you check the supervisor logs for any messages of the form
> "Error when trying to extract ..."?
Nothing.
I don't have a Clojure dev setup here at the moment (and this is the
first time I've had a look at code in Clojure) so figuring out exactly
what is wrong may be a bit tricky :) Any further hints appreciated!
Yes, that works (JAR-PATH is a jar in the 'inbox' directory and
EXTRACT-LOCATION is sourced from the error message when python fails
to execute).
> Finally, what OS are you running Storm on?
Ubuntu 10.10.
Will investigate supervisor paths etc.
2011-09-23 11:43:54 supervisor [INFO] Launching worker with assignment
#:backtype.storm.daemon.supervisor.LocalAssignment{:storm-id
"word-count-3-1316778233", :task-ids (1 2 3 4 5 6 7 8 9 10)} for this
supervisor 9b209e0f-67bb-4523-99cc-e04cba516ccf on port 6700 with id
1d66e4f7-7b0f-4a52-8fe2-3bcb05bf9fd8
2011-09-23 11:43:54 supervisor [INFO]
1d66e4f7-7b0f-4a52-8fe2-3bcb05bf9fd8 still hasn't started
2011-09-23 11:43:54 event [ERROR] Error when processing event
backtype.storm.daemon.supervisor$fn__3298$exec_fn__837__auto____3299$sync_processes__3301@5ffe40d5
java.lang.NullPointerException
at backtype.storm.utils.VersionedStore.listDir(VersionedStore.java:161)
at backtype.storm.utils.VersionedStore.getAllVersions(VersionedStore.java:119)
at backtype.storm.utils.VersionedStore.mostRecentVersion(VersionedStore.java:43)
at backtype.storm.utils.VersionedStore.mostRecentVersionPath(VersionedStore.java:31)
at backtype.storm.utils.LocalState.snapshot(LocalState.java:22)
at backtype.storm.utils.LocalState.get(LocalState.java:28)
at backtype.storm.daemon.supervisor$wait_for_worker_launch.invoke(supervisor.clj:116)
at backtype.storm.daemon.supervisor$wait_for_workers_launch.invoke(supervisor.clj:132)
at backtype.storm.daemon.supervisor$fn__3298$exec_fn__837__auto____3299$sync_processes__3301.invoke(supervisor.clj:218)
at backtype.storm.event$event_manager$fn__1750$fn__1751.invoke(event.clj:25)
At which point the supervisor stops and is picked back up by monit.
I also see a number of exceptions after killing a running topology
(although they look like they are not directly related):
2011-09-23 11:44:00 supervisor [ERROR] Failed to cleanup worker
72397b9d-3c85-4bb9-89c7-2678d86f4939. Will retry later
java.lang.RuntimeException: Failed to delete
/ebs_data/storm/data/workers/72397b9d-3c85-4bb9-89c7-2678d86f4939/pids
at backtype.storm.util$rmpath.invoke(util.clj:263)
at backtype.storm.daemon.supervisor$try_cleanup_worker.invoke(supervisor.clj:142)
at backtype.storm.daemon.supervisor$shutdown_worker.invoke(supervisor.clj:158)
at backtype.storm.daemon.supervisor$fn__3298$exec_fn__837__auto____3299$sync_processes__3301.invoke(supervisor.clj:206)
at backtype.storm.event$event_manager$fn__1750$fn__1751.invoke(event.clj:25)
at backtype.storm.event$event_manager$fn__1750.invoke(event.clj:22)
at clojure.lang.AFn.run(AFn.java:24)
at java.lang.Thread.run(Thread.java:662)
The directory it is trying to delete doesn't actually exist. If I
create it, it gets deleted again but still says it hasn't deleted it.
It continues to repeat that error/exception on a loop every few
seconds.
A
I'll look into sandboxing and permissions issues when I come back to
it. Most of our code is Java only and it's working really well for
that so far.
> Are you on AWS by any chance (I ask because one of your paths says
> "ebs")? If so, you can deploy a cluster using the storm deploy for AWS
> ( https://github.com/nathanmarz/storm-deploy ) which should solve all
> your issues.
storm-deploy was next on my list of things to look at, but we have a
large investment in our existing AWS infrastructure, which includes
ZooKeeper and monitoring systems, so would like to get storm working
with those systems.
I'll report back on what we find - we're using a standard maverick AMI
with custom-rolled APT packages to deploy code.
Thanks for all your work, storm is just what we needed!
I've come back to this today (our Java topologies are running fine,
but now we have some Python we need to add!)
In one of the other threads you mentioned that nimbus and supervisor
needed separate directories - we were using the same directory for
both with one of our supervisors co-located with nimbus. Stopping that
supervisor to force allocation on another machine has solved the
problem.
I was wondering why they need separate directories? Is it
straightforward to split the configuration so they can be co-located
without installing two copies of storm with different configs?