[
https://issues.apache.org/jira/browse/STORM-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14482339#comment-14482339
]
Jungtaek Lim commented on STORM-758:
------------------------------------
With design constraints I can think only one approach regarding scenario.
- Let subprocess send 'sync' when each N tuples are being processed
-- If N is smaller, its overhead grows, but we can ensure more stable
Currently I don't want to let N configurable cause it should be passed to
subprocess.
Seems like N = 100 is fine.
(I'm also thinking about 1000. How about this?)
Default value of topology.message.timeout.secs is 30 sec, so it can be safe
that subprocess can handle each tuple with 300 ms.
> Very busy ShellBolt subprocess with Non-ACK mode cannot respond heartbeat
> just in time
> --------------------------------------------------------------------------------------
>
> Key: STORM-758
> URL: https://issues.apache.org/jira/browse/STORM-758
> Project: Apache Storm
> Issue Type: Bug
> Affects Versions: 0.10.0, 0.9.4, 0.11.0
> Reporter: Jungtaek Lim
> Assignee: Jungtaek Lim
> Priority: Critical
>
> As [~dashengju] stated from STORM-738, very busy ShellBolt subprocess cannot
> respond heartbeat just in time.
> Actually it's by design constraint (more details are on STORM-513 or
> STORM-738), but it's better to find a way to avoid.
> My approach with ACK mode is here, STORM-742
> This issue points Non-ACK mode.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
