[jira] [Updated] (STORM-1744) Missing javadoc in Trident code

[ https://issues.apache.org/jira/browse/STORM-1744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Samuel Nelson updated STORM-1744: - Description: Some or most of the core Trident classes don't have javadoc. It makes it really

[jira] [Created] (STORM-1744) Missing javadoc in Trident code

Samuel Nelson created STORM-1744: Summary: Missing javadoc in Trident code Key: STORM-1744 URL: https://issues.apache.org/jira/browse/STORM-1744 Project: Apache Storm Issue Type: Bug

[jira] [Commented] (STORM-1733) Logs from bin/storm are lost because stdout and stderr are not flushed

[ https://issues.apache.org/jira/browse/STORM-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263509#comment-15263509 ] ASF GitHub Bot commented on STORM-1733: --- Github user arunmahadevan commented on the pull request:

[GitHub] storm pull request: STORM-1733 (0.10.x) Flush stdout and stderr be...

Github user arunmahadevan commented on the pull request: https://github.com/apache/storm/pull/1373#issuecomment-215623175 +1 @ptgoetz since you are cutting the 0.10.1 RC, should this wait to merge to 0.10.x branch? --- If your project is set up for it, you can reply to this

[jira] [Commented] (STORM-1733) Logs from bin/storm are lost because stdout and stderr are not flushed

[ https://issues.apache.org/jira/browse/STORM-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263510#comment-15263510 ] ASF GitHub Bot commented on STORM-1733: --- Github user arunmahadevan commented on the pull request:

[GitHub] storm pull request: STORM-1733 (0.1.x) Flush stdout and stderr bef...

Github user arunmahadevan commented on the pull request: https://github.com/apache/storm/pull/1374#issuecomment-215623115 +1 @ptgoetz since you are cutting the 1.0.1 RC, should this wait to merge to 1.x branch? --- If your project is set up for it, you can reply to this email

[GitHub] storm pull request: STORM-1733 Flush stdout and stderr before call...

Github user arunmahadevan commented on the pull request: https://github.com/apache/storm/pull/1360#issuecomment-215622873 Thanks @dsKarthick merged to master. --- 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

[jira] [Commented] (STORM-1358) Porting JStorm multi-thread mode of spout to Storm

[ https://issues.apache.org/jira/browse/STORM-1358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263507#comment-15263507 ] Nisarg Shah commented on STORM-1358: I'll keep a watch for this issue and think it is better to wait

[jira] [Commented] (STORM-1733) Logs from bin/storm are lost because stdout and stderr are not flushed

[ https://issues.apache.org/jira/browse/STORM-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263506#comment-15263506 ] ASF GitHub Bot commented on STORM-1733: --- Github user arunmahadevan commented on the pull request:

[jira] [Commented] (STORM-1733) Logs from bin/storm are lost because stdout and stderr are not flushed

[ https://issues.apache.org/jira/browse/STORM-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263503#comment-15263503 ] ASF GitHub Bot commented on STORM-1733: --- Github user asfgit closed the pull request at:

[GitHub] storm pull request: STORM-1733 Flush stdout and stderr before call...

Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/1360 --- 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

[jira] [Commented] (STORM-1742) More accurate 'complete latency'

[ https://issues.apache.org/jira/browse/STORM-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263468#comment-15263468 ] Jungtaek Lim commented on STORM-1742: - Will go on option 2 since I saw sojourn time at spout send

Re: Thought on complete latency

One way to confirm my assumption is valid, we could use sojourn_time_ms currently provided to queue metrics. We could see sojourn_time_ms in '__receive' metrics of Spout component to verify how long messages from Acker wait from receive queue in Spout. And we also could estimate "waiting time in

[jira] [Created] (STORM-1743) consumerAutoCommitMode not work in storm-kafka-client

Jifeng Yin created STORM-1743: - Summary: consumerAutoCommitMode not work in storm-kafka-client Key: STORM-1743 URL: https://issues.apache.org/jira/browse/STORM-1743 Project: Apache Storm Issue

[jira] [Commented] (STORM-1742) More accurate 'complete latency'

[ https://issues.apache.org/jira/browse/STORM-1742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263433#comment-15263433 ] Jungtaek Lim commented on STORM-1742: - About option 1, I found some answers / articles claiming there

[jira] [Created] (STORM-1742) More accurate 'complete latency'

Jungtaek Lim created STORM-1742: --- Summary: More accurate 'complete latency' Key: STORM-1742 URL: https://issues.apache.org/jira/browse/STORM-1742 Project: Apache Storm Issue Type: Improvement

[GitHub] storm pull request: add convenience methods for checking tuple typ...

GitHub user daluu opened a pull request: https://github.com/apache/storm/pull/1378 add convenience methods for checking tuple type Convenience methods for checking if tuple is tick or heartbeat tuple to match python version, also fix some comment typos. You can merge this pull

[jira] [Commented] (STORM-1278) port backtype.storm.daemon.worker to java

[ https://issues.apache.org/jira/browse/STORM-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15263373#comment-15263373 ] Jark Wu commented on STORM-1278: Yes, I have done some of it. But as worker depends on executor, so I'm

Re: Thought on complete latency

Roshan, Thanks for sharing your thought. About your thoughts I'm in favor of 1), that's what my sketch is trying to achieve. If we agree to go on 1), IMO the options I stated are clear. Let me elaborate more. Root tuple has been made from "Spout" and on definition of 'complete latency' tuple

Re: Thought on complete latency

IMO, avoiding the time variation on machines makes total sense. But I feel that this is a tricky question. Couple more thoughts: 1) As per http://storm.apache.org/releases/current/Guaranteeing-message-processing.ht ml "Storm can detect when the tree of tuples is fully processed and can ack

[jira] [Commented] (STORM-1733) Logs from bin/storm are lost because stdout and stderr are not flushed

[ https://issues.apache.org/jira/browse/STORM-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262712#comment-15262712 ] ASF GitHub Bot commented on STORM-1733: --- Github user dsKarthick commented on the pull request:

[GitHub] storm pull request: STORM-1733 Flush stdout and stderr before call...

Github user dsKarthick commented on the pull request: https://github.com/apache/storm/pull/1360#issuecomment-215525229 @vesense Closed 0.9.x PR. thanks. --- 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

[jira] [Commented] (STORM-1733) Logs from bin/storm are lost because stdout and stderr are not flushed

[ https://issues.apache.org/jira/browse/STORM-1733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262653#comment-15262653 ] ASF GitHub Bot commented on STORM-1733: --- Github user dsKarthick closed the pull request at:

[GitHub] storm pull request: STORM-1733 (0.9.x) Flush stdout and stderr bef...

Github user dsKarthick closed the pull request at: https://github.com/apache/storm/pull/1372 --- 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

[jira] [Commented] (STORM-1278) port backtype.storm.daemon.worker to java

[ https://issues.apache.org/jira/browse/STORM-1278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262647#comment-15262647 ] Abhishek Agarwal commented on STORM-1278: - [~jark] Have you started working on this? Do you mind

[jira] [Commented] (STORM-1276) port backtype.storm.daemon.nimbus to java

[ https://issues.apache.org/jira/browse/STORM-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262644#comment-15262644 ] Abhishek Agarwal commented on STORM-1276: - Sounds like a good idea. Let me know which parts you

[GitHub] storm pull request: STORM-1741: remove unconditional setting of JA...

Github user erikdw commented on a diff in the pull request: https://github.com/apache/storm/pull/1377#discussion_r61466360 --- Diff: conf/storm-env.sh --- @@ -19,6 +19,6 @@ # Set Storm specific environment variables here. # The java implementation to use.

[GitHub] storm pull request: STORM-1741: remove unconditional setting of JA...

GitHub user ptgoetz opened a pull request: https://github.com/apache/storm/pull/1377 STORM-1741: remove unconditional setting of JAVA_HOME from storm-env.sh You can merge this pull request into a Git repository by running: $ git pull https://github.com/ptgoetz/storm

[jira] [Created] (STORM-1741) storm-env.sh unconditionally sets JAVA_HOME

P. Taylor Goetz created STORM-1741: -- Summary: storm-env.sh unconditionally sets JAVA_HOME Key: STORM-1741 URL: https://issues.apache.org/jira/browse/STORM-1741 Project: Apache Storm Issue

[jira] [Updated] (STORM-1741) storm-env.sh unconditionally sets JAVA_HOME

[ https://issues.apache.org/jira/browse/STORM-1741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P. Taylor Goetz updated STORM-1741: --- Priority: Blocker (was: Major) > storm-env.sh unconditionally sets JAVA_HOME >

[jira] [Updated] (STORM-841) Thread-safeness of OutputCollector has documented contrary to two official doc.

[ https://issues.apache.org/jira/browse/STORM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P. Taylor Goetz updated STORM-841: -- Affects Version/s: (was: 2.0.0) (was: 1.0.0) > Thread-safeness of

[jira] [Commented] (STORM-841) Thread-safeness of OutputCollector has documented contrary to two official doc.

[ https://issues.apache.org/jira/browse/STORM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262459#comment-15262459 ] P. Taylor Goetz commented on STORM-841: --- Okay, cool. I didn't realize the old shuffle grouping was

[CANCELED] [VOTE] Release Apache Storm 1.0.1 (rc2)

Canceling the vote to address the issue raised. -Taylor > On Apr 28, 2016, at 11:51 AM, Harsha wrote: > > storm-env.sh introduced if users want override any environment > variables. we can either comment out the line as default or what Taylor > proposed looks good too. >

Thought on complete latency

Hi devs, While thinking about metrics improvements, I doubt how many users know that what 'exactly' is complete latency. In fact, it's somewhat complicated because additional waiting time could be added to complete latency because of single-thread model event loop of spout. Long running

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

storm-env.sh introduced if users want override any environment variables. we can either comment out the line as default or what Taylor proposed looks good too. -Harsha On Thu, Apr 28, 2016, at 08:27 AM, P. Taylor Goetz wrote: > HDP uses storm-env.sh, which is where it came from. That makes sense

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

HDP uses storm-env.sh, which is where it came from. That makes sense because I’ve noticed HDP builds exhibit the same issue. That line in storm-env.sh should probably be: if [ -n "$JAVA_HOME" ]; then export JAVA_HOME=${JAVA_HOME}; fi The fastest route would be to simply revert STORM-1706, but

[jira] [Commented] (STORM-841) Thread-safeness of OutputCollector has documented contrary to two official doc.

[ https://issues.apache.org/jira/browse/STORM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262275#comment-15262275 ] Robert Joseph Evans commented on STORM-841: --- When is it not thread safe any more? I thought the

[jira] [Updated] (STORM-841) Thread-safeness of OutputCollector has documented contrary to two official doc.

[ https://issues.apache.org/jira/browse/STORM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P. Taylor Goetz updated STORM-841: -- Affects Version/s: 2.0.0 0.9.6 1.0.0

[jira] [Reopened] (STORM-841) Thread-safeness of OutputCollector has documented contrary to two official doc.

[ https://issues.apache.org/jira/browse/STORM-841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P. Taylor Goetz reopened STORM-841: --- This change somehow got reverted and the documentation for all versions claims OutputCollector is

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

Yeah, great finding. I agree it's critical so we should take an action. 1. storm-env.sh should be fixed to not re-set JAVA_HOME (btw, what exactly is the meaning?) 2. rename storm-env.sh to storm-env.sh.example (and also apply 1) 3. just revert STORM-1706. Anything would be fine for me. 2016년

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

STORM-1706 introduced it. Before 1.0.1 we weren’t including `storm-env.sh`. That file does the following: export JAVA_HOME=${JAVA_HOME} Which, if JAVA_HOME is not set, will set it, but leave it empty. So the clj `if (nil? java-home)` will evaluate to false and we’ll end up with `/bin/java` as

[jira] [Commented] (STORM-1740) Storm on mesos and yarn

[ https://issues.apache.org/jira/browse/STORM-1740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262161#comment-15262161 ] Robert Joseph Evans commented on STORM-1740: That is fine with me in some use cases, but we

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

Yeah, that section hasn’t changed. I think it’s a change further up the stack. > On Apr 28, 2016, at 9:05 AM, Jungtaek Lim wrote: > > It's here. > > (defn jvm-cmd [cmd] > (let [java-home (.get (System/getenv) "JAVA_HOME")] >(if (nil? java-home) > cmd > (str

[GitHub] storm pull request: minor: improved documenation layout

Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/1363 --- 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

[GitHub] storm pull request: minor: improved documenation layout

Github user HeartSaVioR commented on the pull request: https://github.com/apache/storm/pull/1363#issuecomment-215417302 +1 Go ahead merging. Thanks for your work. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

It's here. (defn jvm-cmd [cmd] (let [java-home (.get (System/getenv) "JAVA_HOME")] (if (nil? java-home) cmd (str java-home file-path-separator "bin" file-path-separator cmd If JAVA_HOME isn't set to system environment, it may works as what we want. But if it's set to empty

[GitHub] storm pull request: minor: improved documenation layout

Github user mjsax commented on the pull request: https://github.com/apache/storm/pull/1363#issuecomment-215415879 I nobody objects, I will merge this. --- 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

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

> On Apr 28, 2016, at 2:30 AM, Jungtaek Lim wrote: > > - if we don't set JAVA_HOME, supervisor runs "/bin/java" instead of "java" > when it launches worker with non-secure mode. That seems like a regression we don't want. I'll look into where that came from -Taylor

[jira] [Commented] (STORM-1276) port backtype.storm.daemon.nimbus to java

[ https://issues.apache.org/jira/browse/STORM-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15262072#comment-15262072 ] Basti Liu commented on STORM-1276: -- [~abhishek.agarwal] thanks for the reminding. I have been busy on the

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

+1 (Non binding) src distribution - Retrieved source archive and built using 'mvn clean install -P all-tests’ - Built the binary package from the above source archive bin distribution - Checked Release notes etc. - Ran different topologies in local cluster - Created a 3 node cluster

[jira] [Commented] (STORM-1276) port backtype.storm.daemon.nimbus to java

[ https://issues.apache.org/jira/browse/STORM-1276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261881#comment-15261881 ] Abhishek Agarwal commented on STORM-1276: - [~basti.lj] If you are not woking on this right now, do

[GitHub] storm pull request: STORM-1727: add storm 1.0.0 rename note

Github user abhishekagarwal87 commented on the pull request: https://github.com/apache/storm/pull/1358#issuecomment-215360850 Agree with @HeartSaVioR - This should be added to the 1.0 release announcement page. --- If your project is set up for it, you can reply to this email and

[jira] [Commented] (STORM-1727) add storm 1.0.0 rename note

[ https://issues.apache.org/jira/browse/STORM-1727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15261817#comment-15261817 ] ASF GitHub Bot commented on STORM-1727: --- Github user abhishekagarwal87 commented on the pull

Re: [VOTE] Release Apache Storm 0.10.1 (rc2)

+1 (binding) - testing with source distribution : OK - unzip : OK - building from source dist : OK - how to build: running `mvn -P all-tests clean install` on unzipped source dist. - testing with binary distribution (one machine) : OK - launch daemons : OK - run RollingTopWords

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

+1 (binding) - testing with source distribution : OK - unzip : OK - building from source dist : OK - how to build: running `mvn -P all-tests clean install` on unzipped source dist. - testing with binary distribution (one machine) : OK - launch daemons : OK - run RollingTopWords

Re: [VOTE] Release Apache Storm 1.0.1 (rc2)

+1 (Non binding) - testing with binary distribution (one machine) : OK - launch daemons : OK - run RollingTopWords (local) : OK - run RollingTopWords (remote) : OK - activate / deactivate / rebalance / kill : OK - logviewer (worker dir, daemon dir) : OK - change log level : OK