[GitHub] storm issue #2721: STORM-3110: Skip the user while checking isProcessAlive
Github user arunmahadevan commented on the issue: https://github.com/apache/storm/pull/2721 @revans2 , @HeartSaVioR, can you take a look? ---
[GitHub] storm pull request #2721: STORM-3110: Skip the user while checking isProcess...
GitHub user arunmahadevan opened a pull request: https://github.com/apache/storm/pull/2721 STORM-3110: Skip the user while checking isProcessAlive You can merge this pull request into a Git repository by running: $ git pull https://github.com/arunmahadevan/storm STORM-3110-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/2721.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 #2721 commit 1d43937a12d5632d1c64e5701b8443a179595062 Author: Arun Mahadevan Date: 2018-06-15T23:32:53Z STORM-3110: Skip the user while checking isProcessAlive ---
[GitHub] storm pull request #2720: STORM-3109: Fixed incorrect conversion from relati...
GitHub user zd-project opened a pull request: https://github.com/apache/storm/pull/2720 STORM-3109: Fixed incorrect conversion from relative path to absolute path for STORM_LOCAL_DIR See issue: https://issues.apache.org/jira/browse/STORM-3109 You can merge this pull request into a Git repository by running: $ git pull https://github.com/zd-project/storm STORM-3109 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/2720.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 #2720 commit b03ee18dd13196265c3d68e59e76380ccc6b4bd8 Author: Zhengdai Hu Date: 2018-06-15T21:56:01Z STORM-3109: Fixed incorrect conversion from relative path to absolute path for STORM_LOCAL_DIR ---
Powered-By Storm: Southcom - Mezzo fluid mediation
Nathan, Thanks to Storm we have redefined a telecom critical process, mediation. Classical mediation was file based, but we envision file as a stream of records that we can redirect into Mezzo. "Mezzo is a distributed real time mediation platform, build upon Storm. The mediation process is described in an acyclic graph (Storm topology) of nodes that we called a flow. Each node (Storm bolts) of the flow has one or more mediation rules and receives one record from a previous node and returns the mediated record to the next one. The rules are programmable in a high language and editable with the flow editor." we would like to be named on your page http://storm.apache.org/Powered-By.html thanks for your time Paolo Galeotti
[GitHub] storm issue #2718: STORM-3103 allow nimbus to shutdown properly
Github user agresch commented on the issue: https://github.com/apache/storm/pull/2718 If it helps, here is the callstack from our original bug report: 2018-05-24 09:27:05.636 o.a.s.d.n.Nimbus main [INFO] Starting nimbus server for storm version '2.0.0.y' 2018-05-24 09:27:06.012 o.a.s.d.n.Nimbus timer [ERROR] Error while processing event java.lang.RuntimeException: java.lang.NullPointerException at org.apache.storm.daemon.nimbus.Nimbus.lambda$launchServer$37(Nimbus.java:2685) ~[storm-server-2.0.0.y.jar:2.0.0.y] at org.apache.storm.StormTimer$1.run(StormTimer.java:111) ~[storm-client-2.0.0.y.jar:2.0.0.y] at org.apache.storm.StormTimer$StormTimerTask.run(StormTimer.java:227) ~[storm-client-2.0.0.y.jar:2.0.0.y] Caused by: java.lang.NullPointerException at org.apache.storm.daemon.nimbus.Nimbus.readAllSupervisorDetails(Nimbus.java:1814) ~[storm-server-2.0.0.y.jar:2.0.0.y] at org.apache.storm.daemon.nimbus.Nimbus.computeNewSchedulerAssignments(Nimbus.java:1906) ~[storm-server-2.0.0.y.jar:2.0.0.y] at org.apache.storm.daemon.nimbus.Nimbus.mkAssignments(Nimbus.java:2057) ~[storm-server-2.0.0.y.jar:2.0.0.y] at org.apache.storm.daemon.nimbus.Nimbus.mkAssignments(Nimbus.java:2003) ~[storm-server-2.0.0.y.jar:2.0.0.y] at org.apache.storm.daemon.nimbus.Nimbus.lambda$launchServer$37(Nimbus.java:2681) ~[storm-server-2.0.0.y.jar:2.0.0.y] ... 2 more 2018-05-24 09:27:06.023 o.a.s.u.Utils timer [ERROR] Halting process: Error while processing event java.lang.RuntimeException: Halting process: Error while processing event at org.apache.storm.utils.Utils.exitProcess(Utils.java:469) ~[storm-client-2.0.0.y.jar:2.0.0.y] at org.apache.storm.daemon.nimbus.Nimbus.lambda$new$17(Nimbus.java:484) ~[storm-server-2.0.0.y.jar:2.0.0.y] at org.apache.storm.StormTimer$StormTimerTask.run(StormTimer.java:252) ~[storm-client-2.0.0.y.jar:2.0.0.y] 2018-05-24 09:27:06.032 o.a.s.d.n.Nimbus Thread-12 [INFO] Shutting down master 2018-05-24 09:27:06.032 o.a.s.u.Utils Thread-13 [INFO] Halting after 10 seconds No further shutdown was processed. It's entirely reproducible by forcing an NPE from the timer. ---
[GitHub] storm issue #2718: STORM-3103 allow nimbus to shutdown properly
Github user agresch commented on the issue: https://github.com/apache/storm/pull/2718 @danny0405 - The case I saw was the Timer throwing a null pointer exception from mkAssignments() - fixed in https://github.com/apache/storm/pull/2693. This causes the onKill callback to be called and locks up the timer thread. ---
[GitHub] storm issue #2711: STORM-3100 : Introducing CustomIndexArray to speedup Hash...
Github user roshannaik commented on the issue: https://github.com/apache/storm/pull/2711 Looks like tester_bolt_metrics.py under storm-core is failing. I see that it can be run via mvn clojure:test under storm-core. But unable to figure out what really going wrong. Any help would be appreciated. thanks. ---
[GitHub] storm issue #2718: STORM-3103 allow nimbus to shutdown properly
Github user danny0405 commented on the issue:
https://github.com/apache/storm/pull/2718
@agresch
Yes the
[https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/StormTimer.java#L173](https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/StormTimer.java#L173)
may throw an Interrupted Exception,
but
`} catch (Throwable e) {
if
(!(Utils.exceptionCauseIsInstanceOf(InterruptedException.class, e))
&&
!(Utils.exceptionCauseIsInstanceOf(ClosedByInterruptException.class, e))) {
this.onKill.uncaughtException(this, e);
this.setActive(false);
}
}`
here it already make a decision that if the exception is not
InterruptedException.class we shall register the uncaughtException, so in what
situation you mean the deadlock will occur?
---
