Package org.apache.storm.task

Interface IBolt

All Superinterfaces:
Serializable
All Known Subinterfaces:
IRichBolt
All Known Implementing Classes:
AbstractEsBolt, AbstractHdfsBolt, AbstractJdbcBolt, AbstractRedisBolt, Acker, AvroGenericRecordBolt, BaseRichBolt, BaseStatefulBoltExecutor, BaseTickTupleAwareRichBolt, BasicBoltExecutor, BatchBoltExecutor, BlobStoreAPIWordCountTopology.SplitSentence, BoltTracker, CheckpointTupleForwarder, ClojureBolt, CoordinatedBolt, DevNullBolt, EsIndexBolt, EsLookupBolt, EsPercolateBolt, EventLoggerBolt, ExclamationTopology.ExclamationBolt, ExclamationTopology.ExclamationBolt, FluxShellBolt, GenericBolt, HdfsBolt, HdfsFileTopology.MyBolt, HdfsSpoutTopology.ConstBolt, HiveBolt, IdBolt, IdentityBolt, JdbcInsertBolt, JdbcLookupBolt, JmsBolt, JoinResult, KafkaBolt, KafkaSpoutTestBolt, KeyedFairBolt, LoadBolt, LookupWordCount.PrintWordTotalCountBolt, MetricsConsumerBolt, MultipleLoggerTopology.ExclamationLoggingBolt, MultiThreadWordCountTopology.MultiThreadedSplitSentence, NonRichBoltTracker, PersistentWindowedBoltExecutor, PythonShellMetricsBolt, RedisFilterBolt, RedisLookupBolt, RedisStoreBolt, ResourceAwareExampleTopology.ExclamationBolt, ReturnResults, RichShellBolt, RollingCountAggBolt, RollingCountBolt, SequenceFileBolt, SequenceFileTopology.MyBolt, ShellBolt, SingleJoinBolt, SocketBolt, StatefulBoltExecutor, StatefulWindowedBoltExecutor, SystemBolt, TestAggregatesCounter, TestEventOrderCheckBolt, TestGlobalCount, TestPlannerBolt, TridentBoltExecutor, TupleCaptureBolt, WhitelistWordCount.PrintWordTotalCountBolt, WindowedBoltExecutor, WordCountTopology.SplitSentence, WordCountTopologyNode.SplitSentence
public interface IBolt extends Serializable
An IBolt represents a component that takes tuples as input and produces tuples as output. An IBolt can do everything from filtering to joining to functions to aggregations. It does not have to process a tuple immediately and may hold onto tuples to process later.

A bolt's lifecycle is as follows:

IBolt object created on client machine. The IBolt is serialized into the topology (using Java serialization) and submitted to the master machine of the cluster (Nimbus). Nimbus then launches workers which deserialize the object, call prepare on it, and then start processing tuples.

If you want to parameterize an IBolt, you should set the parameters through its constructor and save the parameterization state as instance variables (which will then get serialized and shipped to every task executing this bolt across the cluster).

When defining bolts in Java, you should use the IRichBolt interface which adds necessary methods for using the Java TopologyBuilder API.

  • Method Summary

    Modifier and Type
    Method
    Description
    void
    cleanup()
    Called when an IBolt is going to be shutdown.
    void
    execute(Tuple input)
    Process a single tuple of input.
    void
    prepare(Map<String,Object> topoConf, TopologyContext context, OutputCollector collector)
    Called when a task for this component is initialized within a worker on the cluster.

  • Method Details

    • prepare

      void prepare(Map<String,Object> topoConf, TopologyContext context, OutputCollector collector)
      Called when a task for this component is initialized within a worker on the cluster. It provides the bolt with the environment in which the bolt executes.

      This includes the:

      Parameters:
      topoConf - The Storm configuration for this bolt. This is the configuration provided to the topology merged in with cluster configuration on this machine.
      context - This object can be used to get information about this task's place within the topology, including the task id and component id of this task, input and output information, etc.
      collector - The collector is used to emit tuples from this bolt. Tuples can be emitted at any time, including the prepare and cleanup methods. The collector is thread-safe and should be saved as an instance variable of this bolt object.

    • execute

      void execute(Tuple input)
      Process a single tuple of input. The Tuple object contains metadata on it about which component/stream/task it came from. The values of the Tuple can be accessed using Tuple#getValue. The IBolt does not have to process the Tuple immediately. It is perfectly fine to hang onto a tuple and process it later (for instance, to do an aggregation or join).

      Tuples should be emitted using the OutputCollector provided through the prepare method. It is required that all input tuples are acked or failed at some point using the OutputCollector. Otherwise, Storm will be unable to determine when tuples coming off the spouts have been completed.

      For the common case of acking an input tuple at the end of the execute method, see IBasicBolt which automates this.

      Parameters:
      input - The input tuple to be processed.

    • cleanup

      void cleanup()
      Called when an IBolt is going to be shutdown. Storm will make a best-effort attempt to call this if the worker shutdown is orderly. The Config.SUPERVISOR_WORKER_SHUTDOWN_SLEEP_SECS setting controls how long orderly shutdown is allowed to take. There is no guarantee that cleanup will be called if shutdown is not orderly, or if the shutdown exceeds the time limit.

      The one context where cleanup is guaranteed to be called is when a topology is killed when running Storm in local mode.