[GitHub] storm pull request: [STORM-826] Update KafkaBolt to use the new ka...
Github user lazyval commented on the pull request: https://github.com/apache/storm/pull/572#issuecomment-118368768 Okay, I am too late to the party :-) --- 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-826) As a storm developer I’d like to use the new kafka producer API to reduce dependencies and use long term supported kafka apis
[
https://issues.apache.org/jira/browse/STORM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613232#comment-14613232
]
ASF GitHub Bot commented on STORM-826:
--
Github user lazyval commented on a diff in the pull request:
https://github.com/apache/storm/pull/572#discussion_r33868970
--- Diff: external/storm-kafka/src/jvm/storm/kafka/bolt/KafkaBolt.java ---
@@ -102,12 +114,40 @@ public void execute(Tuple input) {
key = mapper.getKeyFromTuple(input);
message = mapper.getMessageFromTuple(input);
topic = topicSelector.getTopic(input);
-if(topic != null ) {
-producer.send(new KeyedMessageK, V(topic, key, message));
+if (topic != null ) {
+Callback callback = null;
+
+if (!fireAndForget async) {
+callback = new Callback() {
+@Override
+public void onCompletion(RecordMetadata ignored,
Exception e) {
+synchronized (collector) {
--- End diff --
Most of the storm user facing components usually thought as a single thread
actors. Are you sure you want to break this abstraction?
As a storm developer I’d like to use the new kafka producer API to reduce
dependencies and use long term supported kafka apis
--
Key: STORM-826
URL: https://issues.apache.org/jira/browse/STORM-826
Project: Apache Storm
Issue Type: Story
Components: storm-kafka
Reporter: Thomas Becker
Assignee: Zhuo Liu
Fix For: 0.11.0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] storm pull request: [STORM-826] Update KafkaBolt to use the new ka...
Github user lazyval commented on a diff in the pull request: https://github.com/apache/storm/pull/572#discussion_r33868816 --- Diff: external/storm-kafka/pom.xml --- @@ -113,8 +113,8 @@ /dependency dependency groupIdorg.apache.kafka/groupId -artifactIdkafka_2.9.2/artifactId -version0.8.1.1/version +artifactIdkafka_2.10/artifactId --- End diff -- Why bump version? Why not set it to 2.11? --- 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-826) As a storm developer I’d like to use the new kafka producer API to reduce dependencies and use long term supported kafka apis
[ https://issues.apache.org/jira/browse/STORM-826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613229#comment-14613229 ] ASF GitHub Bot commented on STORM-826: -- Github user lazyval commented on a diff in the pull request: https://github.com/apache/storm/pull/572#discussion_r33868816 --- Diff: external/storm-kafka/pom.xml --- @@ -113,8 +113,8 @@ /dependency dependency groupIdorg.apache.kafka/groupId -artifactIdkafka_2.9.2/artifactId -version0.8.1.1/version +artifactIdkafka_2.10/artifactId --- End diff -- Why bump version? Why not set it to 2.11? As a storm developer I’d like to use the new kafka producer API to reduce dependencies and use long term supported kafka apis -- Key: STORM-826 URL: https://issues.apache.org/jira/browse/STORM-826 Project: Apache Storm Issue Type: Story Components: storm-kafka Reporter: Thomas Becker Assignee: Zhuo Liu Fix For: 0.11.0 -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (STORM-160) Allow ShellBolt to set env vars (particularly PATH)
[ https://issues.apache.org/jira/browse/STORM-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613290#comment-14613290 ] ASF GitHub Bot commented on STORM-160: -- Github user bourneagain commented on the pull request: https://github.com/apache/storm/pull/575#issuecomment-118387380 Thanks @HeartSaVioR . I have fixed the imports issue and tested on local machine to see it working fine. I shall keep a note of this in future. Thanks. Allow ShellBolt to set env vars (particularly PATH) --- Key: STORM-160 URL: https://issues.apache.org/jira/browse/STORM-160 Project: Apache Storm Issue Type: New Feature Reporter: James Xu Priority: Minor Labels: newbie https://github.com/nathanmarz/storm/issues/32 While trying to implement a multilang based bolt, I discovered that binaries outside of /usr/bin, /usr/sbin, and /sbin, are not found despite being installed in say, /usr/local/bin. Is there a way to specify a PATH variable so when storm creates the sub shell, these binaries can be located by name? If not, can we get one added? -- nathanmarz: This is a good idea. For the meantime, does using the full path of the binary (e.g., /usr/local/bin/python) work around this issue? -- dinedal: That works for processes that don't require any other environment variables. Also, in cases where developers have multiple versions of a program (say, RVM) and the production servers have another one installed on the system, it means changing code for deploying the topology. -- nicoo: +1 To work around this issue you can start your multilang bolt from a bash script that set all needed env vars. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (STORM-160) Allow ShellBolt to set env vars (particularly PATH)
[
https://issues.apache.org/jira/browse/STORM-160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14613567#comment-14613567
]
ASF GitHub Bot commented on STORM-160:
--
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/575#discussion_r33884760
--- Diff: storm-core/src/jvm/backtype/storm/utils/ShellProcess.java ---
@@ -48,8 +50,31 @@ public ShellProcess(String[] command) {
this.command = command;
}
+public void setEnv(MapString, String env) {
+this.env = env;
+}
+
+private void modifyEnvironment(MapString, String buildEnv) {
+for (Map.EntryString, String entry : env.entrySet()) {
+if (PATH.equals(entry.getKey())) {
+buildEnv.put(PATH, buildEnv.get(PATH) +
File.pathSeparatorChar + env.get(PATH));
+} else {
+buildEnv.put(entry.getKey(), entry.getValue());
+}
+}
+}
+
+
public Number launch(Map conf, TopologyContext context) {
ProcessBuilder builder = new ProcessBuilder(command);
+if (!env.isEmpty()) {
+MapString, String buildEnv = builder.environment();
+modifyEnvironment(buildEnv);
+}
+for(Map.EntryString, String entry :
builder.environment().entrySet()) {
--- End diff --
@bourneagain
Maybe it is for debugging. Could you remove it, or use logger to log
properly?
Allow ShellBolt to set env vars (particularly PATH)
---
Key: STORM-160
URL: https://issues.apache.org/jira/browse/STORM-160
Project: Apache Storm
Issue Type: New Feature
Reporter: James Xu
Priority: Minor
Labels: newbie
https://github.com/nathanmarz/storm/issues/32
While trying to implement a multilang based bolt, I discovered that binaries
outside of /usr/bin, /usr/sbin, and /sbin, are not found despite being
installed in say, /usr/local/bin.
Is there a way to specify a PATH variable so when storm creates the sub
shell, these binaries can be located by name? If not, can we get one added?
--
nathanmarz: This is a good idea. For the meantime, does using the full path
of the binary (e.g., /usr/local/bin/python) work around this issue?
--
dinedal: That works for processes that don't require any other environment
variables.
Also, in cases where developers have multiple versions of a program (say,
RVM) and the production servers have another one installed on the system, it
means changing code for deploying the topology.
--
nicoo: +1
To work around this issue you can start your multilang bolt from a bash
script that set all needed env vars.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] storm pull request: STORM-160 Allow ShellBolt to set env vars (par...
Github user HeartSaVioR commented on a diff in the pull request:
https://github.com/apache/storm/pull/575#discussion_r33884760
--- Diff: storm-core/src/jvm/backtype/storm/utils/ShellProcess.java ---
@@ -48,8 +50,31 @@ public ShellProcess(String[] command) {
this.command = command;
}
+public void setEnv(MapString, String env) {
+this.env = env;
+}
+
+private void modifyEnvironment(MapString, String buildEnv) {
+for (Map.EntryString, String entry : env.entrySet()) {
+if (PATH.equals(entry.getKey())) {
+buildEnv.put(PATH, buildEnv.get(PATH) +
File.pathSeparatorChar + env.get(PATH));
+} else {
+buildEnv.put(entry.getKey(), entry.getValue());
+}
+}
+}
+
+
public Number launch(Map conf, TopologyContext context) {
ProcessBuilder builder = new ProcessBuilder(command);
+if (!env.isEmpty()) {
+MapString, String buildEnv = builder.environment();
+modifyEnvironment(buildEnv);
+}
+for(Map.EntryString, String entry :
builder.environment().entrySet()) {
--- End diff --
@bourneagain
Maybe it is for debugging. Could you remove it, or use logger to log
properly?
---
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-924:Set the file mode of the files inclu...
Github user HeartSaVioR commented on the pull request: https://github.com/apache/storm/pull/614#issuecomment-118436035 How about setting file mode to storm_env.ini too? --- 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 763/839 0.11.x
GitHub user eshioji opened a pull request: https://github.com/apache/storm/pull/616 Storm 763/839 0.11.x This is a port of PR #568 . It fixes STORM-839 (Deadlock) and STORM-763 (Establish Netty reconnects asynchronously and reduce verbosity of error logs) @revans2 This is the PR for master. I ran the performance test against master's HEAD and the results were in-line with the results I got in #568 . I'll create a separate PR for 0.10.x You can merge this pull request into a Git repository by running: $ git pull https://github.com/eshioji/storm STORM-763_0.11.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/616.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #616 commit b1411aa63383801913cb1340a8b51c5bb46db0ba Author: Enno Shioji eshi...@gmail.com Date: 2015-07-01T12:54:33Z This fixes STORM-763 and STORM-839 commit 935e87accc85340549f44effa8a675e950747faa Author: Enno Shioji eshi...@gmail.com Date: 2015-07-02T17:56:23Z Remove obsolete TODO commit 7af467723b5c4b0beedc40626a8c56bc7c3e0d21 Author: Enno Shioji eshi...@gmail.com Date: 2015-07-03T00:02:00Z Bring back removal of client from context upon closing --- 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-839) Deadlock hazard in backtype.storm.messaging.netty.Client
[ https://issues.apache.org/jira/browse/STORM-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612982#comment-14612982 ] ASF GitHub Bot commented on STORM-839: -- GitHub user eshioji opened a pull request: https://github.com/apache/storm/pull/617 Storm 763/839 0.10.x This is a port of PR #568 from 0.9.x to 0.10.x. It fixes STORM-839 (Deadlock) and STORM-763 (Establish Netty reconnects asynchronously and reduce verbosity of error logs) The content is equivalent to the PR for 0.11.x (#616) @revans2 This is the PR for 0.10.x. I also ran the performance test for this and the results were again inline with what I got with 0.9.x. I get build failure on my machine but I get the same failure with 0.10.x HEAD, so I'm guessing it's unrelated to this change. You can merge this pull request into a Git repository by running: $ git pull https://github.com/eshioji/storm STORM-763_0.10.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/617.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #617 commit 286bacdf49937d1e8576eff27dfc887824ffdbbb Author: Enno Shioji eshi...@gmail.com Date: 2015-07-02T18:01:01Z This fixes STORM-763 and STORM-839 commit a2502c3bc3bcd4caf3800bb645058abb61d2a071 Author: Enno Shioji eshi...@gmail.com Date: 2015-07-02T23:51:32Z Merge remote-tracking branch 'upstream/0.10.x-branch' into STORM-763_0.10.x # Conflicts: # storm-core/src/jvm/backtype/storm/messaging/netty/Client.java commit f5db06ce2809c3b66f2d797f979f8c40133c2f60 Author: Enno Shioji eshi...@gmail.com Date: 2015-07-03T00:02:00Z Bring back removal of client from context on closing Deadlock hazard in backtype.storm.messaging.netty.Client Key: STORM-839 URL: https://issues.apache.org/jira/browse/STORM-839 Project: Apache Storm Issue Type: Bug Affects Versions: 0.9.4 Reporter: Enno Shioji Priority: Critical See the thread dump below that shows the deadlock. client-worker-1 is holding 7b5a7fa5 and waiting on 1446a1e9. Thread-10-disruptor-worker-transfer-queue is holding 1446a1e9 and is waiting on 7b5a7fa5. (Thread dump is truncated to show only the relevant parts) 2015-05-28 15:37:15 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.72-b04 mixed mode): Thread-10-disruptor-worker-transfer-queue - Thread t@52 java.lang.Thread.State: BLOCKED at org.apache.storm.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:398) - waiting to lock 7b5a7fa5 (a java.lang.Object) owned by client-worker-1 t@25 at org.apache.storm.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:128) at org.apache.storm.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(NioClientSocketPipelineSink.java:84) at org.apache.storm.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779) at org.apache.storm.netty.channel.Channels.write(Channels.java:725) at org.apache.storm.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71) at org.apache.storm.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59) at org.apache.storm.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591) at org.apache.storm.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582) at org.apache.storm.netty.channel.Channels.write(Channels.java:704) at org.apache.storm.netty.channel.Channels.write(Channels.java:671) at org.apache.storm.netty.channel.AbstractChannel.write(AbstractChannel.java:248) at backtype.storm.messaging.netty.Client.flushMessages(Client.java:480) - locked 1446a1e9 (a backtype.storm.messaging.netty.Client) at backtype.storm.messaging.netty.Client.send(Client.java:412) - locked 1446a1e9 (a backtype.storm.messaging.netty.Client) at backtype.storm.utils.TransferDrainer.send(TransferDrainer.java:54) at backtype.storm.daemon.worker$mk_transfer_tuples_handler$fn__5014$fn__5015.invoke(worker.clj:334) at backtype.storm.daemon.worker$mk_transfer_tuples_handler$fn__5014.invoke(worker.clj:332) at backtype.storm.disruptor$clojure_handler$reify__1446.onEvent(disruptor.clj:58) at backtype.storm.utils.DisruptorQueue.consumeBatchToCursor(DisruptorQueue.java:125) at backtype.storm.utils.DisruptorQueue.consumeBatchWhenAvailable(DisruptorQueue.java:99) at
[GitHub] storm pull request: Storm 763/839 0.10.x
GitHub user eshioji opened a pull request: https://github.com/apache/storm/pull/617 Storm 763/839 0.10.x This is a port of PR #568 from 0.9.x to 0.10.x. It fixes STORM-839 (Deadlock) and STORM-763 (Establish Netty reconnects asynchronously and reduce verbosity of error logs) The content is equivalent to the PR for 0.11.x (#616) @revans2 This is the PR for 0.10.x. I also ran the performance test for this and the results were again inline with what I got with 0.9.x. I get build failure on my machine but I get the same failure with 0.10.x HEAD, so I'm guessing it's unrelated to this change. You can merge this pull request into a Git repository by running: $ git pull https://github.com/eshioji/storm STORM-763_0.10.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/617.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #617 commit 286bacdf49937d1e8576eff27dfc887824ffdbbb Author: Enno Shioji eshi...@gmail.com Date: 2015-07-02T18:01:01Z This fixes STORM-763 and STORM-839 commit a2502c3bc3bcd4caf3800bb645058abb61d2a071 Author: Enno Shioji eshi...@gmail.com Date: 2015-07-02T23:51:32Z Merge remote-tracking branch 'upstream/0.10.x-branch' into STORM-763_0.10.x # Conflicts: # storm-core/src/jvm/backtype/storm/messaging/netty/Client.java commit f5db06ce2809c3b66f2d797f979f8c40133c2f60 Author: Enno Shioji eshi...@gmail.com Date: 2015-07-03T00:02:00Z Bring back removal of client from context on closing --- 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-839) Deadlock hazard in backtype.storm.messaging.netty.Client
[ https://issues.apache.org/jira/browse/STORM-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612923#comment-14612923 ] ASF GitHub Bot commented on STORM-839: -- GitHub user eshioji opened a pull request: https://github.com/apache/storm/pull/616 Storm 763/839 0.11.x This is a port of PR #568 . It fixes STORM-839 (Deadlock) and STORM-763 (Establish Netty reconnects asynchronously and reduce verbosity of error logs) @revans2 This is the PR for master. I ran the performance test against master's HEAD and the results were in-line with the results I got in #568 . I'll create a separate PR for 0.10.x You can merge this pull request into a Git repository by running: $ git pull https://github.com/eshioji/storm STORM-763_0.11.x Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/616.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #616 commit b1411aa63383801913cb1340a8b51c5bb46db0ba Author: Enno Shioji eshi...@gmail.com Date: 2015-07-01T12:54:33Z This fixes STORM-763 and STORM-839 commit 935e87accc85340549f44effa8a675e950747faa Author: Enno Shioji eshi...@gmail.com Date: 2015-07-02T17:56:23Z Remove obsolete TODO commit 7af467723b5c4b0beedc40626a8c56bc7c3e0d21 Author: Enno Shioji eshi...@gmail.com Date: 2015-07-03T00:02:00Z Bring back removal of client from context upon closing Deadlock hazard in backtype.storm.messaging.netty.Client Key: STORM-839 URL: https://issues.apache.org/jira/browse/STORM-839 Project: Apache Storm Issue Type: Bug Affects Versions: 0.9.4 Reporter: Enno Shioji Priority: Critical See the thread dump below that shows the deadlock. client-worker-1 is holding 7b5a7fa5 and waiting on 1446a1e9. Thread-10-disruptor-worker-transfer-queue is holding 1446a1e9 and is waiting on 7b5a7fa5. (Thread dump is truncated to show only the relevant parts) 2015-05-28 15:37:15 Full thread dump Java HotSpot(TM) 64-Bit Server VM (24.72-b04 mixed mode): Thread-10-disruptor-worker-transfer-queue - Thread t@52 java.lang.Thread.State: BLOCKED at org.apache.storm.netty.channel.socket.nio.AbstractNioWorker.cleanUpWriteBuffer(AbstractNioWorker.java:398) - waiting to lock 7b5a7fa5 (a java.lang.Object) owned by client-worker-1 t@25 at org.apache.storm.netty.channel.socket.nio.AbstractNioWorker.writeFromUserCode(AbstractNioWorker.java:128) at org.apache.storm.netty.channel.socket.nio.NioClientSocketPipelineSink.eventSunk(NioClientSocketPipelineSink.java:84) at org.apache.storm.netty.channel.DefaultChannelPipeline$DefaultChannelHandlerContext.sendDownstream(DefaultChannelPipeline.java:779) at org.apache.storm.netty.channel.Channels.write(Channels.java:725) at org.apache.storm.netty.handler.codec.oneone.OneToOneEncoder.doEncode(OneToOneEncoder.java:71) at org.apache.storm.netty.handler.codec.oneone.OneToOneEncoder.handleDownstream(OneToOneEncoder.java:59) at org.apache.storm.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:591) at org.apache.storm.netty.channel.DefaultChannelPipeline.sendDownstream(DefaultChannelPipeline.java:582) at org.apache.storm.netty.channel.Channels.write(Channels.java:704) at org.apache.storm.netty.channel.Channels.write(Channels.java:671) at org.apache.storm.netty.channel.AbstractChannel.write(AbstractChannel.java:248) at backtype.storm.messaging.netty.Client.flushMessages(Client.java:480) - locked 1446a1e9 (a backtype.storm.messaging.netty.Client) at backtype.storm.messaging.netty.Client.send(Client.java:412) - locked 1446a1e9 (a backtype.storm.messaging.netty.Client) at backtype.storm.utils.TransferDrainer.send(TransferDrainer.java:54) at backtype.storm.daemon.worker$mk_transfer_tuples_handler$fn__5014$fn__5015.invoke(worker.clj:334) at backtype.storm.daemon.worker$mk_transfer_tuples_handler$fn__5014.invoke(worker.clj:332) at backtype.storm.disruptor$clojure_handler$reify__1446.onEvent(disruptor.clj:58) at backtype.storm.utils.DisruptorQueue.consumeBatchToCursor(DisruptorQueue.java:125) at backtype.storm.utils.DisruptorQueue.consumeBatchWhenAvailable(DisruptorQueue.java:99) at backtype.storm.disruptor$consume_batch_when_available.invoke(disruptor.clj:80) at backtype.storm.disruptor$consume_loop_STAR_$fn__1459.invoke(disruptor.clj:94) at backtype.storm.util$async_loop$fn__458.invoke(util.clj:463) at clojure.lang.AFn.run(AFn.java:24) at java.lang.Thread.run(Unknown Source)
[jira] [Commented] (STORM-913) Use Curator's delete().deletingChildrenIfNeeded() instead of zk/delete-recursive
[ https://issues.apache.org/jira/browse/STORM-913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14612892#comment-14612892 ] ASF GitHub Bot commented on STORM-913: -- GitHub user caofangkun opened a pull request: https://github.com/apache/storm/pull/615 STORM-913:Use Curator's delete().deletingChildrenIfNeeded() instead of zk/delete-recursive You can merge this pull request into a Git repository by running: $ git pull https://github.com/caofangkun/apache-storm storm-913-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/615.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #615 commit fa370b540cdc91cefea6ccda166525ba4e6aa15c Author: caofangkun caofang...@gmail.com Date: 2015-07-03T06:29:57Z STORM-913:Use Curator's delete().deletingChildrenIfNeeded() instead of zk/delete-recursive Use Curator's delete().deletingChildrenIfNeeded() instead of zk/delete-recursive - Key: STORM-913 URL: https://issues.apache.org/jira/browse/STORM-913 Project: Apache Storm Issue Type: Improvement Affects Versions: 0.11.0 Reporter: caofangkun Assignee: caofangkun Priority: Minor -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (STORM-925) Move DefaultRolloverStrategy in log4j2/worker.xml
Benjamin Welch created STORM-925: Summary: Move DefaultRolloverStrategy in log4j2/worker.xml Key: STORM-925 URL: https://issues.apache.org/jira/browse/STORM-925 Project: Apache Storm Issue Type: Bug Affects Versions: 0.10.0 Reporter: Benjamin Welch Priority: Minor Fix For: 0.10.0 In log4j2/cluster.xml and log4j2/worker.xml, the DefaultRolloverStrategy line (three instances) need to be move out of Policy. Storm supervisor, ui, and nimbus will output errors on start when running 0.10.0 beta1 https://stackoverflow.com/questions/31046512/storm-error-on-initialization-of-server-mk-supervisor-required-field-serializ -- This message was sent by Atlassian JIRA (v6.3.4#6332)
