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 [email protected] or file a JIRA ticket
with INFRA.
---
