Yes, I considered a threadpool, but the confusion was about where to declare them, initiate a thread run and when to join the threads. Any code samples or pseudocode that could help? Besides, there's this thread where a person advises <https://mail-archives.apache.org/mod_mbox/storm-user/201311.mbox/%3CCAAYLz+pUZ44GNsNNJ9O5hjTr2rZLW=CKM=fgvcfwbnw613r...@mail.gmail.com%3E> not using a threadpool.
What exactly is the backpressure <https://issues.apache.org/jira/browse/STORM-431> concept? Is it something about having enough of bolts to process the tuples the spout emits so that acks would be received by the spout on time? On Sun, May 8, 2016 at 5:20 PM, Enno Shioji <eshi...@gmail.com> wrote: > There's nothing that keeps you from simply having a thread pool in your > bolts. Or you could go for an async DB client. > > You will have to be careful about providing back pressure (e.g. by using a > bounded queue). > > On Sun, May 8, 2016 at 12:12 PM, Navin Ipe < > navin....@searchlighthealth.com> wrote: > >> Hi, >> >> I've wanted to do this and this post confirms the idea: >> http://stackoverflow.com/a/36106683/453673 >> But when I have a spout that constantly has nextTuple() being called by >> Storm and I have a bolt that constantly has execute() being called whenever >> it receives a tuple, how do I program the Spout to have a separate thread >> which reads from MongoDB or for the bolt to have a separate thread that >> writes to DB? >> >> If Storm is in complete charge of calling nextTuple() and execute(), then >> how do I start my own thread which does something? This is important, >> because I don't want my bolt to spend time writing to DB, when it should >> actually be busy receiving and processing hundreds of tuples. >> >> -- >> Regards, >> Navin >> > > -- Regards, Navin
