[GitHub] storm pull request: Storm-166: Nimbus HA design doc and implementa...
Github user Parth-Brahmbhatt commented on the pull request: https://github.com/apache/storm/pull/354#issuecomment-83786134 @revans2 @harshach @ptgoetz upmerged to master one more time and this time it took me a lot longer due to my own changes (rolling upgrade support and run as user support). I would like to mention that since last 3-4 commits I have only tested locally by running mvn clean install and running wordcount topology. Given the number of changes, I will try to re-test the HA test cases and rolling upgrade test cases one more time in my vagrant setup and update the PR. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (STORM-695) storm CLI tool reports zero exit code on error scenario, take 2
[
https://issues.apache.org/jira/browse/STORM-695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14369278#comment-14369278
]
ASF GitHub Bot commented on STORM-695:
--
Github user Lewuathe commented on the pull request:
https://github.com/apache/storm/pull/456#issuecomment-83543346
@revans2 @HeartSaVioR Thank you for reviewing.
We should not distinguish error types with exit code. So JVM return code
informs us the occurrence of some exception, I'll update to return exit code 1
when any exception has been occurred.
storm CLI tool reports zero exit code on error scenario, take 2
---
Key: STORM-695
URL: https://issues.apache.org/jira/browse/STORM-695
Project: Apache Storm
Issue Type: Bug
Affects Versions: 0.9.3
Reporter: Michael Noll
Assignee: Kai Sasaki
Priority: Minor
Commands such as storm kill non-existing-topology will return an exit code
of zero, indicating success when in fact the command failed.
h3. How to reproduce
Here is but one example where the {{storm}} CLI tool violates shell best
practices:
{code}
# Let's kill a topology that is in fact not running in the cluster.
$ storm kill i-do-not-exist-topo
snip
Exception in thread main NotAliveException(msg:i-do-not-exist-topo is not
alive)
# Print the exit code of last command.
$ echo $?
0 # but since the kill command failed this should be non-zero!
{code}
Another example is the storm jar command. If you attempt to submit a
topology that has the same name as an existing, running topology, the storm
jar command will not submit the topology -- instead it will print an
exception (think: the topology FooName is already running), which is ok,
but it will then exit with a return code of zero, which indicates success
(which is wrong).
h3. Impact
This bug prevents automated deployment tools such as Ansible or Puppet as
well as ad-hoc CLI scripting (think: fire-fighting Ops teams) to work
properly because Storm violates shell conventions by not returning non-zero
exit codes in case of failures.
h3. How to fix
From what I understand the solution is two-fold:
# The various Storm commands that are being called by the {{storm}} script
must return proper exit codes.
# The {{storm}} script must store these exit codes and return itself with the
respective exit code of the Storm command it actually ran.
For example, here's the current code that implements the storm kill command:
{code}
# In: bin/storm
def kill(*args):
Syntax: [storm kill topology-name [-w wait-time-secs]]
Kills the topology with the name topology-name. Storm will
first deactivate the topology's spouts for the duration of
the topology's message timeout to allow all messages currently
being processed to finish processing. Storm will then shutdown
the workers and clean up their state. You can override the length
of time Storm waits between deactivation and shutdown with the -w flag.
exec_storm_class(
backtype.storm.command.kill_topology,
args=args,
jvmtype=-client,
extrajars=[USER_CONF_DIR, STORM_BIN_DIR])
{code}
which in turn calls the following code in {{kill_topology.clj}}:
{code}
;; In: backtype.storm.command.kill-topology
(ns backtype.storm.command.kill-topology
(:use [clojure.tools.cli :only [cli]])
(:use [backtype.storm thrift config log])
(:import [backtype.storm.generated KillOptions])
(:gen-class))
(defn -main [ args]
(let [[{wait :wait} [name] _] (cli args [-w --wait :default nil
:parse-fn #(Integer/parseInt %)])
opts (KillOptions.)]
(if wait (.set_wait_secs opts wait))
(with-configured-nimbus-connection nimbus
(.killTopologyWithOpts nimbus name opts)
(log-message Killed topology: name)
)))
{code}
which in turn calls the following code in {{nimbus.clj}}:
{code}
;; In: backtype.storm.daemon.nimbus
(^void killTopologyWithOpts [this ^String storm-name ^KillOptions
options]
(check-storm-active! nimbus storm-name true)
(let [topology-conf (try-read-storm-conf-from-name conf storm-name
nimbus)]
(check-authorization! nimbus storm-name topology-conf
killTopology))
(let [wait-amt (if (.is_set_wait_secs options)
(.get_wait_secs options)
)]
(transition-name! nimbus storm-name [:kill wait-amt] true)
))
{code}
As you can see the current implementation does not pass success/failure
information back to the caller.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] storm pull request: [STORM-695] storm CLI tool reports zero exit c...
Github user Lewuathe commented on the pull request: https://github.com/apache/storm/pull/456#issuecomment-83543346 @revans2 @HeartSaVioR Thank you for reviewing. We should not distinguish error types with exit code. So JVM return code informs us the occurrence of some exception, I'll update to return exit code 1 when any exception has been occurred. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] storm pull request: Storm-166: Nimbus HA design doc and implementa...
Github user ptgoetz commented on the pull request: https://github.com/apache/storm/pull/354#issuecomment-83850291 +1 I'll proceed with crating the necessary branches. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (STORM-638) UI should show up process-id of the Worker to which an Executor is assigned
[ https://issues.apache.org/jira/browse/STORM-638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370781#comment-14370781 ] ASF GitHub Bot commented on STORM-638: -- Github user vesense commented on the pull request: https://github.com/apache/storm/pull/396#issuecomment-83920789 unnecessary UI should show up process-id of the Worker to which an Executor is assigned Key: STORM-638 URL: https://issues.apache.org/jira/browse/STORM-638 Project: Apache Storm Issue Type: Bug Affects Versions: 0.10.0 Reporter: caofangkun Assignee: caofangkun Priority: Minor Attachments: with process id.png -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: Storm-166: Nimbus HA design doc and implementa...
Github user vesense commented on the pull request: https://github.com/apache/storm/pull/354#issuecomment-83840369 +1 looks good to me. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] storm pull request: STORM-638:UI should show up process-id of the ...
Github user vesense commented on the pull request: https://github.com/apache/storm/pull/396#issuecomment-83920789 unnecessary --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (STORM-713) Storm Kafka Metrics Don't Include Topic
[ https://issues.apache.org/jira/browse/STORM-713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14369747#comment-14369747 ] ASF GitHub Bot commented on STORM-713: -- Github user chawco commented on the pull request: https://github.com/apache/storm/pull/470#issuecomment-83682537 Sure thing, I've filed [STORM-713 ](https://issues.apache.org/jira/browse/STORM-713) for this issue. Storm Kafka Metrics Don't Include Topic --- Key: STORM-713 URL: https://issues.apache.org/jira/browse/STORM-713 Project: Apache Storm Issue Type: Bug Components: storm-kafka Affects Versions: 0.9.3, 0.10.0 Reporter: Craig Hawco Assignee: Craig Hawco Priority: Minor Storm Kafka does a good job of tracking internal metrics, such as spout backlog (spoutLag), and contains both aggregate and per-partition values. Unfortunately, this data is not tied to a specific topic, and provides no way to disambiguate between multiple topics when more than one spout is present. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: Include topic information with Kafka metrics
Github user chawco commented on the pull request: https://github.com/apache/storm/pull/470#issuecomment-83682537 Sure thing, I've filed [STORM-713 ](https://issues.apache.org/jira/browse/STORM-713) for this issue. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] storm pull request: Include topic information with Kafka metrics
Github user chawco commented on the pull request: https://github.com/apache/storm/pull/470#issuecomment-83695774 I've amended the offending commit. 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 does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] storm pull request: STORM-691 Add basic lookup / persist bolts
Github user ptgoetz commented on the pull request: https://github.com/apache/storm/pull/451#issuecomment-83732719 +1 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (STORM-691) [storm-redis] Add basic lookup / persist bolts
[ https://issues.apache.org/jira/browse/STORM-691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14369969#comment-14369969 ] ASF GitHub Bot commented on STORM-691: -- Github user ptgoetz commented on the pull request: https://github.com/apache/storm/pull/451#issuecomment-83732719 +1 [storm-redis] Add basic lookup / persist bolts -- Key: STORM-691 URL: https://issues.apache.org/jira/browse/STORM-691 Project: Apache Storm Issue Type: Improvement Affects Versions: 0.10.0 Reporter: Jungtaek Lim Assignee: Jungtaek Lim Priority: Minor Currently storm-redis provides AbstractRedisBolt for normal (not Trident) Bolt. Jedis is easy to use so it may be enough, but we can also provide implementations of AbstractRedisBolt for simple usage. eg. store (key, value) pair, get key's value Since Redis has various data types and commands, we can't cover whole things, but seems like below things could be considered. || Type || Read || Write || | STRING | GET (key) | SET (key, value) | | HASH | HGET (key, field) | HSET (key, field, value) | | LIST | LPOP (key) | RPUSH (key, value) | | SET | SCARD (key) | SADD (key, member) | | SORTED SET | ZSCORE (key, member) | ZADD (key, score, member) | | HLL (HyperLogLog) | PFCOUNT (key) | PFADD (key, element) | Btw, since we will normally get key value from tuple (as most external module did), HASH, SET, SORTED SET needs additional key to process. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Release Storm 0.9.4 / 0.10.0
Hi, For storm 0.10.0 please add if you want any JIRAs that should be included. I want to include https://issues.apache.org/jira/browse/STORM-617 Thanks, Harsha On March 12, 2015 at 9:30:25 AM, T B (thomas...@arcor.de) wrote: Hi, For storm 0.10.0 please add if you want any JIRAs that should be included. I want to include https://issues.apache.org/jira/browse/STORM-617 Thanks, Harsha
Re: [DISCUSS] Release Storm 0.9.4 / 0.10.0
With the VOTE underway for a 0.9.4 release ( if you have time, please evaluate the RC and vote accordingly), I’d like to turn our attention toward the 0.10.0 release. I’d appreciate feedback on the state of the 0.10.0 (master) branch, especially from those who have been involved in developing the security-related features (which is one of the primary features of this branch). Personally, I know of several organizations that are using a build of 0.10.0 successfully in production with security enabled. The main issue I’ve seen people struggle with is not a problem with code itself, but rather difficulties in setting up a secure cluster and interacting with other systems that are secured with Kerberos. I see that as more of a documentation issue, and not something that should block a release. One feature that I think is essential for 0.10.0 is STORM-634 [1] (support for rolling upgrades), which was recently merged. This should make post-0.10.0 upgrades a lot less painful for users. Based on the feedback received thus far, it looks like all the suggested patches have either been merged or are ready to be merged, with the exception of STORM-617 [2] (no patch available yet). Should we wait for STORM-617? Any other patch suggestions? -Taylor [1] https://issues.apache.org/jira/browse/STORM-634 [2] https://issues.apache.org/jira/browse/STORM-617 On Mar 12, 2015, at 12:29 PM, T B thomas...@arcor.de wrote: +1 for releasing 0.9.4 Thomas On 11 March 2015 at 21:39, Richard Kellogg rmkell...@comcast.net wrote: Suggest we pull in STORM-559 as well. It is strictly an update to documentation and has already been merged to trunk. -Original Message- From: P. Taylor Goetz [mailto:ptgo...@gmail.com] Sent: Wednesday, March 11, 2015 4:51 PM To: dev@storm.apache.org Subject: Re: [DISCUSS] Release Storm 0.9.4 / 0.10.0 Thanks for the feedback Richard, Parth, and Jungtaek. I’ve made a note of your suggestions for the releases. Does anyone else have any thoughts (esp. committers)? Should we move forward with releasing? -Taylor On Mar 5, 2015, at 5:00 PM, 임정택 kabh...@gmail.com wrote: storm-redis (scheduled to be released at 0.10.0) has one bugfix and one essential feature PRs. - bugfix: https://issues.apache.org/jira/browse/STORM-690 -- It fixes connection pool issue. - feature: https://issues.apache.org/jira/browse/STORM-691 -- It provides basic lookup / persist bolts so I believe it's necessary. Furthermore, I'd like to continue to support various data types with storm-redis Trident, after STORM-691 is merged to master. Thanks! Regards Jungtaek Lim (HeartSaVioR) 2015-03-06 2:37 GMT+09:00 P. Taylor Goetz ptgo...@gmail.com: I’d like to start a discussion for releasing 0.9.4 (maintenance release) and 0.10.0 (security release). 0.9.4 is basically a branch of 0.9.3 with two important bug fixes: STORM-329: fix cascading Storm failure by improving reconnection strategy and buffering messages STORM-130: Supervisor getting killed due to java.io.FileNotFoundException: File '../stormconf.ser' does not exist. Both are long-standing bugs that have proven problematic for many users. I’d be in favor of releasing 0.9.4 with just those two fixes, but I’m interested in finding out if anyone thinks there are additional patches to master that should be considered for 0.9.4. 0.10.0 is a much larger release in terms of changes. In addition to the changes above, it includes all the new security features and numerous fixes and enhancements (see the CHANGELOG in the master branch for a full list). Do we feel 0.10.0 is ready for release? If not what outstanding bugs/patches should we consider before releasing? I’m fine holding off on a 0.10.0 release if we feel there is additional work to be done, but I’d like to at least move forward with 0.9.4 release. Thoughts? -Taylor -- Name : 임 정택 Blog : http://www.heartsavior.net / http://dev.heartsavior.net Twitter : http://twitter.com/heartsavior LinkedIn : http://www.linkedin.com/in/heartsavior signature.asc Description: Message signed with OpenPGP using GPGMail
[jira] [Commented] (STORM-167) proposal for storm topology online update
[ https://issues.apache.org/jira/browse/STORM-167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14369823#comment-14369823 ] Parth Brahmbhatt commented on STORM-167: This is a useful feature and I see a lot of user interest. [~xiaokang] Thanks for the original patch and I am not sure why it was not reviewed. Do you think you can upmerge this with storm/master? If not, do you mind if I take over this task? proposal for storm topology online update - Key: STORM-167 URL: https://issues.apache.org/jira/browse/STORM-167 Project: Apache Storm Issue Type: New Feature Reporter: James Xu Priority: Minor https://github.com/nathanmarz/storm/issues/540 Now update topology code can only be done by kill it and re-submit a new one. During the kill and re-submit process some request may delay or fail. It is not so good for online service. So we consider to add topology online update recently. Mission update running topology code gracefully one worker after another without service total interrupted. Just update topology code, not update topology DAG structure including component, stream and task number. Proposal * client use storm update topology-name new-jar-file to submit new-jar-file update request * nimbus update stormdist dir, link topology-dir to new one * nimbus update topology version on zk * the supervisors that running this topology update it ** check topology version on zk, if it is not the same as local version, a topology update begin ** each supervisor schedule the topology's worker update at a rand(expect-max-update-time) time point ** sync-supervisor download the latest code from nimbus ** sync-process check local worker heartbeat version(to be added), if it is not the same with sync-supervisor downloaded version, kill the worker ** sync-process restart killed worker ** new worker heartbeat to zk with version(to be added), it can be displayed on web ui to check update progress. This feature is deployed in our production clusters. It's really useful for topologys handling online request waiting for response. Topology jar can be updated without entire service offline. We hope that this feature is useful for others too. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: Include topic information with Kafka metrics
Github user Parth-Brahmbhatt commented on the pull request: https://github.com/apache/storm/pull/470#issuecomment-83685286 You should update the commit message so it begins with JIRA number. +1. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] storm pull request: [STORM-570] replace table sorter with data tab...
Github user kishorvpatil commented on the pull request: https://github.com/apache/storm/pull/328#issuecomment-83749375 @revans2 Thank you. I have merged in the changes. Sorry for delay. --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (STORM-570) Switch from tablesorter to datatables jquery plugin
[ https://issues.apache.org/jira/browse/STORM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370034#comment-14370034 ] ASF GitHub Bot commented on STORM-570: -- Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/328 Switch from tablesorter to datatables jquery plugin --- Key: STORM-570 URL: https://issues.apache.org/jira/browse/STORM-570 Project: Apache Storm Issue Type: Improvement Reporter: Robert Joseph Evans Priority: Minor Datatables (http://www.datatables.net/) allows for more than just sorting, it can do filtering and pagination if needed. This is especially nice for things like the config that can be rather large, and fill up the page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (STORM-570) Switch from tablesorter to datatables jquery plugin
[ https://issues.apache.org/jira/browse/STORM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14370036#comment-14370036 ] ASF GitHub Bot commented on STORM-570: -- Github user kishorvpatil commented on the pull request: https://github.com/apache/storm/pull/328#issuecomment-83749375 @revans2 Thank you. I have merged in the changes. Sorry for delay. Switch from tablesorter to datatables jquery plugin --- Key: STORM-570 URL: https://issues.apache.org/jira/browse/STORM-570 Project: Apache Storm Issue Type: Improvement Reporter: Robert Joseph Evans Priority: Minor Datatables (http://www.datatables.net/) allows for more than just sorting, it can do filtering and pagination if needed. This is especially nice for things like the config that can be rather large, and fill up the page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: [STORM-570] replace table sorter with data tab...
Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/328 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] storm pull request: Include topic information with Kafka metrics
Github user harshach commented on the pull request: https://github.com/apache/storm/pull/470#issuecomment-83752728 +1 --- 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 enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (STORM-570) Switch from tablesorter to datatables jquery plugin
[ https://issues.apache.org/jira/browse/STORM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishor Patil resolved STORM-570. Resolution: Fixed Fix Version/s: 0.10.0 Switch from tablesorter to datatables jquery plugin --- Key: STORM-570 URL: https://issues.apache.org/jira/browse/STORM-570 Project: Apache Storm Issue Type: Improvement Reporter: Robert Joseph Evans Assignee: Robert Joseph Evans Priority: Minor Fix For: 0.10.0 Datatables (http://www.datatables.net/) allows for more than just sorting, it can do filtering and pagination if needed. This is especially nice for things like the config that can be rather large, and fill up the page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (STORM-570) Switch from tablesorter to datatables jquery plugin
[ https://issues.apache.org/jira/browse/STORM-570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kishor Patil updated STORM-570: --- Assignee: Robert Joseph Evans Switch from tablesorter to datatables jquery plugin --- Key: STORM-570 URL: https://issues.apache.org/jira/browse/STORM-570 Project: Apache Storm Issue Type: Improvement Reporter: Robert Joseph Evans Assignee: Robert Joseph Evans Priority: Minor Fix For: 0.10.0 Datatables (http://www.datatables.net/) allows for more than just sorting, it can do filtering and pagination if needed. This is especially nice for things like the config that can be rather large, and fill up the page. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [DISCUSS] Release Storm 0.9.4 / 0.10.0
Taylor, STORM-617 is on me I’ll send a patch in next couple of days. Thanks, Harsha On March 19, 2015 at 1:05:21 PM, P. Taylor Goetz (ptgo...@gmail.com) wrote: With the VOTE underway for a 0.9.4 release ( if you have time, please evaluate the RC and vote accordingly), I’d like to turn our attention toward the 0.10.0 release. I’d appreciate feedback on the state of the 0.10.0 (master) branch, especially from those who have been involved in developing the security-related features (which is one of the primary features of this branch). Personally, I know of several organizations that are using a build of 0.10.0 successfully in production with security enabled. The main issue I’ve seen people struggle with is not a problem with code itself, but rather difficulties in setting up a secure cluster and interacting with other systems that are secured with Kerberos. I see that as more of a documentation issue, and not something that should block a release. One feature that I think is essential for 0.10.0 is STORM-634 [1] (support for rolling upgrades), which was recently merged. This should make post-0.10.0 upgrades a lot less painful for users. Based on the feedback received thus far, it looks like all the suggested patches have either been merged or are ready to be merged, with the exception of STORM-617 [2] (no patch available yet). Should we wait for STORM-617? Any other patch suggestions? -Taylor [1] https://issues.apache.org/jira/browse/STORM-634 [2] https://issues.apache.org/jira/browse/STORM-617 On Mar 12, 2015, at 12:29 PM, T B thomas...@arcor.de wrote: +1 for releasing 0.9.4 Thomas On 11 March 2015 at 21:39, Richard Kellogg rmkell...@comcast.net wrote: Suggest we pull in STORM-559 as well. It is strictly an update to documentation and has already been merged to trunk. -Original Message- From: P. Taylor Goetz [mailto:ptgo...@gmail.com] Sent: Wednesday, March 11, 2015 4:51 PM To: dev@storm.apache.org Subject: Re: [DISCUSS] Release Storm 0.9.4 / 0.10.0 Thanks for the feedback Richard, Parth, and Jungtaek. I’ve made a note of your suggestions for the releases. Does anyone else have any thoughts (esp. committers)? Should we move forward with releasing? -Taylor On Mar 5, 2015, at 5:00 PM, 임정택 kabh...@gmail.com wrote: storm-redis (scheduled to be released at 0.10.0) has one bugfix and one essential feature PRs. - bugfix: https://issues.apache.org/jira/browse/STORM-690 -- It fixes connection pool issue. - feature: https://issues.apache.org/jira/browse/STORM-691 -- It provides basic lookup / persist bolts so I believe it's necessary. Furthermore, I'd like to continue to support various data types with storm-redis Trident, after STORM-691 is merged to master. Thanks! Regards Jungtaek Lim (HeartSaVioR) 2015-03-06 2:37 GMT+09:00 P. Taylor Goetz ptgo...@gmail.com: I’d like to start a discussion for releasing 0.9.4 (maintenance release) and 0.10.0 (security release). 0.9.4 is basically a branch of 0.9.3 with two important bug fixes: STORM-329: fix cascading Storm failure by improving reconnection strategy and buffering messages STORM-130: Supervisor getting killed due to java.io.FileNotFoundException: File '../stormconf.ser' does not exist. Both are long-standing bugs that have proven problematic for many users. I’d be in favor of releasing 0.9.4 with just those two fixes, but I’m interested in finding out if anyone thinks there are additional patches to master that should be considered for 0.9.4. 0.10.0 is a much larger release in terms of changes. In addition to the changes above, it includes all the new security features and numerous fixes and enhancements (see the CHANGELOG in the master branch for a full list). Do we feel 0.10.0 is ready for release? If not what outstanding bugs/patches should we consider before releasing? I’m fine holding off on a 0.10.0 release if we feel there is additional work to be done, but I’d like to at least move forward with 0.9.4 release. Thoughts? -Taylor -- Name : 임 정택 Blog : http://www.heartsavior.net / http://dev.heartsavior.net Twitter : http://twitter.com/heartsavior LinkedIn : http://www.linkedin.com/in/heartsavior
[GitHub] storm pull request: Include topic information with Kafka metrics
Github user harshach commented on the pull request: https://github.com/apache/storm/pull/470#issuecomment-83647641 @chawco patch looks good to me but can you open a apache jira for it. 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 does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
