Hi Jonathan, I've used jruby fairly extensively with storm (though with the trident API), but it's been a while so I'm rusty.
Initializing the jruby runtime is very expensive, so you should do that in the prepare() method of your bolt. That means you'll have to store it as an instance variable in your bolt, which in turn opens the door for potential concurrency issues in your jruby code. Be warned. It can get kind of crazy. I forget what the magic jruby runtime configuration was off hand. But it works. I'll try to unarchive those memories and reply. -Taylor > On Feb 25, 2014, at 10:32 PM, Jonathan Nilsson <[email protected]> > wrote: > > I'm trying to write a Storm Bolt that does some processing with JRuby. When > my data goes through this Bolt I see that the Spout does not appear to be > receiving any acks. I'm pretty sure I'm anchoring my tuples correctly. If I > take the JRuby Bolt out of the topology everything works fine again. In > trying to isolate the problem I wrote a Bolt that does no processing at all > but does call Ruby.getGlobalRuntime(). That call alone seems to be enough to > stop the acks from flowing. I've boiled the execute method down to > > public void execute(Tuple input) { > Ruby.getGlobalRuntime(); > LOG.info("Sending Ack for "+input); > collector.ack(input); > } > > and I get the log message but no messages in the Spout's ack or fail methods. > If I remove the Ruby.getGlobalRuntime(); line everything works. I've tried > using Ruby.getThreadLocalRuntime() but it doesn't seem to make a difference. > Has anyone seen a similar problem? Are there any tricks to calling JRuby code > from within Storm?
