Hello! It's due to differences between spout and bolt. In spout, nextTuple is automatically called from Storm, so depending on your configuration but nextTuple in subprocess would be called periodically. That's great for heartbeat.
But bolt is based on event, bolt never calls subprocess when there're no tuples to process. It means idle bolt would kill itself. It's terrible, so I have to introduce multilang protocol's changed. There's other discussions, why not letting subprocess send heartbeat periodically by itself. Surely it's better than current, but it would be not easy because of "multilang", and AFAIK PHP doesn't have real thread so PHP is an example. Hope this helps. Regards. Jungtaek Lim (HeartSaVioR) On 2014년 11월 27일 (목) at 오전 12:35 William Oberman <[email protected]> wrote: > I was reading the release notes for 0.9.3, and STORM-513 concerns me. I'm > using php, which being single threaded will have challenges to respond in a > timely manner to a sync command. I just checked, > and supervisor.worker.timeout.secs defaults to 30 seconds, which I'll have > to sadly increase (globally, unless I use an isolation scheduler? ugh...) > as I have an oddball legacy php-based bolt that can take minutes to process > a Tuple. > > I just looked over the pull request. While this doesn't solve my problem, > is there any reason to not call setHeartbeat() for all responses (ack, > fail, emit, etc...) from the managed subprocess in ShellBolt? I mean, if > the managed subprocess sends *anything* back, that seems as good as a sync > to me. In fact, why bother adding a new protocol command (sync) that broke > all existing multilang implementations when you could have piggybacked on > all of the other messages already coming from the managed subprocess? You > basically did that for ShellSpout... > > I hate to "throw stones", and I'm sure I'm just missing something not > being as deep into the code on the Storm-side. > > Thanks! > > will >
