[ https://issues.apache.org/jira/browse/STORM-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14997778#comment-14997778 ]
don lee commented on STORM-605: ------------------------------- In my case, streamparse api were used to run locally and submit code to STORM cluster, and it didn't happen during prepare, when I ran it locally it was ok but when it is submitted to STORM cluster, I got java.lang.RuntimeException: java.lang.IllegalStateException: Attempting to call unbound fn clojure version is 1.5.1, storm version is 0.9.5, sparse 2.1.3 the error was due to calling "call-to-outside-function" within spout execute, and that function can be 3rd party library as well, the code is as follows: (defn call-to-outside-function [someArg] (do stuff ....)) (defspout kw-spout ["something"] [conf context collector] (spout (nextTuple [] (Thread/sleep 100) (call-to-outside-function "someArgs") (emit-spout! collector ("not important")) ) (ack [id]) )) It is related to this bug ? > Attempting to call unbound fn during bolt prepare > ------------------------------------------------- > > Key: STORM-605 > URL: https://issues.apache.org/jira/browse/STORM-605 > Project: Apache Storm > Issue Type: Bug > Components: storm-core > Affects Versions: 0.9.3 > Reporter: Philippe Guillebert > > We had a bunch of topologies running very well under Storm 0.8.2 until last > week when we switched to storm 0.9.2-incubating. We use the clojure DSL, > and clojure 1.5.1 (only). > Since the change, we have a large topology (about 30 bolts, parallellism=10 > or 20 per bolt, total 372 tasks on 10 workers) that fails on startup with > several bolts showing the exception : > java.lang.RuntimeException: java.lang.IllegalStateException: Attempting to > call unbound fn: #'entry-dedup.bolt/dedup__ at > backtype.storm.clojure.ClojureBolt.prepare(ClojureBolt.java:77) ... > This can occur on one or several bolts at random and is not consistent > between restarts. > The topology is indeed quite long to initialize (a dozen seconds) due to > several models being loaded but this was OK in 0.8.2. > Another (shorter) topology works most of the time but shows this behaviour > on some restarts sometimes. > We found a workaround that works most of the time : start the topology in > the INACTIVE state, then wait 200 seconds, then activate it. But this > doesn't really solve our problem because sometimes Storm tries to rebalance > the topologies by itself and reassigns the topology without our little trick, > effectively crashing them. > The same behavior is present with storm 0.9.3. > So maybe something changed in storm that introduces a kind of race > condition during initializaion of some bolts on larger topologies ? Maybe > this is a consequence to the switch to Netty ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)