You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@storm.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2014/08/18 00:00:19 UTC
[jira] [Commented] (STORM-406) Trident topologies getting stuck
when using Netty transport (reproducible)
[ https://issues.apache.org/jira/browse/STORM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100139#comment-14100139 ]
ASF GitHub Bot commented on STORM-406:
--------------------------------------
GitHub user Parth-Brahmbhatt opened a pull request:
https://github.com/apache/incubator-storm/pull/230
STORM-406: Fix for storm CSRF vulnerability using ring-anti-forgery.
I have tested the ui in 36.0.1985.143 and firefox-24.0. That said, I know pretty much nothing about ui , css or javascript so any comments will be helpful.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Parth-Brahmbhatt/incubator-storm STORM-406
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-storm/pull/230.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #230
----
commit 576726292a88c67aa9e9ba7563de114540487f54
Author: Parth Brahmbhatt <br...@gmail.com>
Date: 2014-08-17T21:56:27Z
STORM-406: Fix for storm CSRF vulnerability using ring-anti-forgery.
----
> Trident topologies getting stuck when using Netty transport (reproducible)
> --------------------------------------------------------------------------
>
> Key: STORM-406
> URL: https://issues.apache.org/jira/browse/STORM-406
> Project: Apache Storm (Incubating)
> Issue Type: Bug
> Affects Versions: 0.9.2-incubating, 0.9.1-incubating, 0.9.0.1
> Environment: Linux, OpenJDK 7
> Reporter: Danijel Schiavuzzi
> Assignee: Kishor Patil
> Priority: Blocker
> Labels: b
> Fix For: 0.9.3-incubating
>
>
> When using the new, default Netty transport, Trident topologies sometimes get stuck, while under ZeroMQ everything is working fine.
> I can reliably reproduce this issue by killing a Storm worker on a running Trident topology. If the worker gets re-spawned on the same slot (port), the topology stops processing. But if the worker re-spawns on a different port, topology processing continues normally.
> The Storm cluster configuration is pretty standard, there are two Supervisor nodes, one node has also Nimbus, UI and DRPC running on it. I have four slots per Supervisor, and run my test topology with setNumWorkers set to 8 so that it occupies all eight slots across the cluster. Killing a worker in this configuration will always re-spawn the worker on the same node and slot (port), thus causing the topology to stop processing. This is 100% reproducible on a few Storm clusters of mine, across multiple Storm versions (0.9.0.1, 0.9.1, 0.9.2).
> I have reproduced this with multiple Trident topologies, the simplest of which is the TridentWordCount topology from storm-starter. I've just modified it a little to add an additional Trident filter to log the tuple throughput: https://github.com/dschiavu/storm-trident-stuck-topology
> Non-transactional Trident topologies just silently stop processing, while transactional topologies continuously retry the batches and are re-emitted by the spout, however they never get processed by the next bolts in the chain so they time out.
--
This message was sent by Atlassian JIRA
(v6.2#6252)