Github user roshannaik commented on the issue: https://github.com/apache/storm/pull/2241 @avermeer Looks like SuperChief blog is relaying the same basic claims that Heron has marketed. Since you ask, i will share my opinions wrt Heron's claims. - Heron has never been a player in the high performance club. They have been smart about not comparing themselves with the real top performers of the day. I only included them here because they have built they have made much noise against Storm. They are smart about not mentioning which version of Storm they are comparing with (how does a paper with such critical info missing get accepted ?). That creates an illusion in people that their perf claims apply to all versions of Storm in general... even if Storm [publishes new perf numbers](hortonworks.com/blog/microbenchmarking-storm-1-0-performance/) comparing itself to a prior version. - Heron's threading model (1 thread per process.. based on what i gather from their articles), is really primitive for this application domain. I don't recommend it, but by setting 'topology.workers' equal to the number of spout& bolt instances, Storm can be run in Heron mode. - I find it much easier to debug a process with multiple components using a debugger rather start a separate debugger for every instance of spout bolt running. Also, I would imagine, having so many processes means you have an explosion of log files to deal with when triaging. - Unclear why the recovery model (when worker process crashes) is any better ... the same kind of replay from the spout would be required. The gains may be minor if any. Making minor optimizations to the failure path and penalizing the normal operation path... is backwards. - Cant get a stack from a Storm worker ? Thats clearly false. Try it yourself. I do it all the time. Heapdumps, on the other hand, can stall the worker and if the heap size is really large the supervisor might feel the worker is having a problem. There are timeouts that you can increase to for the supervisor to wait longer. I cant imagine that Heron doesn't monitor their workers and restart them if they are not responsive. - Heron's Backpressure model is simply too overweight, but marketed as a novel idea. - A quick read of their latest perf blog, noted in the comparison, and it was evident that they missed recognizing their real perf problem.
--- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---