[jira] [Commented] (STORM-994) Connection leak between nimbus and supervisors

[Frantz Mazoyer (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727018#comment-14727018
 ] 

Frantz Mazoyer commented on STORM-994:
--

My pleasure :-)
Thanks for merging.

> Connection leak between nimbus and supervisors
> --
>
> Key: STORM-994
> URL: https://issues.apache.org/jira/browse/STORM-994
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.9.3, 0.10.0, 0.9.4, 0.11.0, 0.9.5
>Reporter: Frantz Mazoyer
>Assignee: Frantz Mazoyer
>Priority: Minor
> Fix For: 0.10.0
>
>
> Successive deploys/undeploys of topology(ies) may result in a connection leak 
> between nimbus and its supervisors



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1024) log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727714#comment-14727714
 ] 

ASF GitHub Bot commented on STORM-1024:
---

Github user harshach commented on the pull request:

https://github.com/apache/storm/pull/714#issuecomment-137184747
  
+1


> log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir
> ---
>
> Key: STORM-1024
> URL: https://issues.apache.org/jira/browse/STORM-1024
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Arun Mahadevan
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (STORM-1024) log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir

[Arun Mahadevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727700#comment-14727700
 ] 

Arun Mahadevan commented on STORM-1024:
---

[~sriharsha] Please review

> log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir
> ---
>
> Key: STORM-1024
> URL: https://issues.apache.org/jira/browse/STORM-1024
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Arun Mahadevan
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] storm pull request: [STORM-1024] Pass -Dstorm.log.dir arg to LogWr...

[arunmahadevan]

GitHub user arunmahadevan opened a pull request:

https://github.com/apache/storm/pull/714

[STORM-1024] Pass -Dstorm.log.dir arg to LogWriter

The log4j variable `${sys:storm.log.dir}` is used in `worker.xml` to set 
the fileName however the system property was not being set while launching 
worker (via LogWriter) causing a directory by the name ${sys:storm.log.dir} to 
be created under `STORM_HOME` dir.

This fix is to pass the system property while launching LogWriter

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/arunmahadevan/storm master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/714.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 #714


commit 6c2b754a7a0c69852850c4dd39af31ba98ef847d
Author: Arun Mahadevan 
Date:   2015-09-02T17:31:13Z

Pass -Dstorm.log.dir arg to LogWriter




---
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-1024) log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727696#comment-14727696
 ] 

ASF GitHub Bot commented on STORM-1024:
---

GitHub user arunmahadevan opened a pull request:

https://github.com/apache/storm/pull/714

[STORM-1024] Pass -Dstorm.log.dir arg to LogWriter

The log4j variable `${sys:storm.log.dir}` is used in `worker.xml` to set 
the fileName however the system property was not being set while launching 
worker (via LogWriter) causing a directory by the name ${sys:storm.log.dir} to 
be created under `STORM_HOME` dir.

This fix is to pass the system property while launching LogWriter

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/arunmahadevan/storm master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/714.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 #714


commit 6c2b754a7a0c69852850c4dd39af31ba98ef847d
Author: Arun Mahadevan 
Date:   2015-09-02T17:31:13Z

Pass -Dstorm.log.dir arg to LogWriter




> log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir
> ---
>
> Key: STORM-1024
> URL: https://issues.apache.org/jira/browse/STORM-1024
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Arun Mahadevan
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] storm pull request: [STORM-1024] Pass -Dstorm.log.dir arg to LogWr...

[harshach]

Github user harshach commented on the pull request:

https://github.com/apache/storm/pull/714#issuecomment-137184747
  
+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-1024) log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir

[Arun Mahadevan (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1024?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727680#comment-14727680
 ] 

Arun Mahadevan commented on STORM-1024:
---

It appears that the "-Dstorm.log.dir" arg is not passed to the LogWriter which 
is causing this. Will raise a PR for the same.

> log4j changes leaving ${sys:storm.log.dir} under STORM_HOME dir
> ---
>
> Key: STORM-1024
> URL: https://issues.apache.org/jira/browse/STORM-1024
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Arun Mahadevan
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] storm pull request: [STORM-1005]replace default storm.local.dir va...

[HeartSaVioR]

Github user HeartSaVioR commented on the pull request:

https://github.com/apache/storm/pull/713#issuecomment-137288071
  
One thing we should keep in mind is, some users are using Storm in Windows 
environment.
Using absolute path, especially known *nix path to default value will make 
a problem for those users.


---
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-1005) Supervisor do not get running workers after restart.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14728331#comment-14728331
 ] 

ASF GitHub Bot commented on STORM-1005:
---

Github user HeartSaVioR commented on the pull request:

https://github.com/apache/storm/pull/713#issuecomment-137288071
  
One thing we should keep in mind is, some users are using Storm in Windows 
environment.
Using absolute path, especially known *nix path to default value will make 
a problem for those users.


> Supervisor do not get running workers after restart.
> 
>
> Key: STORM-1005
> URL: https://issues.apache.org/jira/browse/STORM-1005
> Project: Apache Storm
>  Issue Type: Bug
>  Components: Storm-eventhubs
>Affects Versions: 0.9.4
>Reporter: Renkai Ge
> Attachments: screenshot-1.png, screenshot-2.png
>
>
> I have 8 supervisors running,2 of them shutdown by themselves.
> After I restart them.One supervisor shows the right number of workers, but 
> another shows the worker number is 0 while the workers are still running on 
> that host.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] storm pull request: STORM-1026: Expand external classpaths to incl...

[HeartSaVioR]

Github user HeartSaVioR commented on a diff in the pull request:

https://github.com/apache/storm/pull/715#discussion_r38604124
  
--- Diff: bin/storm.py ---
@@ -103,6 +103,12 @@ def get_config_opts():
 sys.exit(1)
 
 def get_jars_full(adir):
+files = []
+if os.path.isdir(adir):
+files = os.listdir(adir)
+elif os.path.exists(adir):
+files = [aidr]
+
 files = os.listdir(adir)
--- End diff --

This line should be removed to accomplish above lines.


---
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-1026) Adding external classpath elements does not work

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14728337#comment-14728337
 ] 

ASF GitHub Bot commented on STORM-1026:
---

Github user HeartSaVioR commented on a diff in the pull request:

https://github.com/apache/storm/pull/715#discussion_r38604124
  
--- Diff: bin/storm.py ---
@@ -103,6 +103,12 @@ def get_config_opts():
 sys.exit(1)
 
 def get_jars_full(adir):
+files = []
+if os.path.isdir(adir):
+files = os.listdir(adir)
+elif os.path.exists(adir):
+files = [aidr]
+
 files = os.listdir(adir)
--- End diff --

This line should be removed to accomplish above lines.


> Adding external classpath elements does not work
> 
>
> Key: STORM-1026
> URL: https://issues.apache.org/jira/browse/STORM-1026
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.10.0, 0.11.0, 0.9.6
>Reporter: Bryan Shell
>Priority: Minor
>
> Adding an external path and/or jar to the classpath fails to work as 
> expected.  I would expect it to work the same as {noformat}
> "${STORM_DIR}/extlib"{noformat} and 
> {noformat}"${STORM_DIR}/extlib-daemon"{noformat}, and create a complete list 
> of all jars in the path spec(s). 
> Here is an example of the issue:
> {code}
> % STORM_EXT_CLASSPATH=/usr/lib/jvm/default-java/lib/jconsole.jar python
> Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
> [GCC 4.8.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> import fnmatch
> >>> os.getenv('STORM_EXT_CLASSPATH', None)
> '/usr/lib/jvm/default-java/lib/jconsole.jar'
> >>> ret = fnmatch.filter(os.listdir('/opt/HipChat/lib/'), "*.so")
> >>> ret
> ['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 
> 'libhipchatdbusscripting.so', 'libcanberra.so', 'libvorbis.so', 
> 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 'libqxmpp.so', 
> 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 'libz.so', 
> 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
> 'libcanberraSoundNotification.so']
> >>> ret.extend(os.getenv('STORM_EXT_CLASSPATH', None))
> >>> ret
> ['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 
> 'libhipchatdbusscripting.so', 'libcanberra.so', 'libvorbis.so', 
> 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 'libqxmpp.so', 
> 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 'libz.so', 
> 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
> 'libcanberraSoundNotification.so', '/', 'u', 's', 'r', '/', 'l', 'i', 'b', 
> '/', 'j', 'v', 'm', '/', 'd', 'e', 'f', 'a', 'u', 'l', 't', '-', 'j', 'a', 
> 'v', 'a', '/', 'l', 'i', 'b', '/', 'j', 'c', 'o', 'n', 's', 'o', 'l', 'e', 
> '.', 'j', 'a', 'r']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] storm pull request: [STORM-1019][STORM-1020] Added missing version...

[rmkellogg]

Github user rmkellogg commented on the pull request:

https://github.com/apache/storm/pull/710#issuecomment-137296720
  
Can we merge this?  No idea why Travis-CI is failing.  It worked earlier.


---
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-1019) Added missing dependency version to use of org.codehaus.mojo:make-maven-plugin

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14728368#comment-14728368
 ] 

ASF GitHub Bot commented on STORM-1019:
---

Github user rmkellogg commented on the pull request:

https://github.com/apache/storm/pull/710#issuecomment-137296720
  
Can we merge this?  No idea why Travis-CI is failing.  It worked earlier.


> Added missing dependency version to use of 
> org.codehaus.mojo:make-maven-plugin 
> ---
>
> Key: STORM-1019
> URL: https://issues.apache.org/jira/browse/STORM-1019
> Project: Apache Storm
>  Issue Type: Improvement
>Affects Versions: 0.10.0
>Reporter: Rick Kellogg
>Assignee: Rick Kellogg
>Priority: Minor
> Fix For: 0.11.0
>
>
> Travis-CI reports critical warning that Maven plugin is missing version 
> information.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (STORM-1026) Adding external classpath elements does not work

[Bryan Shell (JIRA)]

Bryan Shell created STORM-1026:
--

 Summary: Adding external classpath elements does not work
 Key: STORM-1026
 URL: https://issues.apache.org/jira/browse/STORM-1026
 Project: Apache Storm
  Issue Type: Bug
Affects Versions: 0.10.0, 0.11.0, 0.9.6
Reporter: Bryan Shell
Priority: Minor


Adding an external path and/or jar to the classpath fails to work as expected.  
I would expect it to work the same as {{{
"${STORM_DIR}/extlib"}}} and {{{
"${STORM_DIR}/extlib-daemon"}}}, and create a complete list of all jars in the 
path spec(s). 

Here is an example of the issue:

{code}
% STORM_EXT_CLASSPATH=/usr/lib/jvm/default-java/lib/jconsole.jar python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import fnmatch
>>> os.getenv('STORM_EXT_CLASSPATH', None)
'/usr/lib/jvm/default-java/lib/jconsole.jar'
>>> ret = fnmatch.filter(os.listdir('/opt/HipChat/lib/'), "*.so")
>>> ret
['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 'libhipchatdbusscripting.so', 
'libcanberra.so', 'libvorbis.so', 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 
'libqxmpp.so', 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 
'libz.so', 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
'libcanberraSoundNotification.so']
>>> ret.extend(os.getenv('STORM_EXT_CLASSPATH', None))
>>> ret
['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 'libhipchatdbusscripting.so', 
'libcanberra.so', 'libvorbis.so', 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 
'libqxmpp.so', 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 
'libz.so', 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
'libcanberraSoundNotification.so', '/', 'u', 's', 'r', '/', 'l', 'i', 'b', '/', 
'j', 'v', 'm', '/', 'd', 'e', 'f', 'a', 'u', 'l', 't', '-', 'j', 'a', 'v', 'a', 
'/', 'l', 'i', 'b', '/', 'j', 'c', 'o', 'n', 's', 'o', 'l', 'e', '.', 'j', 'a', 
'r']
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (STORM-1026) Adding external classpath elements does not work

[Bryan Shell (JIRA)]

 [ 
https://issues.apache.org/jira/browse/STORM-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Shell updated STORM-1026:
---
Description: 
Adding an external path and/or jar to the classpath fails to work as expected.  
I would expect it to work the same as {noformat}
"${STORM_DIR}/extlib"{noformat} and 
{noformat}"${STORM_DIR}/extlib-daemon"{noformat}, and create a complete list of 
all jars in the path spec(s). 

Here is an example of the issue:

{code}
% STORM_EXT_CLASSPATH=/usr/lib/jvm/default-java/lib/jconsole.jar python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import fnmatch
>>> os.getenv('STORM_EXT_CLASSPATH', None)
'/usr/lib/jvm/default-java/lib/jconsole.jar'
>>> ret = fnmatch.filter(os.listdir('/opt/HipChat/lib/'), "*.so")
>>> ret
['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 'libhipchatdbusscripting.so', 
'libcanberra.so', 'libvorbis.so', 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 
'libqxmpp.so', 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 
'libz.so', 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
'libcanberraSoundNotification.so']
>>> ret.extend(os.getenv('STORM_EXT_CLASSPATH', None))
>>> ret
['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 'libhipchatdbusscripting.so', 
'libcanberra.so', 'libvorbis.so', 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 
'libqxmpp.so', 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 
'libz.so', 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
'libcanberraSoundNotification.so', '/', 'u', 's', 'r', '/', 'l', 'i', 'b', '/', 
'j', 'v', 'm', '/', 'd', 'e', 'f', 'a', 'u', 'l', 't', '-', 'j', 'a', 'v', 'a', 
'/', 'l', 'i', 'b', '/', 'j', 'c', 'o', 'n', 's', 'o', 'l', 'e', '.', 'j', 'a', 
'r']
{code}

  was:
Adding an external path and/or jar to the classpath fails to work as expected.  
I would expect it to work the same as {{{
"${STORM_DIR}/extlib"}}} and {{{
"${STORM_DIR}/extlib-daemon"}}}, and create a complete list of all jars in the 
path spec(s). 

Here is an example of the issue:

{code}
% STORM_EXT_CLASSPATH=/usr/lib/jvm/default-java/lib/jconsole.jar python
Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
[GCC 4.8.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> import fnmatch
>>> os.getenv('STORM_EXT_CLASSPATH', None)
'/usr/lib/jvm/default-java/lib/jconsole.jar'
>>> ret = fnmatch.filter(os.listdir('/opt/HipChat/lib/'), "*.so")
>>> ret
['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 'libhipchatdbusscripting.so', 
'libcanberra.so', 'libvorbis.so', 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 
'libqxmpp.so', 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 
'libz.so', 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
'libcanberraSoundNotification.so']
>>> ret.extend(os.getenv('STORM_EXT_CLASSPATH', None))
>>> ret
['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 'libhipchatdbusscripting.so', 
'libcanberra.so', 'libvorbis.so', 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 
'libqxmpp.so', 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 
'libz.so', 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
'libcanberraSoundNotification.so', '/', 'u', 's', 'r', '/', 'l', 'i', 'b', '/', 
'j', 'v', 'm', '/', 'd', 'e', 'f', 'a', 'u', 'l', 't', '-', 'j', 'a', 'v', 'a', 
'/', 'l', 'i', 'b', '/', 'j', 'c', 'o', 'n', 's', 'o', 'l', 'e', '.', 'j', 'a', 
'r']
{code}


> Adding external classpath elements does not work
> 
>
> Key: STORM-1026
> URL: https://issues.apache.org/jira/browse/STORM-1026
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.10.0, 0.11.0, 0.9.6
>Reporter: Bryan Shell
>Priority: Minor
>
> Adding an external path and/or jar to the classpath fails to work as 
> expected.  I would expect it to work the same as {noformat}
> "${STORM_DIR}/extlib"{noformat} and 
> {noformat}"${STORM_DIR}/extlib-daemon"{noformat}, and create a complete list 
> of all jars in the path spec(s). 
> Here is an example of the issue:
> {code}
> % STORM_EXT_CLASSPATH=/usr/lib/jvm/default-java/lib/jconsole.jar python
> Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
> [GCC 4.8.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> import fnmatch
> >>> os.getenv('STORM_EXT_CLASSPATH', None)
> '/usr/lib/jvm/default-java/lib/jconsole.jar'
> >>> ret = fnmatch.filter(os.listdir('/opt/HipChat/lib/'), "*.so")
> >>> ret
> ['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 
> 'libhipchatdbusscripting.so', 'libcanberra.so', 'libvorbis.so', 
> 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 'libqxmpp.so', 
> 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 

[jira] [Commented] (STORM-1026) Adding external classpath elements does not work

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-1026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727907#comment-14727907
 ] 

ASF GitHub Bot commented on STORM-1026:
---

GitHub user shellbj opened a pull request:

https://github.com/apache/storm/pull/715

STORM-1026: Expand external classpaths to include any jars



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shellbj/storm STORM-1026

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/715.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 #715


commit 62ab4bc114a42115bfdcae2a38456548138a9b0d
Author: Bryan Shell 
Date:   2015-09-02T19:45:04Z

STORM-1026: Expand external classpaths to include any jars




> Adding external classpath elements does not work
> 
>
> Key: STORM-1026
> URL: https://issues.apache.org/jira/browse/STORM-1026
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.10.0, 0.11.0, 0.9.6
>Reporter: Bryan Shell
>Priority: Minor
>
> Adding an external path and/or jar to the classpath fails to work as 
> expected.  I would expect it to work the same as {noformat}
> "${STORM_DIR}/extlib"{noformat} and 
> {noformat}"${STORM_DIR}/extlib-daemon"{noformat}, and create a complete list 
> of all jars in the path spec(s). 
> Here is an example of the issue:
> {code}
> % STORM_EXT_CLASSPATH=/usr/lib/jvm/default-java/lib/jconsole.jar python
> Python 2.7.6 (default, Jun 22 2015, 17:58:13) 
> [GCC 4.8.2] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import os
> >>> import fnmatch
> >>> os.getenv('STORM_EXT_CLASSPATH', None)
> '/usr/lib/jvm/default-java/lib/jconsole.jar'
> >>> ret = fnmatch.filter(os.listdir('/opt/HipChat/lib/'), "*.so")
> >>> ret
> ['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 
> 'libhipchatdbusscripting.so', 'libcanberra.so', 'libvorbis.so', 
> 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 'libqxmpp.so', 
> 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 'libz.so', 
> 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
> 'libcanberraSoundNotification.so']
> >>> ret.extend(os.getenv('STORM_EXT_CLASSPATH', None))
> >>> ret
> ['libxml2.so', 'libogg.so', 'libdbusmenu-qt5.so', 
> 'libhipchatdbusscripting.so', 'libcanberra.so', 'libvorbis.so', 
> 'libxcb-sync.so', 'libxslt.so', 'liblzma.so', 'libqxmpp.so', 
> 'libvorbisfile.so', 'libssl.so', 'libpng16.so', 'libsqlite3.so', 'libz.so', 
> 'libadl_sdk.so', 'libtdb.so', 'libuuid.so', 'libcrypto.so', 
> 'libcanberraSoundNotification.so', '/', 'u', 's', 'r', '/', 'l', 'i', 'b', 
> '/', 'j', 'v', 'm', '/', 'd', 'e', 'f', 'a', 'u', 'l', 't', '-', 'j', 'a', 
> 'v', 'a', '/', 'l', 'i', 'b', '/', 'j', 'c', 'o', 'n', 's', 'o', 'l', 'e', 
> '.', 'j', 'a', 'r']
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] storm pull request: STORM-1026: Expand external classpaths to incl...

[shellbj]

GitHub user shellbj opened a pull request:

https://github.com/apache/storm/pull/715

STORM-1026: Expand external classpaths to include any jars



You can merge this pull request into a Git repository by running:

$ git pull https://github.com/shellbj/storm STORM-1026

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/storm/pull/715.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 #715


commit 62ab4bc114a42115bfdcae2a38456548138a9b0d
Author: Bryan Shell 
Date:   2015-09-02T19:45:04Z

STORM-1026: Expand external classpaths to include any jars




---
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.
---

Storm UI does not load

[Matthias J. Sax]

Hi,

I am running Debian Jessy in my laptop. Up to now I never had problems
to access Storm UI via Iceweasel (ie, Debian's Firefox). But now, the UI
does not load completely. It displays "Loading summary..." and the
background is shaded. The cluster summary on top of the page is not
rendered correctly. See attached screenshot.

The UI loads without problems using Opera.

I am building Storm from the sources using the current master version
(0.11.0-SNAPSHOT). I just rebased. The last commit is

> commit 154e9ec55deb4eea8fca8554e4d3b224bf337834

I am not sure what the cause of the problem might be, but I do install
available OS updates regularly. I guess that an update changed
something. (Maybe an upgrade to a new version of Iceweasel?) The
currently installed version is 31.8.0.

Maybe anyone can reproduce the problem and have a look into it? For now,
I just use Opera. So for me, it's not urgent.


-Matthias


signature.asc
Description: OpenPGP digital signature

Overflow buffer and metrics

[Abhishek Agarwal]

I have been facing a scenario recently wherein the topology is just hung.
In stack trace, I can see that KafkaSpout is stuck on metrics_tick.invoke.
Since it is not able to find free slot in the disruptor queue. Acker taks
is blocked on disruptor queue as well. I noticed that Nathan had a fixed a
deadlock scenario by introducing an overflow buffer. But this overflow
buffer is not used when metrics are emitted. Could that not result in the
same deadlock?
Here is the stack of KafkaSpout

"Thread-109-KafkaSpout" #145 prio=5 os_prio=0 tid=0x7f7f20aae800
nid=0x3c81 runnable [0x7f7cceae9000]

   java.lang.Thread.State: TIMED_WAITING (parking)

at sun.misc.Unsafe.park(Native Method)

at
java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:338)

at
com.lmax.disruptor.SingleThreadedClaimStrategy.waitForFreeSlotAt(SingleThreadedClaimStrategy.java:129)

at
com.lmax.disruptor.SingleThreadedClaimStrategy.incrementAndGet(SingleThreadedClaimStrategy.java:81)

at com.lmax.disruptor.Sequencer.next(Sequencer.java:127)

at
backtype.storm.utils.DisruptorQueue.publishDirect(DisruptorQueue.java:174)

at
backtype.storm.utils.DisruptorQueue.publish(DisruptorQueue.java:167)

at backtype.storm.disruptor$publish.invoke(disruptor.clj:66)

at
backtype.storm.daemon.executor$mk_executor_transfer_fn$this__6431.invoke(executor.clj:190)

at
backtype.storm.daemon.executor$mk_executor_transfer_fn$this__6431.invoke(executor.clj:197)

at backtype.storm.daemon.task$send_unanchored.invoke(task.clj:112)

at backtype.storm.daemon.task$send_unanchored.invoke(task.clj:117)

at
backtype.storm.daemon.executor$metrics_tick.invoke(executor.clj:296)

at
backtype.storm.daemon.executor$fn__6579$tuple_action_fn__6585.invoke(executor.clj:438)

at
backtype.storm.daemon.executor$mk_task_receiver$fn__6570.invoke(executor.clj:404)

at
backtype.storm.disruptor$clojure_handler$reify__1605.onEvent(disruptor.clj:58)

at
backtype.storm.utils.DisruptorQueue.consumeBatchToCursor(DisruptorQueue.java:125)

at
backtype.storm.utils.DisruptorQueue.consumeBatch(DisruptorQueue.java:87)

at backtype.storm.disruptor$consume_batch.invoke(disruptor.clj:76)

at
backtype.storm.daemon.executor$fn__6579$fn__6594$fn__6623.invoke(executor.clj:542)

at backtype.storm.util$async_loop$fn__459.invoke(util.clj:463)

at clojure.lang.AFn.run(AFn.java:24)

at java.lang.Thread.run(Thread.java:745)

-- 
Regards,
Abhishek Agarwal

[GitHub] storm pull request: STORM-969: HDFS Bolt can end up in an unrecove...

[dossett]

Github user dossett commented on the pull request:

https://github.com/apache/storm/pull/664#issuecomment-137064748
  
@arunmahadevan So it can!  PR updated.


---
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-969) HDFS Bolt can end up in an unrecoverable state

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/STORM-969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14727293#comment-14727293
 ] 

ASF GitHub Bot commented on STORM-969:
--

Github user dossett commented on the pull request:

https://github.com/apache/storm/pull/664#issuecomment-137064748
  
@arunmahadevan So it can!  PR updated.


> HDFS Bolt can end up in an unrecoverable state
> --
>
> Key: STORM-969
> URL: https://issues.apache.org/jira/browse/STORM-969
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-hdfs
>Reporter: Aaron Dossett
>Assignee: Aaron Dossett
>
> The body of the HDFSBolt.execute() method is essentially one try-catch block. 
>  The catch block reports the error and fails the current tuple.  In some 
> cases the bolt's FSDataOutputStream object (named 'out') is in an 
> unrecoverable state and no subsequent calls to execute() can succeed.
> To produce this scenario:
> - process some tuples through HDFS bolt
> - put the underlying HDFS system into safemode
> - process some more tuples and receive a correct ClosedChannelException
> - take the underlying HDFS system out of safemode
> - subsequent tuples continue to fail with the same exception
> The three fundamental operations that execute takes (writing, sync'ing, 
> rotating) need to be isolated so that errors from each are specifically 
> handled.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)