Github user wangli1426 commented on the issue:
https://github.com/apache/storm/pull/2164
@revans2 I quite agree with you. The current publish logic in disruptor
queue is difficult to follow. It will be great if some one could refine the
code in a separate JIRA, so that we can easily k
May I have look at your storm.yaml file?
Sent from my iPhone
> On 19 Jun 2017, at 23:48, Ritesh Singh wrote:
>
> Hi,
> When I m not modifying the yml file then nimbus is starting fine, but when I
> m modifying yml file then giving error. plz have a look for your reference
> (attach file)
> A
Each bolt/spout has 2 threads of their own. In one thread the bolt/spout
executes on. A second thread then batches/routes the tuples where they need to
go. This may be putting them in the input queue for another bolt/spout in the
current worker or putting them on a queue to be sent to a diffe
Hi,
When I m not modifying the yml file then nimbus is starting fine, but when
I m modifying yml file then giving error. plz have a look for your
reference (attach file)
Also, plz send me the details, if I m missing.
Also, how will start multiple superwiser in same VM.
how will we test the failover
Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/2164
The change as is looks OK to me. My biggest problem with it is that there
is now tight coupling between the Disruptor queue and storm itself, although
looking at the code that was true before.
Github user arunmahadevan commented on the issue:
https://github.com/apache/storm/pull/2162
+1 LGTM
Before you apply this to #1970 and #1950, you can refactor the logic to
make it re-usable across the different state implementations.
---
If your project is set up for it, you
