+1 (binding)
> source
- verify file (signature, MD5, SHA)
-- source, tar.gz : OK
-- source, zip : OK
- extract file
-- source, tar.gz : OK
-- source, zip : OK
- diff-ing extracted files between tar.gz and zip : OK
- build source with JDK 7
-- source, tar.gz :
- build source dist
-
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r130010442
--- Diff:
storm-client/src/jvm/org/apache/storm/serialization/KryoTupleDeserializer.java
---
@@ -39,7 +38,7 @@ public KryoTupleDeserializer(final Map
c
Github user satishd commented on a diff in the pull request:
https://github.com/apache/storm/pull/2218#discussion_r130010224
--- Diff:
storm-client/src/jvm/org/apache/storm/topology/SimpleWindowPartitionCache.java
---
@@ -0,0 +1,191 @@
+/**
+ * Licensed to the Apache Softw
Github user satishd commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r130009889
--- Diff:
storm-client/src/jvm/org/apache/storm/serialization/KryoTupleDeserializer.java
---
@@ -39,7 +38,7 @@ public KryoTupleDeserializer(final Map
conf,
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r130009804
--- Diff:
storm-client/src/jvm/org/apache/storm/serialization/KryoTupleDeserializer.java
---
@@ -39,7 +38,7 @@ public KryoTupleDeserializer(final Map
c
Github user arunmahadevan commented on the issue:
https://github.com/apache/storm/pull/2241
Agree with @HeartSaVioR. If possible lets break this down into multiple
patches like (1) JCQ replacing disruptor (2) changing the threading model (3)
micro optimizations and so on which makes i
Github user arunmahadevan commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r130009128
--- Diff:
storm-client/src/jvm/org/apache/storm/serialization/KryoTupleDeserializer.java
---
@@ -39,7 +38,7 @@ public KryoTupleDeserializer(final Map
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2241
Just leaving a note to make my requirements clear (it is quite simple):
- new system doesn't break anything it worked
- if they're unavoidable it should be discussed from Storm comm
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2200
+1 Nice documentation!
---
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 wishe
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2245
As you may know, you can even just made a change if it was wrong. Now you
also think it's hard to maintain CHANGELOG, let's see how the discussion goes.
---
If your project is set up for it, you
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2245
+1 You can merge this without waiting 24hr.
---
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 feat
correction: other projects -> *some* other projects, though they're popular
projects (including in competition)
2017년 7월 28일 (금) 오전 10:51, Jungtaek Lim 님이 작성:
> I'm happy that there're other guys having same difficult and sharing same
> feeling.
>
> This discussion has been initiating several tim
I'm happy that there're other guys having same difficult and sharing same
feeling.
This discussion has been initiating several times (from me) and getting
some +1s for each thread but didn't reach to actual work.
We already utilize JIRA, and I'm subscribing issues@ and taking care of
issues forgo
Now pull request for STORM-2306 is up, and it looks like requiring several
weeks (months?) to be verified.
IMHO the effort of rebasing is unavoidable (though we could put effort to
minimize), especially pull requests were up already. Unfortunately, that's
about who takes the load, and I don't want
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2241
Btw, I think talking about current state is less meaningful. This patch has
lots of TODO and some critical identified issues, so it should be addressed,
and after that the number is going to be r
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2241
I don't think utilizing metrics consumer in TVL is the issue: it might
matter if results are close so that contributions of other system component
does matter, but it is just not acceptable laten
Github user roshannaik commented on the issue:
https://github.com/apache/storm/pull/2241
@revans2
About that "better than sliced bread" :
how could i not be offended.. at least briefly ;-) but you could buy me
lunch if this PR turns out better than you were initially a
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/2241
@revans2 I am trying to reproduce the worst-case in your last chart.
Running TVL topology with 4 spout, 10 splitters, 4 counters, 2 ackers. Here is
the code
https://gist.github.com/harshach/73d
We already have to keep JIRA updated, and keeping JIRA consistent is easier
since there isn't one view of the resolved issues for each git branch like
we have with CHANGELOG, so there's no worry about e.g. master having a
different opinion on solved issues in 1.2.0 than 1.x-branch has.
I think we
Github user harshach commented on the issue:
https://github.com/apache/storm/pull/2241
@revans2 I am trying to reproduce the worst-case in your last chart.
Running TVL topology with 4 spout, 10 splitters, 4 counters, 2 ackers. Here is
the code
https://gist.github.com/harshach/73d
Github user roshannaik commented on the issue:
https://github.com/apache/storm/pull/2241
Some points covering prev comments by @HeartSaVioR and @revans2
**Throughput limiting:** That only makes sense if you are measuring
Throughput vs CPU/other resource usage. Latency measur
Github user rtandonmsft closed the pull request at:
https://github.com/apache/storm/pull/476
---
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
I am +1 for discontinuing CHANGELOG. However, using JIRA to compile this info
will only work if contributors are very disciplined and consistent updating
JIRA. That leads to the question, is it any easier to maintain JIRA consistent
then it is to keep CHANGELOG consistent? A clean and consistent
Sorry to necro this thread, but I think it's worth bringing this issue up
again. As Jungtaek mentioned a manual changelog is easy to break, and it
looks like some issues are listed wrong on master and missing from 1.x (
https://github.com/apache/storm/pull/2245)
I think dropping CHANGELOG is a gre
Github user roshannaik commented on the issue:
https://github.com/apache/storm/pull/2241
For the new messaging system.. the scaling rule of thumb I have found so
far is quite simple.
For fast topos (and CPU intensive topos) ... 1 executor thread per
*physical core*. It appl
GitHub user srdo opened a pull request:
https://github.com/apache/storm/pull/2245
Restore issues missing from changelog since fb2446075de202387658b0cc8â¦
â¦434ee53ded5d35a
See
https://github.com/apache/storm/commit/fb2446075de202387658b0cc8434ee53ded5d35a
I've gr
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129946825
--- Diff: storm-client/src/jvm/org/apache/storm/Config.java ---
@@ -548,22 +518,14 @@
public static final String
TOPOLOGY_AUTO_TASK_HOOKS="topolo
Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/2241
I have another chart now showing a comparison between master and this
branch, just varying the number of splitter bolts in the topology. There are 2
ackers, 4 spouts, and 4 count bolts all within a
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129945279
--- Diff: storm-client/src/jvm/org/apache/storm/utils/TransferDrainer.java
---
@@ -21,101 +21,100 @@
import java.util.HashMap;
import java.util.
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129938970
--- Diff: storm-client/src/jvm/org/apache/storm/daemon/Task.java ---
@@ -122,28 +130,33 @@ public Task(Executor executor, Integer taskId) throws
IOExcepti
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129937665
--- Diff: storm-client/src/jvm/org/apache/storm/daemon/GrouperFactory.java
---
@@ -137,7 +137,7 @@ public void prepare(WorkerTopologyContext context,
Glo
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129936657
--- Diff: storm-client/src/jvm/org/apache/storm/task/IOutputCollector.java
---
@@ -30,4 +31,5 @@
void ack(Tuple input);
void fail(Tuple
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129934123
--- Diff: conf/defaults.yaml ---
@@ -304,6 +303,7 @@ storm.cgroup.resources:
storm.cgroup.hierarchy.name: "storm"
storm.supervisor.cgroup.rootdir
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129930495
--- Diff: conf/defaults.yaml ---
@@ -231,16 +228,13 @@ topology.multilang.serializer:
"org.apache.storm.multilang.JsonSerializer"
topology.shellbolt.
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129931296
--- Diff: conf/defaults.yaml ---
@@ -231,16 +228,13 @@ topology.multilang.serializer:
"org.apache.storm.multilang.JsonSerializer"
topology.shellbolt.
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129934167
--- Diff:
examples/storm-elasticsearch-examples/src/main/java/org/apache/storm/elasticsearch/common/EsTestUtil.java
---
@@ -43,7 +43,7 @@ public Fields g
Github user roshannaik commented on a diff in the pull request:
https://github.com/apache/storm/pull/2241#discussion_r129934940
--- Diff:
examples/storm-perf/src/main/java/org/apache/storm/perf/ConstSpoutIdBoltNullBoltTopo.java
---
@@ -76,6 +76,8 @@ public static StormTopology get
This vote is now closed and passes with X binding +1 votes and no 0 or -1 votes.
Vote tally (* indicates binding votes):
+1:
Stig Rhode Døssing*
Bobby Evans*
Kishor Patil*
Jungtaek Lim*
P. Taylor Goetz*
I will release the staged artifacts and announce the release after the 24 hour
waiting perio
+1 (binding)
-Taylor
> On Jul 24, 2017, at 2:24 PM, P. Taylor Goetz wrote:
>
> This is a call to vote on releasing Apache Storm 1.0.4 (rc1)
>
> Full list of changes in this release:
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=CHANGELOG.md;h=50878fab679973a1230466920
This is a call to vote on releasing Apache Storm 1.1.1 (rc2)
Full list of changes in this release:
https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=CHANGELOG.md;hb=41bfea87b1a002565333bd18a06d766af1ca3816
The tag/commit to be voted upon is v1.1.1:
https://git-wip-us.apache.org
Github user revans2 commented on the issue:
https://github.com/apache/storm/pull/2241
I have run some more tests looking at modifying the parallelism of
different components.
First I kept the parallelism of everything else at 4 and modified the acker
count.
