In our case we prefer to use our own state implementation. After going through 
the code and reading documentation, following is how I understand it. Could you 
please see if my understanding is correct?

1. Derive from State and provide an implementation. In the commit (txID) method 
are we supposed to persists the state by our selves or does the framework take 
care of that? If it is taken care of by the framework, how do we add our own 
persisting mechanism - for example one that use Kafka to persist state?
2. Subclass StateProvider to return State objects for namespaces of interest. 
For example, in our case, we wish to use a custom state class in one of the 
bolts and use defaults for spouts. In this case, is it safe to return custom 
states for the bolt in concern and use the default state provider 
(InMemoryKeyValueStateProvider) for other namespaces? Is the custom provider 
supposed to load last saved state for the namespace in concern from the 
persistent store. Again if state persistence is handled by framework, how do we 
know where to get state from?
3. Are checkpoint related methods called by the same bolt or spout thread?


From: Arun Iyer [] on behalf of Arun Mahadevan 
Sent: Monday, July 24, 2017 2:29 PM
Subject: Re: is stateful bolts production ready?

The bolt just needs to “put” the values into the Key-Value state that the bolt 
gets initialized with during “initState”. The framework automatically takes 
care of saving the state behind the scenes.

Theres an example in storm-starter that you might find useful -<>

You can also find the more elaborate documentation here -<>


From: "Wijekoon, Manusha" 
Reply-To: "<>" 
Date: Monday, July 24, 2017 at 4:04 PM
To: "<>" 
Subject: is stateful bolts production ready?


I am thinking of using stateful bolts to manage state of a bolt. From the 
documentation it is not clear how to save the bolt state however. I understand 
it has to be done when we process the checkpoint tuple, but how? Do I just need 
to update the state object and storm pick it up during three phase commit? How 
does Strom know which state object to pick for check pointing?

I wasn’t able to fine more complete examples either, specifically when we can’t 
keep the state in a kev/value map.

Also, Is this functionality tested in production like environments before?


Reply via email to