Github user Ethanlm commented on the issue:
https://github.com/apache/storm/pull/2366
Just ran a very small group of tests:
https://github.com/Ethanlm/STORM-2686-perf-study/commit/50693b938de2321f53655e4039ac8811f963424a
It seems to lead to similar conclusion for these specific
I was hoping we will get 1.2.0 out along with 1.1.2. The pending issues in the
epic https://issues.apache.org/jira/browse/STORM-2710 seems to have been
addressed. Can you add the new issue to the epic?
If its not something critical we can do it in a minor release post 1.2.0.
Thanks,
Arun
On
Github user Ethanlm commented on the issue:
https://github.com/apache/storm/pull/2366
@HeartSaVioR Yea
![image](https://user-images.githubusercontent.com/14900612/31571912-0b879fd2-b061-11e7-9fcb-f84a11eec039.png)
Looking into it
---
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2366
@Ethanlm Ah OK. You talked about the bug you found. OK. Did you also see
the bug without RAS enabled?
---
Github user Ethanlm commented on the issue:
https://github.com/apache/storm/pull/2366
@HeartSaVioR It should be default to worker count. But it's not. There
must be something wrong with the recent code change:
https://github.com/apache/storm/pull/2325 .
I ran topologies with
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2367
I read a mail at dev@ from @hmcl and the talk was not relevant to this
patch. +1 again.
---
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/2366
@Ethanlm
When you don't set topology.acker.executors anywhere it will take default
value which is same as worker count. So the change shouldn't affect the
performance, and if it influences
Github user Ethanlm commented on the issue:
https://github.com/apache/storm/pull/2366
I ran some performance tests using ThroughputVsLatency and the raw results
are available at https://github.com/Ethanlm/STORM-2686-perf-study
The experiments include
| Experiment
I am +1 to releasing 1.1.2 right away. I am in the middle of one review but I
will finish it in the next day, such that we can get this merged soon.
However, we need to hold onto releasing 1.2.0 until some of the changes for
ProcessingGuarantee that got in this
Github user srdo commented on the issue:
https://github.com/apache/storm/pull/2367
I'll merge this weekend if I no one brings up more concerns.
---
Github user asfgit closed the pull request at:
https://github.com/apache/storm/pull/2368
---
I want to say that this is a known issue with checkstyle:check, when you
run the goals directly they don't pick up the configuration from the Storm
pom. As you noted you can use mvn validate instead.
2017-10-13 10:28 GMT+02:00 Jungtaek Lim :
> Hi,
>
> It depends on
Github user govind-menon commented on a diff in the pull request:
https://github.com/apache/storm/pull/2341#discussion_r144578588
--- Diff:
storm-client/src/jvm/org/apache/storm/messaging/netty/NettyUncaughtExceptionHandler.java
---
@@ -33,10 +34,9 @@ public void
I appreciate your suggestions and decide to enable checkstyle first to
get familiar
with code style of storm and building storm.
At the same time, I will try reading some Clojure code in storm-core.
Thanks,
On Fri, Oct 13, 2017 at 3:29 AM, Stig Rohde Døssing
wrote:
>
Hi,
I refer to https://issues.apache.org/jira/browse/STORM-2565 and want to use
checkstyle to get familiar with building Storm.
>From Source Code, I understand that *storm-checkstyle *is custom developed
checkstyle project which is included in all projects as a dependency to the
Checkstyle
15 matches
Mail list logo