Re: Storm 2.5.0 Release Candidate Vote

[Derek Dagit]

I downloaded the release files:

∴ wget -r -np 
'https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.5.0-rc2/'

I checked signatures:

∴ ls *.asc|xargs -n1 gpg --verify
gpg: assuming signed data in 'apache-storm-2.5.0.pom'
gpg: Signature made Tue 25 Jul 2023 09:33:30 AM CDT
gpg:using RSA key 51379DA8A7AE5B02674EF15C134716AF768D9B6E
gpg: Good signature from "Bipin Prasad (For Signing Apache Storm release) 
" [full]
gpg: assuming signed data in 'apache-storm-2.5.0-src.tar.gz'
gpg: Signature made Tue 25 Jul 2023 09:34:52 AM CDT
gpg:using RSA key 51379DA8A7AE5B02674EF15C134716AF768D9B6E
gpg: Good signature from "Bipin Prasad (For Signing Apache Storm release) 
" [full]
gpg: assuming signed data in 'apache-storm-2.5.0-src.zip'
gpg: Signature made Tue 25 Jul 2023 09:34:52 AM CDT
gpg:using RSA key 51379DA8A7AE5B02674EF15C134716AF768D9B6E
gpg: Good signature from "Bipin Prasad (For Signing Apache Storm release) 
" [full]
gpg: assuming signed data in 'apache-storm-2.5.0.tar.gz'
gpg: Signature made Tue 25 Jul 2023 09:33:39 AM CDT
gpg:using RSA key 51379DA8A7AE5B02674EF15C134716AF768D9B6E
gpg: Good signature from "Bipin Prasad (For Signing Apache Storm release) 
" [full]
gpg: assuming signed data in 'apache-storm-2.5.0.zip'
gpg: Signature made Tue 25 Jul 2023 09:33:39 AM CDT
gpg:using RSA key 51379DA8A7AE5B02674EF15C134716AF768D9B6E
gpg: Good signature from "Bipin Prasad (For Signing Apache Storm release) 
" [full]
gpg: assuming signed data in 'RELEASE_NOTES.html'
gpg: Signature made Tue 25 Jul 2023 09:47:54 AM CDT
gpg:using RSA key 51379DA8A7AE5B02674EF15C134716AF768D9B6E
gpg: Good signature from "Bipin Prasad (For Signing Apache Storm release) 
" [full]



I checked checksums:

∴ ls *.sha512|while read f; do gpg --print-md SHA512 "${f%%.sha512}" | diff -s 
- "$f"; done

Each one of these failed because the format does not match what results from
following the instructions at
https://github.com/apache/storm/blob/master/RELEASING.md#setting-up-a-vote.

I retried this way:

∴ ls *.sha512|while read f; do sha512sum "${f%%.sha512}" | diff -s - "$f"; done
Files - and apache-storm-2.5.0.pom.asc.sha512 are identical
Files - and apache-storm-2.5.0.pom.sha512 are identical
Files - and apache-storm-2.5.0-src.tar.gz.asc.sha512 are identical
Files - and apache-storm-2.5.0-src.tar.gz.sha512 are identical
Files - and apache-storm-2.5.0-src.zip.asc.sha512 are identical
Files - and apache-storm-2.5.0-src.zip.sha512 are identical
Files - and apache-storm-2.5.0.tar.gz.asc.sha512 are identical
Files - and apache-storm-2.5.0.tar.gz.sha512 are identical
Files - and apache-storm-2.5.0.zip.asc.sha512 are identical
Files - and apache-storm-2.5.0.zip.sha512 are identical
Files - and RELEASE_NOTES.html.asc.sha512 are identical
Files - and RELEASE_NOTES.html.sha512 are identical

Looks OK.



Unzipped the source, built and ran tests with `mvn clean && mvn install`

I needed to use the trick at https://stackoverflow.com/a/70673228 to avoid the 
"Blocked mirror for repositories" error maven throws when trying to download 
with plain HTTP.

Eventually, the project failed to build because conjars.org was down:

[ERROR] Failed to execute goal on project storm-autocreds: Could not resolve 
dependencies for project org.apache.storm:storm-autocreds:jar:2.5.0: Failed to 
collect dependencies at 
org.apache.hive.hcatalog:hive-webhcat-java-client:jar:2.3.9 -> 
org.apache.hive.hcatalog:hive-hcatalog-core:jar:2.3.9 -> 
org.apache.hive:hive-cli:jar:2.3.9 -> org.apache.hive:hive-service:jar:2.3.9 -> 
org.apache.hive:hive-exec:jar:2.3.9 -> 
org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde: Failed to read 
artifact descriptor for 
org.pentaho:pentaho-aggdesigner-algorithm:jar:5.1.5-jhyde: Could not transfer 
artifact org.pentaho:pentaho-aggdesigner-algorithm:pom:5.1.5-jhyde from/to 
conjars (http://conjars.org/repo): transfer failed for 
http://conjars.org/repo/org/pentaho/pentaho-aggdesigner-algorithm/5.1.5-jhyde/pentaho-aggdesigner-algorithm-5.1.5-jhyde.pom:
 Connect to conjars.org:80 [conjars.org/54.235.127.59] failed: Connection timed 
out (Connection timed out) -> [Help 1]


I gave up and couldn't run the automated tests.



Unzipped the distribution, started nimbus, supervisor, logviewer, ui, 
dev-zookeeper, and launched the WordCountTopology build from the source 
directory.

This topology started OK, but none of the workers could launch. They failed 
with:

2023-07-27 23:43:38.720 o.a.s.u.Utils Thread-5 [INFO] Worker Process 
5147794a-1d75-4384-9c01-db08cbceead2:Error: LinkageError occurred while loading 
main class org.apache.storm.LogWriter
2023-07-27 23:43:38.721 o.a.s.u.Utils Thread-5 [INFO] Worker Process 
5147794a-1d75-4384-9c01-db08cbceead2:  java.lang.UnsatisfiedLinkError: 
/usr/lib/jvm/java-11-openjdk/lib/libnio.so: 
/usr/lib/jvm/java-11-openjdk/lib/libnio.so: undefined symbol: 
reuseport_available

So I could not test a 

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

[Derek Dagit]

I downloaded the release artifacts and verified the PGP signatures and
checksums.

I then expanded the source tarball and built the project.

But first I applied following patch that disables testing with python2
because I could not easily install python2 at the time:

```diff
diff --git a/storm-client/pom.xml b/storm-client/pom.xml
index cc78ca2d3..13305d32e 100644
--- a/storm-client/pom.xml
+++ b/storm-client/pom.xml
@@ -271,25 +271,6 @@
 org.codehaus.mojo
 exec-maven-plugin
 
-
-
-python2.7
-
test/py
-
-test_storm_cli.py
-
-
-
../../../bin:$PYTHONPATH
-
true
-
-${skipTests}
-
-python2.7-test
-test
-
-exec
-
-
 
 
 python3
```


My dependency versions were:

openjdk 1.8.0_332
maven 3.8.4
python 3.10
nodejs v17.7.2
ruby 3.0.3p157

My build commands were:

```
mvn clean
mvn install -pl storm-multilang/ruby -am
mvn install -pl storm-multilang/python -am
mvn install -pl storm-multilang/javascript -am
mvn install -pl storm-client -am
mvn install 
```

Unit tests passed.

I unpacked the resulting tarball and ran WordCountTopology and checked
that it was doing work in the UI, and opened the logviewer for a worker.
I deactivated the topoligy via the CLI and rebalance and killed the
topology via the UI.

All seems to work.

+1



Issues Encountered:


0.
There are two spurious files ending in .asc.asc that appear to be invalid and 
should probably be removed from the dist site:

https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.4.0-rc2/apache-storm-2.4.0.tar.gz.asc.asc

https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.4.0-rc2/apache-storm-2.4.0.zip.asc.asc

The source tarball contents match the git repo at
https://github.com/apache/storm/commit/a432e99bca526886655cc1d5b2453a09b302b5ca,
however the source tarball contains several extra files. Most are
'dependency-reduced-pom.xml' files that are build artifacts, and two
other (/storm-core/null and /storm-server/csvmetrics) seem to be test
artifacts. If these are intentionally included in the source
distribution, then disregard.


The following issues could be addressed to help make evaluation of storm
releases more efficient:

1. Builds failed with JDK17, and the WordCount topology could not be run
with JDK11. It would be good to document supported versions of Java and
how to address incompatibilities. (For example, how to adjust the
default worker GC options when using JDK11.)

2. Python 2 reached end-of-life over two years ago. Perhaps we should
drop support for it and remove the test dependency. We do not need to
deliberately break support, but let's not require it for building and
testing the project.
https://www.python.org/doc/sunset-python-2/

3. The build cannot be completed with the latest version of maven. We
should fix this to work or document which versions of maven are
supported.

4. The build instructions in the DEVELOPER.md document are `mvn clean
install`, and this did not work with a fresh Maven repository. Probably
we should update the build steps or adjust the code so that this works
once again.

5. I noticed that worker logs are HTML-escaping program output, but then
the worker logs are rendered in preformatted text blocks. This may not
be what users expect.


Regards,
-- 
Derek


On Wed, Mar 16, 2022 at 07:19:35AM -0700, Bipin Prasad wrote:
> Gentle reminder to vote on this release for Storm 2.4.0 (rc2):
> 
> "How to vote" is described here:
> https://github.com/apache/storm/blob/master/RELEASING.md#how-to-vote-on-a-release-candidate
> 
> *This is a call to vote on releasing Apache Storm 2.4.0 (rc2)*
> 
> Full list of changes in this release:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.4.0-rc2/RELEASE_NOTES.html
> 
> The tag/commit to be voted upon is v2.4.0:
> 
> https://github.com/apache/storm/commit/a432e99bca526886655cc1d5b2453a09b302b5ca
> 
> 
> The source archive being voted upon can be found here:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.4.0-rc2/apache-storm-2.4.0-src.tar.gz
> 
> Other release files, signatures and digests can be found here:
> 
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.4.0-rc2/
> 
> The release artifacts are signed with the 

Re: [VOTE] Release Apache Storm 2.3.0 (rc1)

[Derek Dagit]

+1

Verified sigs and sums
Built from source tarball & ran tests
Started daemons and launched WordCountTopology


Things I noticed:
- In the source tarball, there is a `/storm-core/null` directory that
  seems to have been created as part of testing.
- Tests require Python2.7, which is EOL
- Default GC options seem incompatible with Java 11

On Fri, Sep 24, 2021 at 01:50:59PM -0500, Aaron Gresch wrote:
> +1
> 
> built source from tag
> ran word count topology from release files and validated metrics are
> reporting and jstack works.
> 
> 
> On Thu, Sep 23, 2021 at 7:36 PM Ethan Li  wrote:
> 
> > This is a call to vote on releasing Apache Storm 2.3.0 (rc1)
> >
> > Full list of changes in this release:
> >
> >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.3.0-rc1/RELEASE_NOTES.html
> >
> > The tag/commit to be voted upon is v2.3.0:
> >
> >
> > https://gitbox.apache.org/repos/asf?p=storm.git;a=commit;h=b5252eda18e76c4f42af58d7481ea66cf3ec8471
> >
> > The source archive being voted upon can be found here:
> >
> >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.3.0-rc1/apache-storm-2.3.0-src.tar.gz
> >
> > Other release files, signatures and digests can be found here:
> >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.3.0-rc1/
> >
> > The release artifacts are signed with the following key:
> >
> > https://www.apache.org/dist/storm/KEYS
> >
> > The Nexus staging repository for this release is:
> >
> > https://repository.apache.org/content/repositories/orgapachestorm-1096
> >
> > Please vote on releasing this package as Apache Storm 2.3.0.
> >
> > When voting, please list the actions taken to verify the release.
> >
> > This vote will be open for at least 72 hours.
> >
> > [ ] +1 Release this package as Apache Storm 2.3.0
> > [ ]  0 No opinion
> > [ ] -1 Do not release this package because...
> >
> > Thanks to everyone who contributed to this release.
> >

Re: DigestSaslTransportPlugin hardcode "localhost" server

[Derek Dagit]

Yes, it probably could be considered a bug.

As we were adding authentication and authorization to the project, we
did so for Thrift servers via these plugins. Our team was soon after
required to use Kerberos/SASL because of production environment and
security constraints. So we moved on using the Kerberos plugin
exclusively.

I imagine—but I do not specifically recall—that Andy did test
successfully at the time using a non-production environment—possibly
even with the client and server both on the same 'localhost'. The
intention with these plugins was always that they could be configured in
a production environment, and so it seems to me that this value could be
made configurable rather than hard-coded.
 
-- 
Derek

On Tue, Jun 30, 2020 at 04:56:22PM -0500, Ethan Li wrote:
> 
> This looks like a bug. But I have never used this plugin so I am not sure at 
> this moment. Do you have a stack trace that I can take a look?
> 
> > On Jun 26, 2020, at 7:06 AM, Liang Zhao  wrote:
> >
> > Hi,
> >
> > Due to not being able to use Kerberos, we are exploring
> > the DigestSaslTransportPlugin/PlainSaslTransportPlugin as an alternative.
> > However, when we try to set up a storm cluster with
> > DigestSaslTransportPlugin on kubernetes, we came across errors that
> > SaslException, that digest response format violation, Mismatched URI,
> > storm_thrift_server/nimbus; expecting storm_thrift_server/localhost.
> >
> > A close look at the code indicates there is a hardcode "localhost" in the
> > plugin, and this code has been there for many years.
> >
> > https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/security/auth/digest/DigestSaslTransportPlugin.java#L53
> >
> > I'm a bit puzzled as if this is intentional and can be walked around in
> > configuration or it's a bug that should be fixed?
> >
> > Thanks,
> > Liang
> 

Re: [VOTE] Release Apache Storm 2.1.0 (rc5)

[Derek Dagit]

> But for this release, I think it’s fine for now. What do you think?

Yes, I agree it is not a blocker for the release.

On Thu, Oct 31, 2019 at 10:24:15AM -0500, Ethan Li wrote:
> 
> Derek,
> 
> I would think this not a blocker. We don’t really test JDK9. We only have 
> JDK8 and JDK11 test on travis. We can have a separate JIRA if we want to deal 
> with JDK9.
> But for this release, I think it’s fine for now. What do you think?
> 
> Thanks
> Ethan
> 
> > On Oct 31, 2019, at 9:04 AM, Rui Li  wrote:
> >
> > +1
> > Built from source using maven 3.6.1.
> > Ran unit tests.
> > Built local cluster and submitted and killed a WordCountTopology using 
> > storm jar and storm kill.
> > Launched localhost UI and it worked fine
> >
> >
> > Best,
> > Rui
> >
> >> On Oct 31, 2019, at 1:44 AM, Stig Rohde Døssing  
> >> wrote:
> >>
> >> Derek,
> >>
> >> Are you using Maven 3.6.2? There's a bug causing it to fail to look in the
> >> right repositories for dependencies in some cases
> >> https://github.com/apache/maven/pull/294. If you're using 3.6.2, please try
> >> building with 3.6.1 until that issue is fixed. The kafka-avro-serializer
> >> jar is in Confluent's Maven repo.
> >>
> >> Regarding the illegal reflective access, is the test failing or just
> >> warning about the illegal access? The Kryo guys seem to think it's just a
> >> little annoying, but shouldn't break anything
> >> https://github.com/EsotericSoftware/kryo/issues/543#issuecomment-395894516.
> >> Our CI builds with Java 11 (excluding some Hadoop and Cassandra stuff), so
> >> am a little surprised if one of the tests fail on Java 9+.
> >>
> >> Den tor. 31. okt. 2019 kl. 02.43 skrev Derek Dagit :
> >>
> >>> Differencing the source from version control versus the source in the
> >>> tar.gz:
> >>>
> >>> * We are distributing several dependency-reduced-pom.xml files that are
> >>> not part of the source.
> >>> * There is what appears to be a test directory accidentally included at
> >>> apache-storm-2.1.0/storm-core/null/
> >>>
> >>> These are not blockers for a release.
> >>>
> >>> When building the source with `mvn clean install -DskipTests=true`:
> >>>
> >>> * Build fails for flux-examples due to a missing dependency for
> >>> storm-hdfs: io.confluent:kafka-avro-serializer:jar:1.0
> >>>
> >>> Clearing the dependency-reduced-pom.xml files mentioned above does not
> >>> resolve the problem.
> >>>
> >>> This may be a blocker if it prevents the build generally. Has anyone
> >>> else had trouble downloading this dependency? If not, from where is
> >>> the dependency downloaded?
> >>>
> >>>
> >>> When testing with `mvn clean install`
> >>>
> >>> * The following warning fails test-clojure in storm-core:
> >>> WARNING: Illegal reflective access by
> >>> com.esotericsoftware.kryo.util.UnsafeUtil
> >>>
> >>> This may have to do with changes beginning with Java 9:
> >>> http://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation
> >>>
> >>> When using Java 8 I do not see this failure.
> >>>
> >>> This probably should not be a blocker, but we may have to have a
> >>> work-around.
> >>>
> >>> --
> >>> Derek
> >>>
> >>>
> >>> On Wed, Oct 30, 2019 at 04:23:11PM -0400, Kishorkumar Patil wrote:
> >>>>
> >>>> +1.
> >>>>
> >>>> Built from code. Executed based wordcount and drpc topologies. I executed
> >>>> and compared Based ThroughtputVsLatency and performance and resource uses
> >>>> is same as 2.0.0 release.
> >>>>
> >>>> -Kishor
> >>>>
> >>>> On Wed, Oct 30, 2019 at 3:44 PM Aaron Gresch  wrote:
> >>>>
> >>>>> +1
> >>>>>
> >>>>> Built and ran tests from source.
> >>>>> Ran local WordCountTopology, ran a rebalance and kill and looked at
> >>> logs
> >>>>> for ERRORs.
> >>>>> Validated storm blobstore list and jar command with -c option worked.
> >>>>>
> >>>>>
> >>>>> On Fri, Oct 25, 2019 at 3:09 PM Ethan Li  wrote:
> >>>>&

Re: [VOTE] Release Apache Storm 2.1.0 (rc5)

[Derek Dagit]

Environment: macOS 10.15, JDK 8, maven 3.5.4

Verified sigs and sums

Built a binary release from apache-storm-2.1.0-src.tar.gz

Ran unit tests: passed

Started non-secure cluster and launched WordCountTopology.

Opened the UI and browsed the cluster page, the topology page, and
looked at worker logs.

Deactivated, Activated the topology via the UI buttons.  Did the same
via the CLI.

Topology logs and stats look OK.

+1


On Wed, Oct 30, 2019 at 08:43:45PM -0500, Derek Dagit wrote:
> Differencing the source from version control versus the source in the
> tar.gz:
> 
> * We are distributing several dependency-reduced-pom.xml files that are
>   not part of the source.
> * There is what appears to be a test directory accidentally included at
>   apache-storm-2.1.0/storm-core/null/
> 
> These are not blockers for a release.
> 
> When building the source with `mvn clean install -DskipTests=true`:
> 
> * Build fails for flux-examples due to a missing dependency for
>   storm-hdfs: io.confluent:kafka-avro-serializer:jar:1.0
> 
>   Clearing the dependency-reduced-pom.xml files mentioned above does not
>   resolve the problem.
> 
>   This may be a blocker if it prevents the build generally. Has anyone
>   else had trouble downloading this dependency? If not, from where is
>   the dependency downloaded?
> 
> 
> When testing with `mvn clean install`
> 
> * The following warning fails test-clojure in storm-core:
>   WARNING: Illegal reflective access by 
> com.esotericsoftware.kryo.util.UnsafeUtil
> 
>   This may have to do with changes beginning with Java 9:
>   http://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation
> 
>   When using Java 8 I do not see this failure.
> 
>   This probably should not be a blocker, but we may have to have a
>   work-around.
> 
> -- 
> Derek
> 
> 
> On Wed, Oct 30, 2019 at 04:23:11PM -0400, Kishorkumar Patil wrote:
> > 
> > +1.
> > 
> > Built from code. Executed based wordcount and drpc topologies. I executed
> > and compared Based ThroughtputVsLatency and performance and resource uses
> > is same as 2.0.0 release.
> > 
> > -Kishor
> > 
> > On Wed, Oct 30, 2019 at 3:44 PM Aaron Gresch  wrote:
> > 
> > > +1
> > >
> > > Built and ran tests from source.
> > > Ran local WordCountTopology, ran a rebalance and kill and looked at logs
> > > for ERRORs.
> > > Validated storm blobstore list and jar command with -c option worked.
> > >
> > >
> > > On Fri, Oct 25, 2019 at 3:09 PM Ethan Li  wrote:
> > >
> > > > This is a call to vote on releasing Apache Storm 2.1.0 (rc5)
> > > >
> > > > Full list of changes in this release:
> > > >
> > > >
> > > >
> > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5/RELEASE_NOTES.html
> > > >
> > > > The tag/commit to be voted upon is v2.1.0:
> > > >
> > > >
> > > >
> > > https://gitbox.apache.org/repos/asf?p=storm.git;a=tree;h=9a4a245efeb6d74dc01b0feac77bda0e5709b3f6;hb=79fc9b3e6aeec623b42d165536a936d28f2b12f1
> > > >
> > > > The source archive being voted upon can be found here:
> > > >
> > > >
> > > >
> > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5/apache-storm-2.1.0-src.tar.gz
> > > >
> > > > Other release files, signatures and digests can be found here:
> > > >
> > > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5
> > > >
> > > > The release artifacts are signed with the following key:
> > > >
> > > > https://www.apache.org/dist/storm/KEYS
> > > >
> > > > The Nexus staging repository for this release is:
> > > >
> > > > https://repository.apache.org/content/repositories/orgapachestorm-1089/
> > > >
> > > > Please vote on releasing this package as Apache Storm 2.1.0.
> > > >
> > > > When voting, please list the actions taken to verify the release.
> > > >
> > > > This vote will be open for at least 72 hours.
> > > >
> > > > [ ] +1 Release this package as Apache Storm 2.1.0
> > > > [ ]  0 No opinion
> > > > [ ] -1 Do not release this package because...
> > > >
> > > > Thanks to everyone who contributed to this release.
> > > >
> > >

Re: [VOTE] Release Apache Storm 2.1.0 (rc5)

[Derek Dagit]

> Are you using Maven 3.6.2? There's a bug causing it to fail to look in

Yes! I am using exactly that version. I'll try with a different version.


> Regarding the illegal reflective access, is the test failing or just
> warning about the illegal access? The Kryo guys seem to think it's

It seemed to be a warning, but the warning seemed to trigger an error. I
did not dig into what exactly the problem was, but I did confirm that
with JDK 8 it was OK. Considering we do not see this in CI with JDK 11 I
am thinking it something particular to my environment.

Thanks for the pointers. I am not voting either way yet, and I will try
today to build and test again.



On Thu, Oct 31, 2019 at 07:44:37AM +0100, Stig Rohde Døssing wrote:
> 
> Derek,
> 
> Are you using Maven 3.6.2? There's a bug causing it to fail to look in the
> right repositories for dependencies in some cases
> https://github.com/apache/maven/pull/294. If you're using 3.6.2, please try
> building with 3.6.1 until that issue is fixed. The kafka-avro-serializer
> jar is in Confluent's Maven repo.
> 
> Regarding the illegal reflective access, is the test failing or just
> warning about the illegal access? The Kryo guys seem to think it's just a
> little annoying, but shouldn't break anything
> https://github.com/EsotericSoftware/kryo/issues/543#issuecomment-395894516.
> Our CI builds with Java 11 (excluding some Hadoop and Cassandra stuff), so
> am a little surprised if one of the tests fail on Java 9+.
> 
> Den tor. 31. okt. 2019 kl. 02.43 skrev Derek Dagit :
> 
> > Differencing the source from version control versus the source in the
> > tar.gz:
> >
> > * We are distributing several dependency-reduced-pom.xml files that are
> >   not part of the source.
> > * There is what appears to be a test directory accidentally included at
> >   apache-storm-2.1.0/storm-core/null/
> >
> > These are not blockers for a release.
> >
> > When building the source with `mvn clean install -DskipTests=true`:
> >
> > * Build fails for flux-examples due to a missing dependency for
> >   storm-hdfs: io.confluent:kafka-avro-serializer:jar:1.0
> >
> >   Clearing the dependency-reduced-pom.xml files mentioned above does not
> >   resolve the problem.
> >
> >   This may be a blocker if it prevents the build generally. Has anyone
> >   else had trouble downloading this dependency? If not, from where is
> >   the dependency downloaded?
> >
> >
> > When testing with `mvn clean install`
> >
> > * The following warning fails test-clojure in storm-core:
> >   WARNING: Illegal reflective access by
> > com.esotericsoftware.kryo.util.UnsafeUtil
> >
> >   This may have to do with changes beginning with Java 9:
> >   http://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation
> >
> >   When using Java 8 I do not see this failure.
> >
> >   This probably should not be a blocker, but we may have to have a
> >   work-around.
> >
> > --
> > Derek
> >
> >
> > On Wed, Oct 30, 2019 at 04:23:11PM -0400, Kishorkumar Patil wrote:
> > >
> > > +1.
> > >
> > > Built from code. Executed based wordcount and drpc topologies. I executed
> > > and compared Based ThroughtputVsLatency and performance and resource uses
> > > is same as 2.0.0 release.
> > >
> > > -Kishor
> > >
> > > On Wed, Oct 30, 2019 at 3:44 PM Aaron Gresch  wrote:
> > >
> > > > +1
> > > >
> > > > Built and ran tests from source.
> > > > Ran local WordCountTopology, ran a rebalance and kill and looked at
> > logs
> > > > for ERRORs.
> > > > Validated storm blobstore list and jar command with -c option worked.
> > > >
> > > >
> > > > On Fri, Oct 25, 2019 at 3:09 PM Ethan Li  wrote:
> > > >
> > > > > This is a call to vote on releasing Apache Storm 2.1.0 (rc5)
> > > > >
> > > > > Full list of changes in this release:
> > > > >
> > > > >
> > > > >
> > > >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5/RELEASE_NOTES.html
> > > > >
> > > > > The tag/commit to be voted upon is v2.1.0:
> > > > >
> > > > >
> > > > >
> > > >
> > https://gitbox.apache.org/repos/asf?p=storm.git;a=tree;h=9a4a245efeb6d74dc01b0feac77bda0e5709b3f6;hb=79fc9b3e6aeec623b42d165536a936d28f2b12f1
> > > > >
> > > > > The source archive being voted upon can be found here:
> &g

Re: [VOTE] Release Apache Storm 2.1.0 (rc5)

[Derek Dagit]

Differencing the source from version control versus the source in the
tar.gz:

* We are distributing several dependency-reduced-pom.xml files that are
  not part of the source.
* There is what appears to be a test directory accidentally included at
  apache-storm-2.1.0/storm-core/null/

These are not blockers for a release.

When building the source with `mvn clean install -DskipTests=true`:

* Build fails for flux-examples due to a missing dependency for
  storm-hdfs: io.confluent:kafka-avro-serializer:jar:1.0

  Clearing the dependency-reduced-pom.xml files mentioned above does not
  resolve the problem.

  This may be a blocker if it prevents the build generally. Has anyone
  else had trouble downloading this dependency? If not, from where is
  the dependency downloaded?


When testing with `mvn clean install`

* The following warning fails test-clojure in storm-core:
  WARNING: Illegal reflective access by 
com.esotericsoftware.kryo.util.UnsafeUtil

  This may have to do with changes beginning with Java 9:
  http://openjdk.java.net/jeps/261#Relaxed-strong-encapsulation

  When using Java 8 I do not see this failure.

  This probably should not be a blocker, but we may have to have a
  work-around.

-- 
Derek


On Wed, Oct 30, 2019 at 04:23:11PM -0400, Kishorkumar Patil wrote:
> 
> +1.
> 
> Built from code. Executed based wordcount and drpc topologies. I executed
> and compared Based ThroughtputVsLatency and performance and resource uses
> is same as 2.0.0 release.
> 
> -Kishor
> 
> On Wed, Oct 30, 2019 at 3:44 PM Aaron Gresch  wrote:
> 
> > +1
> >
> > Built and ran tests from source.
> > Ran local WordCountTopology, ran a rebalance and kill and looked at logs
> > for ERRORs.
> > Validated storm blobstore list and jar command with -c option worked.
> >
> >
> > On Fri, Oct 25, 2019 at 3:09 PM Ethan Li  wrote:
> >
> > > This is a call to vote on releasing Apache Storm 2.1.0 (rc5)
> > >
> > > Full list of changes in this release:
> > >
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5/RELEASE_NOTES.html
> > >
> > > The tag/commit to be voted upon is v2.1.0:
> > >
> > >
> > >
> > https://gitbox.apache.org/repos/asf?p=storm.git;a=tree;h=9a4a245efeb6d74dc01b0feac77bda0e5709b3f6;hb=79fc9b3e6aeec623b42d165536a936d28f2b12f1
> > >
> > > The source archive being voted upon can be found here:
> > >
> > >
> > >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5/apache-storm-2.1.0-src.tar.gz
> > >
> > > Other release files, signatures and digests can be found here:
> > >
> > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.1.0-rc5
> > >
> > > The release artifacts are signed with the following key:
> > >
> > > https://www.apache.org/dist/storm/KEYS
> > >
> > > The Nexus staging repository for this release is:
> > >
> > > https://repository.apache.org/content/repositories/orgapachestorm-1089/
> > >
> > > Please vote on releasing this package as Apache Storm 2.1.0.
> > >
> > > When voting, please list the actions taken to verify the release.
> > >
> > > This vote will be open for at least 72 hours.
> > >
> > > [ ] +1 Release this package as Apache Storm 2.1.0
> > > [ ]  0 No opinion
> > > [ ] -1 Do not release this package because...
> > >
> > > Thanks to everyone who contributed to this release.
> > >
> >

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

[Derek Dagit]

Well, the change seems to be to throw an IllegalArgumentException
instead of what was the default behavior: to return a String "Unknown".

It is unclear how it would work outside of a Git working tree (as when
the source is built from a download), so it seems the easiest fix would
be to change the default labels to do nothing and revert to the previous
behavior—if we can convince checkstyle that it is OK.

A better fix might be as you suggested. I like the idea of the build not
behaving differently depending on if it is executed within SCM, at least
if we can help it.

In any case, I am inclined to think that this should be fixed before the
release, as it is a bug that prevents the code from building as per our
instructions.

On Thu, Aug 15, 2019 at 02:08:17PM +0200, Stig Rohde Døssing wrote:
> 
> As far as I can tell, the version plugin is supposed to populate these
> files
> https://github.com/apache/storm/blob/master/storm-client/src/resources/storm-client-version-info.properties
> and
> https://github.com/apache/storm/blob/master/storm-core/src/resources/storm-core-version-info.properties.
> I'm not sure why we need this file in both storm-client and storm-core, I'm
> not sure anything reads the storm-core file, so maybe we can delete it?
> 
> When the build runs, those files are supposed to be populated with version
> info (commit hash, author info and so on) from the plugin. The version info
> is then read into
> https://github.com/apache/storm/blob/925422a5b5ad1c3329a2c2b44db460ae94f70806/storm-client/src/jvm/org/apache/storm/utils/VersionInfo.java.
> The VersionInfo file also loads the Storm version from the pom, where it's
> used to populate e.g. the version in Storm UI for Nimbus and Supervisors.
> 
> It looks like this:
> 
> version=2.0.0
> revision=2ba95bbd1c911d4fc6363b1c4b9c4c6d86ac9aae
> branch=(no branch)
> user=tgoetz
> date=2019-04-29T21:17Z
> url=https://git-wip-us.apache.org/repos/asf/storm.git
> srcChecksum=58779abf76d8a8bbd20a2bd5f466
> 
> The only field I see read is the Storm version from the pom, I'm not sure
> we use the other stuff (e.g. commit hash, commit author). For 2.0.0
> something broke when splitting out storm-client, so the file for that
> module doesn't have all fields populated:
> 
> version=2.0.0
> revision=${version-info.scm.commit}
> branch=${version-info.scm.branch}
> user=tgoetz
> date=${version-info.build.time}
> url=${version-info.scm.uri}
> srcChecksum=${version-info.source.md5}
> 
> It's most likely just because storm-client is missing configuration to run
> the plugin when building.
> 
> I think if we're not using these extra fields from git, we might as well
> drop the version info mojo. If we only need to set the "version" field, we
> don't need to invoke git during the build.
> 
> If we do need these fields for something, we should just make the mojo set
> the fields to "Unknown" if it fails to invoke git (i.e. if SCM.NONE is
> set). I'm guessing what's happening for Derek is that he downloaded the
> sources and is trying to run the build with files that aren't part of a git
> repo. So when the mojo tries to do "git branch" it gets an error.
> 
> What do you think?
> 
> Den tor. 15. aug. 2019 kl. 06.02 skrev Ethan Li :
> 
> > Derek ran into this error when building from source:
> >
> > [ERROR] Failed to execute goal
> > org.apache.storm:storm-maven-plugins:2.1.0:version-info (version-info) on
> > project storm-core: java.lang.IllegalArgumentException: SCM NONE is not
> > supported -> [Help 1]
> >
> >
> > The log before this is
> >
> > [INFO] --- storm-maven-plugins:2.1.0:version-info (version-info) @
> > storm-core ---
> > [WARNING] [svn, info] failed with error code 1
> > [WARNING] [git, branch] failed with error code 128
> > [INFO] SCM: NONE
> >
> >
> > I compared with apache-storm-2.0.0 and found that it can pass although
> > there are similar WARNINGs:
> >
> > [INFO] --- storm-maven-plugins:2.0.0:version-info (version-info) @
> > storm-core ---
> > [WARNING] [svn, info] failed with error code 1
> > [WARNING] [git, branch] failed with error code 128
> > [INFO] SCM: NONE
> > [INFO] Computed MD5: 58779abf76d8a8bbd20a2bd5f466
> >
> > This is the PR that changed the behavior
> > https://github.com/apache/storm/pull/3061/files#diff-f1197661326b04376e94e3b25cc3eedcR197
> > <
> > https://github.com/apache/storm/pull/3061/files#diff-f1197661326b04376e94e3b25cc3eedcR197>.
> > I am not sure what this storm-maven-plugin should do though. Will need to
> > look into it. Or if anyone has better idea, please let me know.
> >
> >
> >
> > > On Aug 14, 2019, at 6:53 PM, P. Taylor Goetz  wrote:
> > >
> > > Nice work Ethan!
> > >
> > > I’ll try to take a look in the next few days.
> > >
> > > -Taylor
> > >
> > >> On Aug 14, 2019, at 2:13 PM, Ethan Li  wrote:
> > >>
> > >> This is a call to vote on releasing Apache Storm 2.1.0 (rc2)
> > >>
> > >> Full list of changes in this release:
> > >>
> > >>
> > 

Re: [ANNOUNCE] New Committer/PMC Member Aaron Gresch

[Derek Dagit]

Welcome, Aaron!

On Sat, Aug 10, 2019 at 08:18:40AM -0500, Ethan Li wrote:
> 
> Congratulations, Aaron!
> 
> Ethan Li
> 
> > On Aug 10, 2019, at 07:36, Alexandre Vermeerbergen 
> >  wrote:
> >
> > This is great news (the more PMC members, the more healthly the Apache
> > Storm project is), welcome Aaron!
> >
> > Alexandre Vermeerbergen
> >
> > Le sam. 10 août 2019 à 10:47, Stig Rohde Døssing
> >  a écrit :
> >>
> >> I'm happy to announce that Aaron Gresch is now a member of the Storm PMC.
> >>
> >> Aaron has been active contributing to Storm for a while now. His
> >> contributions have a good spread around the codebase, in particular having
> >> to do with the blob store, metrics system and scheduling. He helped
> >> implement metrics v2.
> >>
> >> Please join me in welcoming Aaron to the PMC.

Re: [DISCUSS] Next 2.x release

[Derek Dagit]

> We might not able to say how long we want to support a specific
> release line but I would love to see a clear release policy being
> made.

That makes sense. It seems better for us not to choose a specific
calendar date or duration of time.

- We do not want too many release lines supported concurrently.
- We want devs and users to know what to expect.

-- 
Derek

On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li wrote:
> 
> Derek,
> 
> I think it’s a good idea to be more clear on the versioning and release 
> process so users and developers know what to expect. We might not able to say 
> how long we want to support a specific release line but I would love to see a 
> clear release policy being made.
> 
> Thanks,
> Ethan
> 
> > On Aug 9, 2019, at 8:53 AM, Derek Dagit  wrote:
> >
> > On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde Døssing wrote:
> >> Where on the Traffic Server page do they list how long their release
> >> trains survive? I only see dates of release, not how long e.g. 7.x is
> >> supposed to receive support.  Derek,
> >
> > This is a better link: 
> > https://cwiki.apache.org/confluence/display/TS/Release+Management
> >
> > This example, where "RM" means "Release Manager":
> >
> >> 1. We promise to make 1 major release / year, but the RM and community
> >>   can of course make more as necessary
> >>
> >> 2. We only make releases off the LTS branches, which are cut once a
> >>   year off master
> >>
> >> 3. Master is always open, for any type of change (including
> >>   incompatible changes). But don't break compatibility just for fun!
> >>
> >> 4. Master is always stable, i.e. commits should be properly tested and
> >>   reviewed before committed to master.
> >>
> >> 5. All releases are stable releases, following strict Semantic
> >>   Versioning.
> >>
> >> 6. Minor releases are made at the discretion at the discretion of the
> >>   community and the RM.
> >>
> >> 7. Minor releases can include new (small / safe) features, but must be
> >>   compatible within the LTS major version.
> >>
> >> 8. The LTS cycle, 2 years + 6 months Sunset, does not reset when we
> >>make a minor release.
> >
> >
> > Now, I am not proposing we do exactly this. The goal would be to set
> > expectations among developers and the community, and here is one
> > concrete example of how it could be done.
> >
> >> If we're going to promise that a release line survives for a given
> >> amount of time, I think we should do it at the major version level
> >> only
> >
> > Yeah, that sounds reasonable to me. If we choose to commit to something
> > like the above, we should base the decision in part on what kind of
> > resources we have so that we do not over-commit.
> >
> >
> >
> >> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit :
> >>
> >>> What do we think about defining Long-Term Support branches with a fixed
> >>> period of support?
> >>>
> >>> For example, we could say 2.0.x is an LTS release line with support
> >>> ending no earlier than a certain calendar date.
> >>>
> >>> The date could be extended, and it might ultimately be governed by the
> >>> timing of the subsequent release (e.g., 2.1.x or 3.0.x). Keeping things
> >>> clear would imply semantic versioning as mentioned earlier
> >>> (https://semver.org/).
> >>>
> >>> Apache Traffic Server does something like this, to name one project:
> >>>
> >>> https://trafficserver.apache.org/downloads
> >>>
> >>> Having a regular cadence of releases might also help make the process
> >>> easier and help set expectations for users and devs.
> >>>
> >>> --
> >>> Derek
> >>>
> >>> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li wrote:
> >>>>
> >>>> Currently we don’t have a 2.0.x-branch and master is actually
> >>> “2.0.1-SNAPSHOT”.
> >>>>
> >>>> So if we  do a 2.1.0 release,  we will create a 2.1.x-branch based on
> >>> current master, release from there. And we change master to
> >>> “2.2.0-SNAPSHOT”.
> >>>>
> >>>> But we will have one problem: we will lose 2.0.x release line.
> >>>>
> >>>> There are two things I can do:
> >>>>
> >>>> 1) create 

Re: [DISCUSS] Next 2.x release

[Derek Dagit]

On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde Døssing wrote:
> Where on the Traffic Server page do they list how long their release
> trains survive? I only see dates of release, not how long e.g. 7.x is
> supposed to receive support.  Derek,

This is a better link: 
https://cwiki.apache.org/confluence/display/TS/Release+Management

This example, where "RM" means "Release Manager":

> 1. We promise to make 1 major release / year, but the RM and community
>can of course make more as necessary
> 
> 2. We only make releases off the LTS branches, which are cut once a
>year off master
> 
> 3. Master is always open, for any type of change (including
>incompatible changes). But don't break compatibility just for fun!
> 
> 4. Master is always stable, i.e. commits should be properly tested and
>reviewed before committed to master.
> 
> 5. All releases are stable releases, following strict Semantic
>Versioning.
> 
> 6. Minor releases are made at the discretion at the discretion of the
>community and the RM.
> 
> 7. Minor releases can include new (small / safe) features, but must be
>compatible within the LTS major version.
> 
> 8. The LTS cycle, 2 years + 6 months Sunset, does not reset when we
> make a minor release.


Now, I am not proposing we do exactly this. The goal would be to set
expectations among developers and the community, and here is one
concrete example of how it could be done.

> If we're going to promise that a release line survives for a given
> amount of time, I think we should do it at the major version level
> only

Yeah, that sounds reasonable to me. If we choose to commit to something
like the above, we should base the decision in part on what kind of
resources we have so that we do not over-commit.



> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit :
> 
> > What do we think about defining Long-Term Support branches with a fixed
> > period of support?
> >
> > For example, we could say 2.0.x is an LTS release line with support
> > ending no earlier than a certain calendar date.
> >
> > The date could be extended, and it might ultimately be governed by the
> > timing of the subsequent release (e.g., 2.1.x or 3.0.x). Keeping things
> > clear would imply semantic versioning as mentioned earlier
> > (https://semver.org/).
> >
> > Apache Traffic Server does something like this, to name one project:
> >
> > https://trafficserver.apache.org/downloads
> >
> > Having a regular cadence of releases might also help make the process
> > easier and help set expectations for users and devs.
> >
> > --
> > Derek
> >
> > On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li wrote:
> > >
> > > Currently we don’t have a 2.0.x-branch and master is actually
> > “2.0.1-SNAPSHOT”.
> > >
> > > So if we  do a 2.1.0 release,  we will create a 2.1.x-branch based on
> > current master, release from there. And we change master to
> > “2.2.0-SNAPSHOT”.
> > >
> > > But we will have one problem: we will lose 2.0.x release line.
> > >
> > > There are two things I can do:
> > >
> > > 1) create a 2.0.x-branch based on v2.0.0 tag.
> > >
> > > 2) ignore it. If there is an issue with 2.0.x release,  ask users to
> > upgrade to 2.1.0.
> > >
> > > I prefer 1) but not sure if it’s the right way to make things right. Or
> > please let me know if I misunderstood something and it’s not an issue.
> > >
> > > Btw, I am seeing the same issue with 1.x-branch. We shouldn’t have
> > 1.x-branch. Instead, we should have 1.2.x-branch. But this is not a problem
> > since we will not release 1.3.x.
> > >
> > > Thanks,
> > > Ethan
> > >
> > >
> > > > On Aug 7, 2019, at 10:43 AM, Ethan Li 
> > wrote:
> > > >
> > > > Yes thanks.
> > > >
> > > >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
> > stigdoess...@gmail.com> wrote:
> > > >>
> > > >> Sounds great. Remember to add your key to
> > > >> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be
> > able
> > > >> to update it with an SVN client. See also
> > > >> https://www.apache.org/dev/openpgp.html#update.
> > > >>
> > > >> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li <
> > ethanopensou...@gmail.com>:
> > > >>
> > > >>> I got my pgp key signed by Bryan W. Call  > > >>> bc...@apache.org>> (Thanks to him).
&g

Re: [DISCUSS] Next 2.x release

[Derek Dagit]

What do we think about defining Long-Term Support branches with a fixed
period of support?

For example, we could say 2.0.x is an LTS release line with support
ending no earlier than a certain calendar date.

The date could be extended, and it might ultimately be governed by the
timing of the subsequent release (e.g., 2.1.x or 3.0.x). Keeping things
clear would imply semantic versioning as mentioned earlier
(https://semver.org/).

Apache Traffic Server does something like this, to name one project:

https://trafficserver.apache.org/downloads

Having a regular cadence of releases might also help make the process
easier and help set expectations for users and devs.

-- 
Derek

On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li wrote:
> 
> Currently we don’t have a 2.0.x-branch and master is actually 
> “2.0.1-SNAPSHOT”.
> 
> So if we  do a 2.1.0 release,  we will create a 2.1.x-branch based on current 
> master, release from there. And we change master to “2.2.0-SNAPSHOT”.
> 
> But we will have one problem: we will lose 2.0.x release line.
> 
> There are two things I can do:
> 
> 1) create a 2.0.x-branch based on v2.0.0 tag.
> 
> 2) ignore it. If there is an issue with 2.0.x release,  ask users to upgrade 
> to 2.1.0.
> 
> I prefer 1) but not sure if it’s the right way to make things right. Or 
> please let me know if I misunderstood something and it’s not an issue.
> 
> Btw, I am seeing the same issue with 1.x-branch. We shouldn’t have 
> 1.x-branch. Instead, we should have 1.2.x-branch. But this is not a problem 
> since we will not release 1.3.x.
> 
> Thanks,
> Ethan
> 
> 
> > On Aug 7, 2019, at 10:43 AM, Ethan Li  wrote:
> >
> > Yes thanks.
> >
> >> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing  
> >> wrote:
> >>
> >> Sounds great. Remember to add your key to
> >> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be able
> >> to update it with an SVN client. See also
> >> https://www.apache.org/dev/openpgp.html#update.
> >>
> >> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li :
> >>
> >>> I got my pgp key signed by Bryan W. Call  >>> bc...@apache.org>> (Thanks to him).
> >>>
> >>> My pgp key:
> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
> >>> <
> >>> http://pgp.surfnet.nl/pks/lookup?op=vindex=on=0xA4A672F11B5050C8
> 
> >>>
> >>> My understanding is that I am good to do release with this key now.
> >>>
> >>>
> >>> Here is a list of PRs that we might want to include in the new release:
> >>>
> >>> https://github.com/apache/storm/pull/3098 <
> >>> https://github.com/apache/storm/pull/3098>
> >>> https://github.com/apache/storm/pull/3096 <
> >>> https://github.com/apache/storm/pull/3096>
> >>> https://github.com/apache/storm/pull/2878 <
> >>> https://github.com/apache/storm/pull/2878>
> >>>
> >>>
> >>> Please review if you get a chance.  Thanks
> >>>
> >>>
> >>> Ethan
> >>>
> >>>
> >>>
>  On Aug 1, 2019, at 4:19 AM, Stig Rohde Døssing 
> >>> wrote:
> 
>  Thanks Ethan, yes 2.1.0 makes sense.
> 
>  Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li <
> >>> ethanopensou...@gmail.com>:
> 
> > It’s a good point. I will start a discussion thread for it.
> >
> >
> > For the new release, I went through the list:
> >
> >>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1
> > <
> >
> >>> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1
> >>
> >
> > We introduced some new functionalities, including
> > https://issues.apache.org/jira/browse/STORM-2720 <
> > https://issues.apache.org/jira/browse/STORM-2720>
> > https://issues.apache.org/jira/browse/STORM-3412 <
> > https://issues.apache.org/jira/browse/STORM-3412>
> > https://issues.apache.org/jira/browse/STORM-3411 <
> > https://issues.apache.org/jira/browse/STORM-3411>
> > https://issues.apache.org/jira/browse/STORM-3442 <
> > https://issues.apache.org/jira/browse/STORM-3442>
> > https://issues.apache.org/jira/browse/STORM-3396 <
> > https://issues.apache.org/jira/browse/STORM-3396>
> > https://issues.apache.org/jira/browse/STORM-3392 <
> > https://issues.apache.org/jira/browse/STORM-3392>
> > https://issues.apache.org/jira/browse/STORM-3395 <
> > https://issues.apache.org/jira/browse/STORM-3395>
> >
> > So I think we should release 2.1.0 rather than 2.0.1.
> >
> > There are a few pull requests we may want to review before the next
> > release:
> >
> > https://github.com/apache/storm/pull/3094 <
> > https://github.com/apache/storm/pull/3094>
> > https://github.com/apache/storm/pull/2990 <
> > https://github.com/apache/storm/pull/2990>
> > https://github.com/apache/storm/pull/2878 <
> > https://github.com/apache/storm/pull/2878>
> >
> >
> > Thanks
> > Ethan
> >
> >
> >> On Jul 29, 2019, at 10:11 AM, Hugo Louro  wrote:
> >>
> >> +1
> 

Re: [VOTE] Release Apache Storm 2.0.0 RC7

[Derek Dagit]

> we can just bump it to something like 3.5.0. I'll raise an issue for it.

+1 and Thanks Alexandre for finding this, it is a help.

On Wed, May 1, 2019 at 2:18 PM Stig Rohde Døssing 
wrote:

> Yes, we already have a check that the Maven version is above 3.0.0 (
> https://github.com/apache/storm/blob/master/pom.xml#L1439), IMO we can
> just
> bump it to something like 3.5.0. I'll raise an issue for it.
>
> Den ons. 1. maj 2019 kl. 20.59 skrev Alexandre Vermeerbergen <
> avermeerber...@gmail.com>:
>
> > Hello Stig,
> >
> > Good catch: I upgraded Maven to version 3.6.1 and I rebuilt everything
> > from source tar.gz without any trouble.
> >
> > So I delay my vote and I'm no longer blocked since I have
> > storm-kafka-client-2.0.0.jar allowing me to rebuilt my topologies.
> >
> > Just a question: since my experience showed that build Storm 2.0.0
> > break with Maven 3.3.9, wouldn't it be possible to improve Storm's
> > pom.xml to include a Maven version check (see
> > https://maven.apache.org/enforcer/enforcer-rules/versionRanges.html) ?
> >
> > This would improve Storm users' experience a little bit, and sounds
> > very simple to do (not a blocker for 2.0.0 of course).
> >
> > How about that?
> >
> > Kind regards,
> > Alexandre Vermeerbergen
> >
> > Le mer. 1 mai 2019 à 19:42, Stig Rohde Døssing
> >  a écrit :
> > >
> > > I haven't seen the error you're getting before, but it looks like it's
> a
> > > Maven issue, not a Storm issue. Could you try updating to the latest
> > Maven
> > > version?
> > >
> > > Den ons. 1. maj 2019 kl. 19.30 skrev Alexandre Vermeerbergen <
> > > avermeerber...@gmail.com>:
> > >
> > > > Hello,
> > > >
> > > > I don't know if this is worth a -1 because maybe I did something
> > > > wrong, but I got a failure when trying to build binaries from the
> > > > sources, see attached log (zipped) with 4 errors, captured from the
> > > > output of:
> > > >
> > > > mvn clean install -DskipTests 2>&1 build_Storm_2.0.0_rc7.log
> > > >
> > > > more details on my machine:
> > > >
> > > > $ cat /etc/redhat-release
> > > > CentOS release 6.7 (Final)
> > > >
> > > > $ mvn -version
> > > > Apache Maven 3.3.9 (bb52d8502b132ec0a5a3f4c09453c07478323dc5;
> > > > 2015-11-10T17:41:47+01:00)
> > > > Maven home: /home/data/ave/maven/src/apache-maven-3.3.9
> > > > Java version: 1.8.0_66, vendor: Oracle Corporation
> > > > Java home: /usr/java/jdk1.8.0_66_x86_64/jdk1.8.0_66/jre
> > > > Default locale: en_US, platform encoding: UTF-8
> > > > OS name: "linux", version: "2.6.32-573.el6.x86_64", arch: "amd64",
> > > > family: "unix"
> > > >
> > > > I got couple of JAR files built, but I'm missing the
> > > > storm-kafka-client one, so am blocked because I need this "external"
> > > > lib to test my topologies rebuilt with Storm 2.0.0 RC7
> > > >
> > > > Did I missed something that break my Storm 2.0.0 RC7 build?
> > > >
> > > > Kind regards,
> > > > Alexandre Vermeerbergen
> > > >
> > > >
> > > > Le mar. 30 avr. 2019 à 00:49, P. Taylor Goetz  a
> > écrit
> > > > :
> > > > >
> > > > > This is a call to vote on releasing Apache Storm 2.0.0 (rc7)
> > > > >
> > > > > Full list of changes in this release:
> > > > >
> > > > >
> > > >
> >
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/RELEASE_NOTES.html
> > > > >
> > > > > The tag/commit to be voted upon is v2.0.0:
> > > > >
> > > > >
> > > >
> >
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=007863edd95e838b3df414928c6fa3f28244ab49;hb=2ba95bbd1c911d4fc6363b1c4b9c4c6d86ac9aae
> > > > >
> > > > > The source archive being voted upon can be found here:
> > > > >
> > > > >
> > > >
> >
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/apache-storm-2.0.0-src.tar.gz
> > > > >
> > > > > Other release files, signatures and digests can be found here:
> > > > >
> > > > >
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/
> > > > >
> > > > > The release artifacts are signed with the following key:
> > > > >
> > > > >
> > > >
> >
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> > > > >
> > > > > The Nexus staging repository for this release is:
> > > > >
> > > > >
> > https://repository.apache.org/content/repositories/orgapachestorm-1079
> > > > >
> > > > > Please vote on releasing this package as Apache Storm 2.0.0.
> > > > >
> > > > > When voting, please list the actions taken to verify the release.
> > > > >
> > > > > This vote will be open for at least 72 hours.
> > > > >
> > > > > [ ] +1 Release this package as Apache Storm 2.0.0
> > > > > [ ]  0 No opinion
> > > > > [ ] -1 Do not release this package because...
> > > > >
> > > > > Thanks to everyone who contributed to this release.
> > > > >
> > > > > -Taylor
> > > >
> >
>

Re: [VOTE] Release Apache Storm 2.0.0 RC7

[Derek Dagit]

OK ran the distribution from the tarball, and built and ran from the src
tarball on macOS with JDK8. Tested WordCountTopology on both and it seemed
fine.

+1

On Tue, Apr 30, 2019 at 11:55 AM Derek Dagit  wrote:

> Sent too soon:
>
> - I verified sigs and sums
> - Built the source from the tarball on macOS
>   - I saw a couple of test errors because the local stormconf.ser was gone
> when the supervisor tried to open it, and this resulted in a crash. I
> re-ran the tests and they passed.
>   - I do not think this is a blocker, but it is probable worth looking
> into.
>
> I'll continue to evaluate the RC, but wanted to send this out in case
> anyone else has seen something similar.
>
> On Tue, Apr 30, 2019 at 11:52 AM Derek Dagit  wrote:
>
>> - I verified sigs and sums
>>
>> On Mon, Apr 29, 2019 at 5:49 PM P. Taylor Goetz 
>> wrote:
>>
>>> This is a call to vote on releasing Apache Storm 2.0.0 (rc7)
>>>
>>> Full list of changes in this release:
>>>
>>>
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/RELEASE_NOTES.html
>>>
>>> The tag/commit to be voted upon is v2.0.0:
>>>
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=007863edd95e838b3df414928c6fa3f28244ab49;hb=2ba95bbd1c911d4fc6363b1c4b9c4c6d86ac9aae
>>>
>>> The source archive being voted upon can be found here:
>>>
>>>
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/apache-storm-2.0.0-src.tar.gz
>>>
>>> Other release files, signatures and digests can be found here:
>>>
>>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/
>>>
>>> The release artifacts are signed with the following key:
>>>
>>>
>>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>>>
>>> The Nexus staging repository for this release is:
>>>
>>> https://repository.apache.org/content/repositories/orgapachestorm-1079
>>>
>>> Please vote on releasing this package as Apache Storm 2.0.0.
>>>
>>> When voting, please list the actions taken to verify the release.
>>>
>>> This vote will be open for at least 72 hours.
>>>
>>> [ ] +1 Release this package as Apache Storm 2.0.0
>>> [ ]  0 No opinion
>>> [ ] -1 Do not release this package because...
>>>
>>> Thanks to everyone who contributed to this release.
>>>
>>> -Taylor
>>
>>

Re: [VOTE] Release Apache Storm 2.0.0 RC7

[Derek Dagit]

Sent too soon:

- I verified sigs and sums
- Built the source from the tarball on macOS
  - I saw a couple of test errors because the local stormconf.ser was gone
when the supervisor tried to open it, and this resulted in a crash. I
re-ran the tests and they passed.
  - I do not think this is a blocker, but it is probable worth looking into.

I'll continue to evaluate the RC, but wanted to send this out in case
anyone else has seen something similar.

On Tue, Apr 30, 2019 at 11:52 AM Derek Dagit  wrote:

> - I verified sigs and sums
>
> On Mon, Apr 29, 2019 at 5:49 PM P. Taylor Goetz  wrote:
>
>> This is a call to vote on releasing Apache Storm 2.0.0 (rc7)
>>
>> Full list of changes in this release:
>>
>>
>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/RELEASE_NOTES.html
>>
>> The tag/commit to be voted upon is v2.0.0:
>>
>>
>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=007863edd95e838b3df414928c6fa3f28244ab49;hb=2ba95bbd1c911d4fc6363b1c4b9c4c6d86ac9aae
>>
>> The source archive being voted upon can be found here:
>>
>>
>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/apache-storm-2.0.0-src.tar.gz
>>
>> Other release files, signatures and digests can be found here:
>>
>> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/
>>
>> The release artifacts are signed with the following key:
>>
>>
>> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>>
>> The Nexus staging repository for this release is:
>>
>> https://repository.apache.org/content/repositories/orgapachestorm-1079
>>
>> Please vote on releasing this package as Apache Storm 2.0.0.
>>
>> When voting, please list the actions taken to verify the release.
>>
>> This vote will be open for at least 72 hours.
>>
>> [ ] +1 Release this package as Apache Storm 2.0.0
>> [ ]  0 No opinion
>> [ ] -1 Do not release this package because...
>>
>> Thanks to everyone who contributed to this release.
>>
>> -Taylor
>
>

Re: [VOTE] Release Apache Storm 2.0.0 RC7

[Derek Dagit]

- I verified sigs and sums

On Mon, Apr 29, 2019 at 5:49 PM P. Taylor Goetz  wrote:

> This is a call to vote on releasing Apache Storm 2.0.0 (rc7)
>
> Full list of changes in this release:
>
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/RELEASE_NOTES.html
>
> The tag/commit to be voted upon is v2.0.0:
>
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=007863edd95e838b3df414928c6fa3f28244ab49;hb=2ba95bbd1c911d4fc6363b1c4b9c4c6d86ac9aae
>
> The source archive being voted upon can be found here:
>
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/apache-storm-2.0.0-src.tar.gz
>
> Other release files, signatures and digests can be found here:
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc7/
>
> The release artifacts are signed with the following key:
>
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>
> The Nexus staging repository for this release is:
>
> https://repository.apache.org/content/repositories/orgapachestorm-1079
>
> Please vote on releasing this package as Apache Storm 2.0.0.
>
> When voting, please list the actions taken to verify the release.
>
> This vote will be open for at least 72 hours.
>
> [ ] +1 Release this package as Apache Storm 2.0.0
> [ ]  0 No opinion
> [ ] -1 Do not release this package because...
>
> Thanks to everyone who contributed to this release.
>
> -Taylor

Re: [VOTE] Release Apache Storm 2.0.0 RC5

[Derek Dagit]

* Downloaded source ZIP, `mvn clean install`, all passed
* Verified signatures and checksums
* Packaged my build and ran a single-tenant (default) cluster
* Ran org.apache.storm.starter.WordCountTopology
* UI seemed OK, Visualization seemed OK, Logviewer seemed OK

+1

On Fri, Mar 22, 2019 at 3:23 PM P. Taylor Goetz  wrote:

> This is a call to vote on releasing Apache Storm 2.0.0 (rc5)
>
> Full list of changes in this release:
>
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc5/RELEASE_NOTES.html
>
> The tag/commit to be voted upon is v2.0.0:
>
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=7e0a711e4ed5315f04f9f726caff61e0f169e320;hb=b5823809bd4b438e789a36f163f318d4b161ad13
>
> The source archive being voted upon can be found here:
>
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc5/apache-storm-2.0.0-src.tar.gz
>
> Other release files, signatures and digests can be found here:
>
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc5/
>
> The release artifacts are signed with the following key:
>
>
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
>
> The Nexus staging repository for this release is:
>
> https://repository.apache.org/content/repositories/orgapachestorm-1076
>
> Please vote on releasing this package as Apache Storm 2.0.0.
>
> When voting, please list the actions taken to verify the release.
>
> This vote will be open for at least 72 hours.
>
> [ ] +1 Release this package as Apache Storm 2.0.0
> [ ]  0 No opinion
> [ ] -1 Do not release this package because...
>
> Thanks to everyone who contributed to this release.
>
> -Taylor

Re: [VOTE] Migration of git repos to gitbox.apache.org

[Derek Dagit]

+1 Thank you for looking into this.

On Fri, Jan 18, 2019 at 9:45 AM Ethan Li  wrote:

> This is a call to vote on migration of git repos to gitbox.apache.org <
> http://gitbox.apache.org/>.
>
> The following repositories on git-wip-us belong to our project:
> - storm-site.git
> - storm.git
>
> All repositories not migrated on February 7th will be mass migrated
> without warning. It’s better to work with the infrastructure team to avoid
> the mass that day.
>
> The notice email is at
> https://lists.apache.org/thread.html/2bb953946ee6652a054329df2814f512f9186e863ec841555f9cc26a@%3Cdev.storm.apache.org%3E
> <
> https://lists.apache.org/thread.html/2bb953946ee6652a054329df2814f512f9186e863ec841555f9cc26a@%3Cdev.storm.apache.org%3E
> >
>
> This vote will be open for at least 24 hours.
>
> Thanks
>
> - Ethan



-- 
Derek

Re: NimbusLeaderNotFoundException

[Derek Dagit]

I would be OK with this.

On Wed, Dec 5, 2018 at 11:24 AM Aaron Gresch  wrote:

> I was wondering if there was support to change
>
> https://git.ouroath.com/storm/storm/blob/master/storm-client/src/jvm/org/apache/storm/utils/NimbusLeaderNotFoundException.java
> to a checked exception.
>


-- 
Derek

Re: [VOTE] Release Apache Storm 2.0.0 (rc3)

[Derek Dagit]

Verified sigs and sums.
Unpacked the tarball and ran WordCountTopology, and accessed the UI and log
viewer.
Did not find unexpected messages in logs.

+1

On Fri, Oct 19, 2018 at 10:55 AM Julien Nioche <
lists.digitalpeb...@gmail.com> wrote:

> Sorry, hit Return too quickly
>
> I am testing Storm 2.0.0 with StormCrawler, not very successfully. One
> immediate issue is that I am getting a version conflict on httpclient as
> the version set by Storm is older than the one I need.
>
> java.lang.NoSuchMethodError:
>
> org.apache.http.impl.client.HttpClientBuilder.setConnectionManagerShared(Z)Lorg/apache/http/impl/client/HttpClientBuilder;
> at
>
> com.digitalpebble.stormcrawler.protocol.httpclient.HttpProtocol.configure(HttpProtocol.java:141)
> ~[2-1.0-SNAPSHOT.jar:?]
> at
>
> com.digitalpebble.stormcrawler.protocol.ProtocolFactory.(ProtocolFactory.java:69)
> ~[2-1.0-SNAPSHOT.jar:?]
> at
>
> com.digitalpebble.stormcrawler.bolt.FetcherBolt.prepare(FetcherBolt.java:760)
> ~[2-1.0-SNAPSHOT.jar:?]
> at org.apache.storm.executor.bolt.BoltExecutor.init(BoltExecutor.java:144)
> ~[storm-client-2.0.0.jar:2.0.0]
> at org.apache.storm.executor.bolt.BoltExecutor.call(BoltExecutor.java:154)
> ~[storm-client-2.0.0.jar:2.0.0]
> at org.apache.storm.executor.bolt.BoltExecutor.call(BoltExecutor.java:58)
> ~[storm-client-2.0.0.jar:2.0.0]
> at org.apache.storm.utils.Utils$1.run(Utils.java:353)
> [storm-client-2.0.0.jar:2.0.0]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_191]
>
> Here is the classpath when calling *storm local *
>
> *16:38:03.445 [main] INFO  o.a.s.s.o.a.z.ZooKeeper - Client
>
> environment:java.class.path=/data/apache-storm-2.0.0/*:/data/apache-storm-2.0.0/lib/log4j-over-slf4j-1.6.6.jar:/data/apache-storm-2.0.0/lib/hadoop-auth-2.6.1.jar:/data/apache-storm-2.0.0/lib/jaxb-api-2.3.0.jar:/data/apache-storm-2.0.0/lib/kryo-shaded-3.0.3.jar:/data/apache-storm-2.0.0/lib/kryo-3.0.3.jar:/data/apache-storm-2.0.0/lib/commons-cli-1.4.jar:/data/apache-storm-2.0.0/lib/log4j-slf4j-impl-2.11.1.jar:/data/apache-storm-2.0.0/lib/jetty-continuation-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/httpclient-4.3.3.jar:/data/apache-storm-2.0.0/lib/commons-io-2.6.jar:/data/apache-storm-2.0.0/lib/commons-collections-3.2.2.jar:/data/apache-storm-2.0.0/lib/guava-16.0.1.jar:/data/apache-storm-2.0.0/lib/metrics-graphite-3.2.6.jar:/data/apache-storm-2.0.0/lib/jetty-http-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/tools.logging-0.2.3.jar:/data/apache-storm-2.0.0/lib/jetty-util-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/rocksdbjni-5.8.6.jar:/data/apache-storm-2.0.0/lib/commons-fileupload-1.3.3.jar:/data/apache-storm-2.0.0/lib/curator-framework-4.0.1.jar:/data/apache-storm-2.0.0/lib/jackson-dataformat-smile-2.9.4.jar:/data/apache-storm-2.0.0/lib/asm-5.0.3.jar:/data/apache-storm-2.0.0/lib/jetty-io-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/chill-java-0.8.0.jar:/data/apache-storm-2.0.0/lib/curator-client-4.0.1.jar:/data/apache-storm-2.0.0/lib/httpcore-4.3.2.jar:/data/apache-storm-2.0.0/lib/log4j-api-2.11.1.jar:/data/apache-storm-2.0.0/lib/jetty-security-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/storm-clojure-2.0.0.jar:/data/apache-storm-2.0.0/lib/commons-compress-1.16.1.jar:/data/apache-storm-2.0.0/lib/jetty-server-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/netty-3.7.0.Final.jar:/data/apache-storm-2.0.0/lib/json-simple-1.1.jar:/data/apache-storm-2.0.0/lib/junit-4.12.jar:/data/apache-storm-2.0.0/lib/jetty-servlet-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/objenesis-2.6.jar:/data/apache-storm-2.0.0/lib/jetty-servlets-9.4.7.v20170914.jar:/data/apache-storm-2.0.0/lib/carbonite-1.5.0.jar:/data/apache-storm-2.0.0/lib/storm-server-2.0.0.jar:/data/apache-storm-2.0.0/lib/shaded-deps-2.0.0.jar:/data/apache-storm-2.0.0/lib/javax.servlet-api-3.1.0.jar:/data/apache-storm-2.0.0/lib/commons-logging-1.1.3.jar:/data/apache-storm-2.0.0/lib/jline-0.9.94.jar:/data/apache-storm-2.0.0/lib/storm-client-2.0.0.jar:/data/apache-storm-2.0.0/lib/snakeyaml-1.11.jar:/data/apache-storm-2.0.0/lib/hamcrest-core-1.3.jar:/data/apache-storm-2.0.0/lib/minlog-1.3.0.jar:/data/apache-storm-2.0.0/lib/slf4j-api-1.7.21.jar:/data/apache-storm-2.0.0/lib/log4j-core-2.11.1.jar:/data/apache-storm-2.0.0/lib/commons-exec-1.3.jar:/data/apache-storm-2.0.0/lib/storm-core-2.0.0.jar:/data/apache-storm-2.0.0/lib/jackson-core-2.9.4.jar:/data/apache-storm-2.0.0/lib/zookeeper-3.4.6.jar:/data/apache-storm-2.0.0/lib/commons-lang-2.6.jar:/data/apache-storm-2.0.0/lib/clojure-1.7.0.jar:/data/apache-storm-2.0.0/lib/metrics-core-3.2.6.jar:/data/apache-storm-2.0.0/lib/reflectasm-1.10.1.jar:/data/apache-storm-2.0.0/lib/commons-codec-1.11.jar:/data/apache-storm-2.0.0/lib/joda-time-2.3.jar:/data/apache-storm-2.0.0/extlib/*:target/2-1.0-SNAPSHOT.jar:/data/apache-storm-2.0.0/conf:/data/apache-storm-2.0.0/bin*
>
> This doesn't happen with Storm 1.2.2. Aren't these libs supposed to be
> shaded by Storm?
>
> Another issue is when I try to launch a topology from Eclipse (as I 

Re: Cleaning Up Old Pull Requests STORM-3250

[Derek Dagit]

OK the Pull Request is up, and I am open to change the wording, etc.

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

On Wed, Oct 10, 2018 at 2:58 PM Stig Rohde Døssing 
wrote:

> Thanks for explaining, that makes sense. It's probably easier to go over
> the issues once the PRs are closed, instead of having to handle them all at
> the same time.
>
> Den ons. 10. okt. 2018 kl. 20.27 skrev Derek Dagit  >:
>
> > > What is the value in keeping the associated Jira issues around though?
> >
> > 1) I had thought Jira issues could be valid even if they are stale,
> whereas
> > pull requests typically are not valid when they go stale.
> > 2) It is less effort. :)
> >
> > The simplest thing to do would be to run a similar query (not updated in
> > 2018) and close the issues with a common message.
> >
> >
> >
> https://issues.apache.org/jira/browse/STORM-579?jql=project%20%3D%20STORM%20AND%20statusCategory%20!%3D%20done%20AND%20updatedDate%20%3C%20startOfYear()%20ORDER%20BY%20updated%20ASC
> >
> > It seems there are currently 800+ issues that match. That is an awful
> lot.
> > I would be open to handling these in bulk too if that is what we want.
> >
> >
> > On Wed, Oct 10, 2018 at 1:19 PM Hugo Louro  wrote:
> >
> > > Derek, I am OK with closing them all. By phase I meant perhaps leaving
> > some
> > > of the most recent one's in case the author wants to resume them...
> but I
> > > guess he can always reopen them.
> > > Stig, the JIRAs I think the should be handled on an individual basis.
> If
> > > they are still revenant, leave the JIRA open hoping someone will pick
> it
> > > up. If they are no longer relevant, perhaps close as "will not fix" or
> > > something like that.
> > >
> > > Hugo
> > >
> > > On Wed, Oct 10, 2018 at 11:12 AM Stig Rohde Døssing <
> > > stigdoess...@gmail.com>
> > > wrote:
> > >
> > > > +1 to close old PRs.
> > > >
> > > > What is the value in keeping the associated Jira issues around
> though?
> > > >
> > > > Den tir. 9. okt. 2018 kl. 17.18 skrev Derek Dagit
> > >  > > > >:
> > > >
> > > > > > Is the idea to remove them all in one batch, or have the removal
> > > > process
> > > > > through phases ?
> > > > >
> > > > > Yeah, the idea was to close them all in one batch. We do not want
> to
> > > > close
> > > > > pull requests that have value, and we want to balance this with the
> > > > effort
> > > > > required to review each one to see if it instead should be kept
> open.
> > > > >
> > > > > If we are interested in putting in more effort, then we could
> remove
> > in
> > > > > phases.
> > > > >
> > > > > On Mon, Oct 8, 2018 at 5:30 PM Hugo Louro 
> > wrote:
> > > > >
> > > > > > +1 to remove old PRs. If any PRs still warrant any value we could
> > try
> > > > > > reaching out to the creator to see if he wants to follow up with
> > it.
> > > Is
> > > > > the
> > > > > > idea to remove them all in one batch, or have the removal process
> > > > through
> > > > > > phases ?
> > > > > >
> > > > > > On Mon, Oct 8, 2018 at 3:26 PM Jungtaek Lim 
> > > wrote:
> > > > > >
> > > > > > > +1 It doesn't look like there're any critical PRs in the list,
> > and
> > > it
> > > > > is
> > > > > > > pretty less chance we could connect with PR authors.
> > > > > > >
> > > > > > > -Jungtaek Lim (HeartSaVioR)
> > > > > > >
> > > > > > > 2018년 10월 9일 (화) 오전 5:08, Kishorkumar Patil
> > >  > > > > >님이
> > > > > > > 작성:
> > > > > > >
> > > > > > > > +1.
> > > > > > > > It would be nice to clean up old clutter while we are getting
> > > ready
> > > > > for
> > > > > > > > days past 2.x
> > > > > > > >
> > > > > > > > -Kishor
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, Oct 8, 2018 at 3:52 PM Bobby Evans  >
> > > 

Re: [CANCELED] [VOTE] Release Apache Storm 2.0.0 (rc2)

[Derek Dagit]

On Fri, Oct 12, 2018 at 9:53 AM Kishorkumar Patil 
wrote:

> We need to fix the possible  leaking of slot in
> https://issues.apache.org/jira/browse/STORM-3254.
> The patch is upIhttps://github.com/apache/storm/pull/2876
> -Kishor
>
>
STORM-3253: Deprecates the storm repl subcommand #2875

We may as well do this too if it is no trouble.

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

[Derek Dagit]

I agree with Aaron, we should fix STORM-3251 first.
-1

On Thu, Oct 11, 2018 at 11:22 AM Aaron Gresch  wrote:

> -1 (non-binding?) https://issues.apache.org/jira/browse/STORM-3251
>
> Just found a security-related issue related to a change I recently made
> (original change causing the bug:
>
> https://github.com/apache/storm/commit/06a64949c8c5b764a33a10beb6088cdd8f182aa0
> ).
>
>
> On Wed, Oct 10, 2018 at 6:46 PM Jungtaek Lim  wrote:
>
> > Thanks all for the quick turnaround! Here's my +1 (binding).
> >
> > > source
> >
> > - verify file (signature, MD5, SHA)
> > -- source, tar.gz : OK
> > -- source, zip : OK
> >
> > - extract file
> > -- source, tar.gz : OK
> > -- source, zip : OK
> >
> > - diff-ing extracted files between tar.gz and zip : OK
> >
> > - build source with JDK 8 (-Pall-tests && -Pexternals)
> > -- source, tar.gz : OK
> >
> > - build source dist
> > -- source, tar.gz : OK
> >
> > - build binary dist
> > -- source, tar.gz : OK
> >
> > > binary
> >
> > - verify file (signature, MD5, SHA)
> > -- binary, tar.gz : OK
> > -- binary, zip : OK
> >
> > - extract file
> > -- binary, tar.gz : OK
> > -- binary, zip : OK
> >
> > - diff-ing extracted files between tar.gz and zip : OK
> >
> > - launch daemons : OK
> >
> > - run RollingTopWords (local) : OK
> >
> > - run RollingTopWords (remote) : OK
> >   - activate / deactivate / rebalance / kill : OK
> >   - logviewer (worker dir, daemon dir) :OK
> >   - change log level : OK
> >   - thread dump, heap dump, restart worker : OK
> >   - log search :OK
> >
> > Note that "profiling worker" and "topology log search" works now which
> were
> > failing in RC1.
> >
> > Thanks,
> > Jungtaek Lim (HeartSaVioR)
> >
> > 2018년 10월 11일 (목) 오전 3:02, Stig Rohde Døssing 님이
> > 작성:
> >
> > > +1
> > >
> > > Built and ran unit tests from the tag.
> > > Ran ExclamationTopology locally using the Storm tar, verified that UI
> > looks
> > > as expected, that logviewer works, and that there were no errors in the
> > > logs.
> > > Verified the signature and SHA512 for the source and binary tars.
> > >
> > > We should consider deleting the md5 files, Apache's release policy
> > > recommends against including them in a release
> > > https://www.apache.org/dev/release-distribution#sigs-and-sums.
> > >
> > >
> > > Den ons. 10. okt. 2018 kl. 17.02 skrev Bobby Evans :
> > >
> > > > +1
> > > >
> > > > built and ran all of the unit tests from the tag.
> > > > Ran some small perf tests on a single node cluster.  Things look
> really
> > > > good there.
> > > >
> > > >
> > > > On a side note our CI pipeline has been running and passing builds
> very
> > > > close to this release too.  (we are following master currently) and
> it
> > is
> > > > looking good.
> > > >
> > > > Thanks,
> > > >
> > > > Bobby
> > > >
> > > > On Tue, Oct 9, 2018 at 4:02 PM Kishorkumar Patil
> >  > > >
> > > > wrote:
> > > >
> > > > > +1  to release this package.
> > > > >
> > > > > I ran basic tests, and fucntionality tested manually some of the UI
> > > > > features and profiling issues reported as part of the blockers. I
> did
> > > not
> > > > > notice any silent failures either - or any failures/exception in
> the
> > > > logs.
> > > > >
> > > > > Regards
> > > > > -Kishor
> > > > >
> > > > >
> > > > > On Tue, Oct 9, 2018 at 4:05 PM P. Taylor Goetz  >
> > > > wrote:
> > > > >
> > > > > > This is a call to vote on releasing Apache Storm 2.0.0 (rc2)
> > > > > >
> > > > > > Full list of changes in this release:
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc2/RELEASE_NOTES.html
> > > > > >
> > > > > > The tag/commit to be voted upon is v2.0.0:
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=f8d04910dc3fd14534c186232ecf7882d8916f67;hb=f8d04910dc3fd14534c186232ecf7882d8916f67
> > > > > >
> > > > > > The source archive being voted upon can be found here:
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc2/apache-storm-2.0.0-src.tar.gz
> > > > > >
> > > > > > Other release files, signatures and digests can be found here:
> > > > > >
> > > > > >
> > https://dist.apache.org/repos/dist/dev/storm/apache-storm-2.0.0-rc2/
> > > > > >
> > > > > > The release artifacts are signed with the following key:
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://git-wip-us.apache.org/repos/asf?p=storm.git;a=blob_plain;f=KEYS;hb=22b832708295fa2c15c4f3c70ac0d2bc6fded4bd
> > > > > >
> > > > > > The Nexus staging repository for this release is:
> > > > > >
> > > > > >
> > > https://repository.apache.org/content/repositories/orgapachestorm-1071
> > > > > >
> > > > > > Please vote on releasing this package as Apache Storm 2.0.0.
> > > > > >
> > > > > > When voting, please list the actions taken to verify the release.
> > > > > >
> > > > > > This vote will be open for at 

Re: Cleaning Up Old Pull Requests STORM-3250

[Derek Dagit]

> What is the value in keeping the associated Jira issues around though?

1) I had thought Jira issues could be valid even if they are stale, whereas
pull requests typically are not valid when they go stale.
2) It is less effort. :)

The simplest thing to do would be to run a similar query (not updated in
2018) and close the issues with a common message.

https://issues.apache.org/jira/browse/STORM-579?jql=project%20%3D%20STORM%20AND%20statusCategory%20!%3D%20done%20AND%20updatedDate%20%3C%20startOfYear()%20ORDER%20BY%20updated%20ASC

It seems there are currently 800+ issues that match. That is an awful lot.
I would be open to handling these in bulk too if that is what we want.


On Wed, Oct 10, 2018 at 1:19 PM Hugo Louro  wrote:

> Derek, I am OK with closing them all. By phase I meant perhaps leaving some
> of the most recent one's in case the author wants to resume them... but I
> guess he can always reopen them.
> Stig, the JIRAs I think the should be handled on an individual basis. If
> they are still revenant, leave the JIRA open hoping someone will pick it
> up. If they are no longer relevant, perhaps close as "will not fix" or
> something like that.
>
> Hugo
>
> On Wed, Oct 10, 2018 at 11:12 AM Stig Rohde Døssing <
> stigdoess...@gmail.com>
> wrote:
>
> > +1 to close old PRs.
> >
> > What is the value in keeping the associated Jira issues around though?
> >
> > Den tir. 9. okt. 2018 kl. 17.18 skrev Derek Dagit
>  > >:
> >
> > > > Is the idea to remove them all in one batch, or have the removal
> > process
> > > through phases ?
> > >
> > > Yeah, the idea was to close them all in one batch. We do not want to
> > close
> > > pull requests that have value, and we want to balance this with the
> > effort
> > > required to review each one to see if it instead should be kept open.
> > >
> > > If we are interested in putting in more effort, then we could remove in
> > > phases.
> > >
> > > On Mon, Oct 8, 2018 at 5:30 PM Hugo Louro  wrote:
> > >
> > > > +1 to remove old PRs. If any PRs still warrant any value we could try
> > > > reaching out to the creator to see if he wants to follow up with it.
> Is
> > > the
> > > > idea to remove them all in one batch, or have the removal process
> > through
> > > > phases ?
> > > >
> > > > On Mon, Oct 8, 2018 at 3:26 PM Jungtaek Lim 
> wrote:
> > > >
> > > > > +1 It doesn't look like there're any critical PRs in the list, and
> it
> > > is
> > > > > pretty less chance we could connect with PR authors.
> > > > >
> > > > > -Jungtaek Lim (HeartSaVioR)
> > > > >
> > > > > 2018년 10월 9일 (화) 오전 5:08, Kishorkumar Patil
>  > > >님이
> > > > > 작성:
> > > > >
> > > > > > +1.
> > > > > > It would be nice to clean up old clutter while we are getting
> ready
> > > for
> > > > > > days past 2.x
> > > > > >
> > > > > > -Kishor
> > > > > >
> > > > > >
> > > > > > On Mon, Oct 8, 2018 at 3:52 PM Bobby Evans 
> > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > Sounds good to me
> > > > > > >
> > > > > > > On Mon, Oct 8, 2018 at 2:50 PM Derek Dagit
> >  > > >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Currently there are over 150 open pull requests on the Apache
> > > Storm
> > > > > > > GitHub
> > > > > > > > project. Over 100 of these have not been modified in 2018.
> > > > > > > >
> > > > > > > > It seems we are unlikely to handle each one of these without
> > > > > > significant
> > > > > > > > effort and time. Looking at many of them, they seem to be
> > > abandoned
> > > > > by
> > > > > > > the
> > > > > > > > requester.
> > > > > > > >
> > > > > > > > I propose in STORM-3250 that we close all pull requests that
> > have
> > > > not
> > > > > > > been
> > > > > > > > updated in 2018 and leave any corresponding Jira issues as
> they
> > > > are.
> > > > > If
> > > > > > > > there are any pull requests among these should remain open,
> > > please
> > > > > let
> > > > > > me
> > > > > > > > know. I plan to wait at least a week before requesting any
> > > changes.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/storm/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+updated%3A%3C2018-01-01
> > > > > > > >
> > > > > > > > --
> > > > > > > > Derek
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > --
> > > Derek
> > >
> >
>


-- 
Derek

Re: Cleaning Up Old Pull Requests STORM-3250

[Derek Dagit]

> Is the idea to remove them all in one batch, or have the removal process
through phases ?

Yeah, the idea was to close them all in one batch. We do not want to close
pull requests that have value, and we want to balance this with the effort
required to review each one to see if it instead should be kept open.

If we are interested in putting in more effort, then we could remove in
phases.

On Mon, Oct 8, 2018 at 5:30 PM Hugo Louro  wrote:

> +1 to remove old PRs. If any PRs still warrant any value we could try
> reaching out to the creator to see if he wants to follow up with it. Is the
> idea to remove them all in one batch, or have the removal process through
> phases ?
>
> On Mon, Oct 8, 2018 at 3:26 PM Jungtaek Lim  wrote:
>
> > +1 It doesn't look like there're any critical PRs in the list, and it is
> > pretty less chance we could connect with PR authors.
> >
> > -Jungtaek Lim (HeartSaVioR)
> >
> > 2018년 10월 9일 (화) 오전 5:08, Kishorkumar Patil 님이
> > 작성:
> >
> > > +1.
> > > It would be nice to clean up old clutter while we are getting ready for
> > > days past 2.x
> > >
> > > -Kishor
> > >
> > >
> > > On Mon, Oct 8, 2018 at 3:52 PM Bobby Evans  wrote:
> > >
> > > > +1
> > > >
> > > > Sounds good to me
> > > >
> > > > On Mon, Oct 8, 2018 at 2:50 PM Derek Dagit 
> > > > wrote:
> > > >
> > > > > Currently there are over 150 open pull requests on the Apache Storm
> > > > GitHub
> > > > > project. Over 100 of these have not been modified in 2018.
> > > > >
> > > > > It seems we are unlikely to handle each one of these without
> > > significant
> > > > > effort and time. Looking at many of them, they seem to be abandoned
> > by
> > > > the
> > > > > requester.
> > > > >
> > > > > I propose in STORM-3250 that we close all pull requests that have
> not
> > > > been
> > > > > updated in 2018 and leave any corresponding Jira issues as they
> are.
> > If
> > > > > there are any pull requests among these should remain open, please
> > let
> > > me
> > > > > know. I plan to wait at least a week before requesting any changes.
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/storm/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+updated%3A%3C2018-01-01
> > > > >
> > > > > --
> > > > > Derek
> > > > >
> > > >
> > >
> >
>


-- 
Derek

Cleaning Up Old Pull Requests STORM-3250

[Derek Dagit]

Currently there are over 150 open pull requests on the Apache Storm GitHub
project. Over 100 of these have not been modified in 2018.

It seems we are unlikely to handle each one of these without significant
effort and time. Looking at many of them, they seem to be abandoned by the
requester.

I propose in STORM-3250 that we close all pull requests that have not been
updated in 2018 and leave any corresponding Jira issues as they are. If
there are any pull requests among these should remain open, please let me
know. I plan to wait at least a week before requesting any changes.


https://github.com/apache/storm/pulls?utf8=%E2%9C%93=is%3Apr+is%3Aopen+updated%3A%3C2018-01-01

-- 
Derek

www.storm.incubator.apache.org

[Derek Dagit]

It seems there are still DNS records resolving this name.

The page does not exist, and the server is presenting a TLS certificate
that will not validate anyway.

This site was the third hit for "apache storm" on one of my recent searches.


It would be good to clean this up.

-- 
Derek

[jira] [Updated] (STORM-2065) Add tooltip descriptions for config keys to the UI

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-2065:
---
Summary: Add tooltip descriptions for config keys to the UI  (was: Add 
tooltip descriptions for config keys)

> Add tooltip descriptions for config keys to the UI
> --
>
> Key: STORM-2065
> URL: https://issues.apache.org/jira/browse/STORM-2065
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Affects Versions: 0.10.2
>    Reporter: Derek Dagit
>Priority: Minor
>
> As an admin/a user, I would like to know the purpose of various config 
> settings I see on the UI, so that I can make the correct changes to my 
> cluster/topology.
> This could be accomplished with a simple annotation for each key in our 
> config classes, similar to those we use for validation, but just a simple 
> string.  The annotations could simply duplicate the text we already have in 
> the javadoc comments.
> The UI could send this text to the browser in as a tooltip pop-up when the 
> mouse hovers over one of the config keys.



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

[jira] [Updated] (STORM-2065) Add tooltip descriptions for config keys

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-2065:
---
Component/s: storm-core

> Add tooltip descriptions for config keys
> 
>
> Key: STORM-2065
> URL: https://issues.apache.org/jira/browse/STORM-2065
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Affects Versions: 0.10.2
>    Reporter: Derek Dagit
>Priority: Minor
>
> As an admin/a user, I would like to know the purpose of various config 
> settings I see on the UI, so that I can make the correct changes to my 
> cluster/topology.
> This could be accomplished with a simple annotation for each key in our 
> config classes, similar to those we use for validation, but just a simple 
> string.  The annotations could simply duplicate the text we already have in 
> the javadoc comments.
> The UI could send this text to the browser in as a tooltip pop-up when the 
> mouse hovers over one of the config keys.



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

[jira] [Created] (STORM-2065) Add tooltip descriptions for config keys

[Derek Dagit (JIRA)]

Derek Dagit created STORM-2065:
--

 Summary: Add tooltip descriptions for config keys
 Key: STORM-2065
 URL: https://issues.apache.org/jira/browse/STORM-2065
 Project: Apache Storm
  Issue Type: Improvement
Affects Versions: 0.10.2
Reporter: Derek Dagit
Priority: Minor


As an admin/a user, I would like to know the purpose of various config settings 
I see on the UI, so that I can make the correct changes to my cluster/topology.



This could be accomplished with a simple annotation for each key in our config 
classes, similar to those we use for validation, but just a simple string.  The 
annotations could simply duplicate the text we already have in the javadoc 
comments.

The UI could send this text to the browser in as a tooltip pop-up when the 
mouse hovers over one of the config keys.



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

[jira] [Created] (STORM-2032) "not fast enough" metrics WARN message in netty client can be misinterpreted

[Derek Dagit (JIRA)]

Derek Dagit created STORM-2032:
--

 Summary: "not fast enough" metrics WARN message in netty client 
can be misinterpreted
 Key: STORM-2032
 URL: https://issues.apache.org/jira/browse/STORM-2032
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 2.0.0
Reporter: Derek Dagit
Assignee: Derek Dagit
Priority: Minor


Example:

bq. WARN Messages are not being delivered fast enough, got 3 metrics messages 
at once

It appears to some users to be a good signal for monitoring/alerting, but 
really this is not part of the design.

We should remove it, change it, or lower the log level.



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

[jira] [Commented] (STORM-1948) Add GC visualization to UI

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1948:


STORM-1947 would be a textual presentation, and should be a change of smaller 
scope.  This change would be much more involved and have a larger scope.

> Add GC visualization to UI
> --
>
> Key: STORM-1948
> URL: https://issues.apache.org/jira/browse/STORM-1948
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-ui
>    Reporter: Derek Dagit
>Priority: Minor
>
> As a user, I would like worker JVM GC metrics presented in a visualization, 
> so that I can quickly see and debug issues with heap utilization.
> Perhaps something similar to what 
> [GCViewer|https://github.com/chewiebug/GCViewer/wiki/Features] could be 
> integrated in the UI.



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

[jira] [Created] (STORM-1948) Add GC visualization to UI

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1948:
--

 Summary: Add GC visualization to UI
 Key: STORM-1948
 URL: https://issues.apache.org/jira/browse/STORM-1948
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-ui
Reporter: Derek Dagit
Priority: Minor


As a user, I would like worker JVM GC metrics presented in a visualization, so 
that I can quickly see and debug issues with heap utilization.

Perhaps something similar to what 
[GCViewer|https://github.com/chewiebug/GCViewer/wiki/Features] could be 
integrated in the UI.



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

[jira] [Created] (STORM-1947) Show worker GC time on the UI

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1947:
--

 Summary: Show worker GC time on the UI
 Key: STORM-1947
 URL: https://issues.apache.org/jira/browse/STORM-1947
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-ui
Reporter: Derek Dagit
Priority: Minor


It would be helpful if GC time was exposed on the UI, especially in a worker 
specific view.



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

[jira] [Created] (STORM-1860) Simple UI Announcements Notification

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1860:
--

 Summary: Simple UI Announcements Notification
 Key: STORM-1860
 URL: https://issues.apache.org/jira/browse/STORM-1860
 Project: Apache Storm
  Issue Type: Story
  Components: storm-core
Affects Versions: 0.9.3
Reporter: Derek Dagit


As a user of a storm cluster, I would like to be informed of current or 
scheduled maintenance on the cluster, so that I can plan my work & debug more 
efficiently.


This could be a really simple UI change.  The UI could look for a special file 
on the local disk. If found, it would display a notification near the top of 
the UI with the contents of this file.

It would be useful to announce an ongoing rolling upgrade of the cluster, 
scheduled future downtime, current known incidents, or other, even more general 
communications from administrators to users.



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

[jira] [Created] (STORM-1768) Reduce noise in worker logs

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1768:
--

 Summary: Reduce noise in worker logs
 Key: STORM-1768
 URL: https://issues.apache.org/jira/browse/STORM-1768
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-core
Affects Versions: 0.10.0
Reporter: Derek Dagit


Much of the time when debugging a problematic topology, worker logs are filled 
with many statements like netty connection issues, so that more relevant 
information is harder to find.

Perhaps we can identify some of the noisiest logs and change their log level to 
DEBUG or TRACE.



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

[jira] [Created] (STORM-1748) Better Trident Spout Names

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1748:
--

 Summary: Better Trident Spout Names
 Key: STORM-1748
 URL: https://issues.apache.org/jira/browse/STORM-1748
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-core
Affects Versions: 0.10.0
Reporter: Derek Dagit


As a user, I would like to see more meaningful component names for spouts in 
trident topologies, so that I can make more sense of the topology functionality.

For example, automatically generated names like "$mastercoord-bg2,3,4,5" are 
not so useful for understanding.



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

[jira] [Commented] (STORM-1683) UI Topology Visualization should not check sys streams by default

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1683:


Pull Requests:
1.x-branch: https://github.com/apache/storm/pull/1308
master: https://github.com/apache/storm/pull/1313

> UI Topology Visualization should not check sys streams by default
> -
>
> Key: STORM-1683
> URL: https://issues.apache.org/jira/browse/STORM-1683
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-ui
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>
> New system streams (beginning with two underscores {{__}}) have been added 
> since the visualization code was added, such as  __ack_reset_timeout  and  
> __eventlog. The visualization code currently presents stream check boxes as 
> unchecked if they are ack-related streams and checked otherwise.
> It seems that it should present only non-system streams as checked, so that 
> the graph shows more relevant streams by default.



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

[jira] [Updated] (STORM-1683) UI Topology Visualization should not check sys streams by default

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1683:
---
Affects Version/s: 2.0.0

> UI Topology Visualization should not check sys streams by default
> -
>
> Key: STORM-1683
> URL: https://issues.apache.org/jira/browse/STORM-1683
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-ui
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>
> New system streams (beginning with two underscores {{__}}) have been added 
> since the visualization code was added, such as  __ack_reset_timeout  and  
> __eventlog. The visualization code currently presents stream check boxes as 
> unchecked if they are ack-related streams and checked otherwise.
> It seems that it should present only non-system streams as checked, so that 
> the graph shows more relevant streams by default.



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

[jira] [Created] (STORM-1683) UI Topology Visualization should not check sys streams by default

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1683:
--

 Summary: UI Topology Visualization should not check sys streams by 
default
 Key: STORM-1683
 URL: https://issues.apache.org/jira/browse/STORM-1683
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-ui
Affects Versions: 1.0.0
Reporter: Derek Dagit
Assignee: Derek Dagit


New system streams (beginning with two underscores {{__}}) have been added 
since the visualization code was added, such as  __ack_reset_timeout  and  
__eventlog. The visualization code currently presents stream check boxes as 
unchecked if they are ack-related streams and checked otherwise.

It seems that it should present only non-system streams as checked, so that the 
graph shows more relevant streams by default.



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

[jira] [Commented] (STORM-1469) Unable to deploy large topologies on apache storm

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1469:


OK, looking at this some more: It is not the size of the jar file that matters 
here, it is the size of the topology config and the topology instance when 
serialized. If those are too big, then as [~kishorvpatil] noted, there is a 
16MB max limit in thrift that we are not correctly overriding with the config 
mentioned above. Nimbus should launch with a thrift server that has the max 
buffer size configured correctly, instead of always using the default of 16MB.

> Unable to deploy large topologies on apache storm
> -
>
> Key: STORM-1469
> URL: https://issues.apache.org/jira/browse/STORM-1469
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Rudra Sharma
> Fix For: 1.0.0, 2.0.0
>
>
> When deploying to a nimbus a topology which is larger in size >17MB, we get 
> an exception. In storm 0.9.3 this could be mitigated by using the following 
> config on the storm.yaml to increse the buffer size to handle the topology 
> size. i.e. 50MB would be
> nimbus.thrift.max_buffer_size: 5000
> This configuration does not resolve the issue in the master branch of storm 
> and we cannot deploy topologies which are large in size.
> Here is the log on the client side when attempting to deploy to the nimbus 
> node:
> java.lang.RuntimeException: org.apache.thrift7.transport.TTransportException
>   at 
> backtype.storm.StormSubmitter.submitTopologyAs(StormSubmitter.java:251) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.StormSubmitter.submitTopology(StormSubmitter.java:272) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.StormSubmitter.submitTopology(StormSubmitter.java:155) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> com.trustwave.siem.storm.topology.deployer.TopologyDeployer.deploy(TopologyDeployer.java:149)
>  [siem-ng-storm-deployer-cloud.jar:]
>   at 
> com.trustwave.siem.storm.topology.deployer.TopologyDeployer.main(TopologyDeployer.java:87)
>  [siem-ng-storm-deployer-cloud.jar:]
> Caused by: org.apache.thrift7.transport.TTransportException
>   at 
> org.apache.thrift7.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
>  ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at org.apache.thrift7.transport.TTransport.readAll(TTransport.java:86) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
>  ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.transport.TFramedTransport.read(TFramedTransport.java:101) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at org.apache.thrift7.transport.TTransport.readAll(TTransport.java:86) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:429) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:318) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:219)
>  ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.TServiceClient.receiveBase(TServiceClient.java:77) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.generated.Nimbus$Client.recv_submitTopology(Nimbus.java:238) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.generated.Nimbus$Client.submitTopology(Nimbus.java:222) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.StormSubmitter.submitTopologyAs(StormSubmitter.java:237) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   ... 4 more
> Here is the log on the server side (nimbus.log):
> 2016-01-13 10:48:07.206 o.a.s.d.nimbus [INFO] Cleaning inbox ... deleted: 
> stormjar-c8666220-fa19-426b-a7e4-c62dfb57f1f0.jar
> 2016-01-13 10:55:09.823 o.a.s.d.nimbus [INFO] Uploading file from client to 
> /var/storm-data/nimbus/inbox/stormjar-80ecdf05-6a25-4281-8c78-10062ac5e396.jar
> 2016-01-13 10:55:11.910 o.a.s.d.nimbus [INFO] Finished uploading file from 
> client: 
> /var/storm-data/nimbus/inbox/stormjar-80ecdf05-6a25-4281-8c78-10062ac5e396.jar
>

[jira] [Commented] (STORM-1469) Unable to deploy large topologies on apache storm

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1469:


[~rudra.sharma], if this was seen on master, was the topology submitted using 
an old client?  I had thought in the latest version of storm the StormSubmitter 
submits topology jars in chunks of about 30kb at a time.

> Unable to deploy large topologies on apache storm
> -
>
> Key: STORM-1469
> URL: https://issues.apache.org/jira/browse/STORM-1469
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0, 2.0.0
>Reporter: Rudra Sharma
> Fix For: 1.0.0, 2.0.0
>
>
> When deploying to a nimbus a topology which is larger in size >17MB, we get 
> an exception. In storm 0.9.3 this could be mitigated by using the following 
> config on the storm.yaml to increse the buffer size to handle the topology 
> size. i.e. 50MB would be
> nimbus.thrift.max_buffer_size: 5000
> This configuration does not resolve the issue in the master branch of storm 
> and we cannot deploy topologies which are large in size.
> Here is the log on the client side when attempting to deploy to the nimbus 
> node:
> java.lang.RuntimeException: org.apache.thrift7.transport.TTransportException
>   at 
> backtype.storm.StormSubmitter.submitTopologyAs(StormSubmitter.java:251) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.StormSubmitter.submitTopology(StormSubmitter.java:272) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.StormSubmitter.submitTopology(StormSubmitter.java:155) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> com.trustwave.siem.storm.topology.deployer.TopologyDeployer.deploy(TopologyDeployer.java:149)
>  [siem-ng-storm-deployer-cloud.jar:]
>   at 
> com.trustwave.siem.storm.topology.deployer.TopologyDeployer.main(TopologyDeployer.java:87)
>  [siem-ng-storm-deployer-cloud.jar:]
> Caused by: org.apache.thrift7.transport.TTransportException
>   at 
> org.apache.thrift7.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
>  ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at org.apache.thrift7.transport.TTransport.readAll(TTransport.java:86) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.transport.TFramedTransport.readFrame(TFramedTransport.java:129)
>  ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.transport.TFramedTransport.read(TFramedTransport.java:101) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at org.apache.thrift7.transport.TTransport.readAll(TTransport.java:86) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:429) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:318) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:219)
>  ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> org.apache.thrift7.TServiceClient.receiveBase(TServiceClient.java:77) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.generated.Nimbus$Client.recv_submitTopology(Nimbus.java:238) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.generated.Nimbus$Client.submitTopology(Nimbus.java:222) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   at 
> backtype.storm.StormSubmitter.submitTopologyAs(StormSubmitter.java:237) 
> ~[storm-core-0.11.0-SNAPSHOT.jar:0.11.0-SNAPSHOT]
>   ... 4 more
> Here is the log on the server side (nimbus.log):
> 2016-01-13 10:48:07.206 o.a.s.d.nimbus [INFO] Cleaning inbox ... deleted: 
> stormjar-c8666220-fa19-426b-a7e4-c62dfb57f1f0.jar
> 2016-01-13 10:55:09.823 o.a.s.d.nimbus [INFO] Uploading file from client to 
> /var/storm-data/nimbus/inbox/stormjar-80ecdf05-6a25-4281-8c78-10062ac5e396.jar
> 2016-01-13 10:55:11.910 o.a.s.d.nimbus [INFO] Finished uploading file from 
> client: 
> /var/storm-data/nimbus/inbox/stormjar-80ecdf05-6a25-4281-8c78-10062ac5e396.jar
> 2016-01-13 10:55:12.084 o.a.t.s.AbstractNonblockingServer$FrameBuffer [WARN] 
> Exception while invoking!
> org.apache.thrift7.transport.TTransportException: Frame size (17435758) 
> larger than max length (16384000)!
> 

[jira] [Assigned] (STORM-1488) UI Topology Page component last error timestamp is from 1970

[Derek Dagit (JIRA)]

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

Derek Dagit reassigned STORM-1488:
--

Assignee: Derek Dagit

> UI Topology Page component last error timestamp is from 1970
> 
>
> Key: STORM-1488
> URL: https://issues.apache.org/jira/browse/STORM-1488
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Critical
> Attachments: screen-shot-error-time.png
>
>
> Seems to be something wrong with the parsing of the timestamp into a date 
> string.
> !screen-shot-error-time.png|thumbnail!



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

[jira] [Created] (STORM-1555) Required field 'topology_id' is unset! seen failing integration-test in Travis CI Test

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1555:
--

 Summary: Required field 'topology_id' is unset! seen failing 
integration-test in Travis CI Test
 Key: STORM-1555
 URL: https://issues.apache.org/jira/browse/STORM-1555
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 2.0.0
Reporter: Derek Dagit


A recent travis ci 
[error|https://travis-ci.org/apache/storm/jobs/109239992#L1570] was seen.  

Here is the stack trace:

{noformat}
107323 [main] ERROR i.o.a.s.t.integration-test - Error in cluster

java.lang.RuntimeException: org.apache.thrift.protocol.TProtocolException: 
Required field 'topology_id' is unset! Struct:LSTopoHistory(topology_id:null, 
time_stamp:1455491275, users:[], groups:[])

at org.apache.storm.utils.LocalState.serialize(LocalState.java:186) 
~[classes/:?]

at org.apache.storm.utils.LocalState.put(LocalState.java:142) 
~[classes/:?]

at org.apache.storm.utils.LocalState.put(LocalState.java:136) 
~[classes/:?]

at 
org.apache.storm.local_state$ls_topo_hist_BANG_.invoke(local_state.clj:48) 
~[classes/:?]

at 
org.apache.storm.daemon.nimbus$add_topology_to_history_log.invoke(nimbus.clj:1279)
 ~[classes/:?]

at 
org.apache.storm.daemon.nimbus$fn__4836$exec_fn__1827__auto__$reify__4865.killTopologyWithOpts(nimbus.clj:1587)
 ~[classes/:?]

at sun.reflect.GeneratedMethodAccessor298.invoke(Unknown Source) ~[?:?]

at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[?:1.7.0_76]

at java.lang.reflect.Method.invoke(Method.java:606) ~[?:1.7.0_76]

at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93) 
~[clojure-1.7.0.jar:?]

at clojure.lang.Reflector.invokeInstanceMethod(Reflector.java:28) 
~[clojure-1.7.0.jar:?]

at 
org.apache.storm.trident.testing$with_topology_STAR_.invoke(testing.clj:62) 
~[classes/:?]

at 
integration.org.apache.storm.trident.integration_test$fn__5251.invoke(integration_test.clj:149)
 [?:?]

at clojure.test$test_var$fn__7670.invoke(test.clj:704) 
[clojure-1.7.0.jar:?]

at clojure.test$test_var.invoke(test.clj:704) [clojure-1.7.0.jar:?]

at clojure.test$test_vars$fn__7692$fn__7697.invoke(test.clj:722) 
[clojure-1.7.0.jar:?]

at clojure.test$default_fixture.invoke(test.clj:674) 
[clojure-1.7.0.jar:?]

at clojure.test$test_vars$fn__7692.invoke(test.clj:722) 
[clojure-1.7.0.jar:?]

at clojure.test$default_fixture.invoke(test.clj:674) 
[clojure-1.7.0.jar:?]

at clojure.test$test_vars.invoke(test.clj:718) [clojure-1.7.0.jar:?]

at clojure.test$test_all_vars.invoke(test.clj:728) [clojure-1.7.0.jar:?]

at clojure.test$test_ns.invoke(test.clj:747) [clojure-1.7.0.jar:?]

at clojure.core$map$fn__4553.invoke(core.clj:2624) [clojure-1.7.0.jar:?]

at clojure.lang.LazySeq.sval(LazySeq.java:40) [clojure-1.7.0.jar:?]

at clojure.lang.LazySeq.seq(LazySeq.java:49) [clojure-1.7.0.jar:?]

at clojure.lang.Cons.next(Cons.java:39) [clojure-1.7.0.jar:?]

at clojure.lang.RT.boundedLength(RT.java:1735) [clojure-1.7.0.jar:?]

at clojure.lang.RestFn.applyTo(RestFn.java:130) [clojure-1.7.0.jar:?]

at clojure.core$apply.invoke(core.clj:632) [clojure-1.7.0.jar:?]

at clojure.test$run_tests.doInvoke(test.clj:762) [clojure-1.7.0.jar:?]

at clojure.lang.RestFn.invoke(RestFn.java:408) [clojure-1.7.0.jar:?]

at 
org.apache.storm.testrunner$eval10993$iter__10994__10998$fn__10999$fn__11000$fn__11001.invoke(test_runner.clj:107)
 [?:?]

at 
org.apache.storm.testrunner$eval10993$iter__10994__10998$fn__10999$fn__11000.invoke(test_runner.clj:53)
 [?:?]

at 
org.apache.storm.testrunner$eval10993$iter__10994__10998$fn__10999.invoke(test_runner.clj:52)
 [?:?]

at clojure.lang.LazySeq.sval(LazySeq.java:40) [clojure-1.7.0.jar:?]

at clojure.lang.LazySeq.seq(LazySeq.java:49) [clojure-1.7.0.jar:?]

at clojure.lang.RT.seq(RT.java:507) [clojure-1.7.0.jar:?]

at clojure.core$seq__4128.invoke(core.clj:137) [clojure-1.7.0.jar:?]

at clojure.core$dorun.invoke(core.clj:3009) [clojure-1.7.0.jar:?]

at org.apache.storm.testrunner$eval10993.invoke(test_runner.clj:52) 
[?:?]

at clojure.lang.Compiler.eval(Compiler.java:6782) [clojure-1.7.0.jar:?]

at clojure.lang.Compiler.load(Compiler.java:7227) [clojure-1.7.0.jar:?]

at clojure.lang.Compiler.loadFile(Compiler.java:7165) 
[clojure-1.7.0.jar:?]

at clojure.main$load_script.invoke(main.clj:275) [clojure-1.7.0.jar:?]

at clojure.main$script_opt.invoke(main.clj:337) [clojure-1.7.0.jar:?]

at clojure.main$main.doInvoke(main.clj:421) [clojure-1.7.0.jar:?]

at clojure.lang.RestFn.invoke(RestFn.java:421) [clojure-1.7.0.jar

[jira] [Created] (STORM-1488) UI Topology Page component last error timestamp is from 1970

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1488:
--

 Summary: UI Topology Page component last error timestamp is from 
1970
 Key: STORM-1488
 URL: https://issues.apache.org/jira/browse/STORM-1488
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 1.0.0, 2.0.0
Reporter: Derek Dagit
Priority: Critical
 Attachments: screen-shot-error-time.png

Seems to be something wrong with the parsing of the timestamp into a date 
string.

!screen-shot-error-time.png|thumbnail!



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

[jira] [Updated] (STORM-1488) UI Topology Page component last error timestamp is from 1970

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1488:
---
Attachment: screen-shot-error-time.png

> UI Topology Page component last error timestamp is from 1970
> 
>
> Key: STORM-1488
> URL: https://issues.apache.org/jira/browse/STORM-1488
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Derek Dagit
>Priority: Critical
> Attachments: screen-shot-error-time.png
>
>
> Seems to be something wrong with the parsing of the timestamp into a date 
> string.
> !screen-shot-error-time.png|thumbnail!



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

[jira] [Updated] (STORM-1487) UI Topology Page tooltips misplaced

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1487:
---
Description: 
!screen-shot-tooltips.png|thumbnail!

Seems the placement is off.

(Note, the error timestamp in the year 1970 will be handled in a separate 
issue.)

  was:
!screen-shot-tooltips.png!

Seems the placement is off.

(Note, the error timestamp in the year 1970 will be handled in a separate 
issue.)


> UI Topology Page tooltips misplaced
> ---
>
> Key: STORM-1487
> URL: https://issues.apache.org/jira/browse/STORM-1487
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Derek Dagit
> Attachments: screen-shot-tooltips.png
>
>
> !screen-shot-tooltips.png|thumbnail!
> Seems the placement is off.
> (Note, the error timestamp in the year 1970 will be handled in a separate 
> issue.)



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

[jira] [Created] (STORM-1487) UI Topology Page tooltips misplaced

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1487:
--

 Summary: UI Topology Page tooltips misplaced
 Key: STORM-1487
 URL: https://issues.apache.org/jira/browse/STORM-1487
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 1.0.0, 2.0.0
Reporter: Derek Dagit


!screen-shot-tooltips.png!

Seems the placement is off.

(Note, the error timestamp in the year 1970 will be handled in a separate 
issue.)



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

[jira] [Updated] (STORM-1487) UI Topology Page tooltips misplaced

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1487:
---
Attachment: screen-shot-tooltips.png

> UI Topology Page tooltips misplaced
> ---
>
> Key: STORM-1487
> URL: https://issues.apache.org/jira/browse/STORM-1487
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0, 2.0.0
>    Reporter: Derek Dagit
> Attachments: screen-shot-tooltips.png
>
>
> !screen-shot-tooltips.png!
> Seems the placement is off.
> (Note, the error timestamp in the year 1970 will be handled in a separate 
> issue.)



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

[jira] [Created] (STORM-1489) Script for cleaner environment checking

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1489:
--

 Summary: Script for cleaner environment checking
 Key: STORM-1489
 URL: https://issues.apache.org/jira/browse/STORM-1489
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-core
Affects Versions: 2.0.0
Reporter: Derek Dagit


As a storm developer, I would like a common script that storm can execute to 
detect features of the environment (like OS), so that storm has cleaner code 
for enabling features at run-time.

See [original 
comment|https://github.com/apache/storm/pull/1012#discussion_r50280610]



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

[jira] [Created] (STORM-1470) org.apache.hadoop:hadoop-auth not shaded, breaks spnego authentication

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1470:
--

 Summary: org.apache.hadoop:hadoop-auth not shaded, breaks spnego 
authentication
 Key: STORM-1470
 URL: https://issues.apache.org/jira/browse/STORM-1470
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 2.0.0, 1.0.0
Reporter: Derek Dagit
Assignee: Derek Dagit
Priority: Blocker


{noformat}
2016-01-12 20:07:45.642 o.a.s.s.o.e.j.s.ServletHandler [WARN] Error for 
/favicon.ico
java.lang.NoClassDefFoundError: org/apache/commons/codec/binary/Base64
at 
org.apache.hadoop.security.authentication.server.KerberosAuthenticationHandler.authenticate(KerberosAuthenticationHandler.java:343)
at 
org.apache.hadoop.security.authentication.server.AuthenticationFilter.doFilter(AuthenticationFilter.java:519)
at 
org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at 
org.apache.storm.shade.org.eclipse.jetty.servlets.CrossOriginFilter.handle(CrossOriginFilter.java:247)
at 
org.apache.storm.shade.org.eclipse.jetty.servlets.CrossOriginFilter.doFilter(CrossOriginFilter.java:210)
at 
org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1291)
at 
org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:443)
at 
org.apache.storm.shade.org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1044)
at 
org.apache.storm.shade.org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:372)
at 
org.apache.storm.shade.org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:978)
at 
org.apache.storm.shade.org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at 
org.apache.storm.shade.org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at 
org.apache.storm.shade.org.eclipse.jetty.server.Server.handle(Server.java:369)
at 
org.apache.storm.shade.org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:486)
at 
org.apache.storm.shade.org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:933)
at 
org.apache.storm.shade.org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:995)
at 
org.apache.storm.shade.org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:644)
at 
org.apache.storm.shade.org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at 
org.apache.storm.shade.org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:82)
at 
org.apache.storm.shade.org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:668)
at 
org.apache.storm.shade.org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:52)
at 
org.apache.storm.shade.org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at 
org.apache.storm.shade.org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:745)
{noformat}

We already shade commons-codec:commons-codec, but we don't apply that shading 
to org.apache.hadoop:hadoop-auth.




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

Re: Java 8 for Storm 2.x?

[Derek Dagit]

I am not sure it makes sense to move to Java 8 merely because of the 
clojure->java translation, but it might be good timing so I would be OK with it.

 -- 
Derek


- Original Message -
From: Reza Farivar 
To: Dev 
Sent: Monday, January 11, 2016 4:40 PM
Subject: Java 8 for Storm 2.x?

I have started work on translating the util.clj to java (STORM-1226). I see 
some instances when translating the functional behavior of clojure to Java 
requires code that is already part of java 8.
For instance, there are many cases where a predicate function is passed around 
(e.g. in find-first). I can go ahead and implement a Predicate interface and 
use that, but Java 8 has already exactly that functionality implemented. 
Would it make sense to move to Java 8 for the post-clojure branch 2.x?
--Reza 

[jira] [Assigned] (STORM-1452) Worker "profiler" actions broken by default

[Derek Dagit (JIRA)]

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

Derek Dagit reassigned STORM-1452:
--

Assignee: Derek Dagit

> Worker "profiler" actions broken by default
> ---
>
> Key: STORM-1452
> URL: https://issues.apache.org/jira/browse/STORM-1452
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.11.0
>Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Blocker
>
> * The profiler script flight.bash is not packaged by default.
> * The default options enable the Oracle specific flight-recorder that 
> requires a support subscription.
> The option to enable the profiler should not be enabled by default.  Other 
> actions such as worker restart, debugging, and heap can remain enabled.



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

[jira] [Commented] (STORM-1452) Worker "profiler" actions broken by default

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1452:


We also need a fix for [~revans2]'s 
[comment|https://github.com/apache/storm/pull/995#discussion-diff-49221805]

> Worker "profiler" actions broken by default
> ---
>
> Key: STORM-1452
> URL: https://issues.apache.org/jira/browse/STORM-1452
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.11.0
>Reporter: Derek Dagit
>Priority: Blocker
>
> * The profiler script flight.bash is not packaged by default.
> * The default options enable the Oracle specific flight-recorder that 
> requires a support subscription.
> The option to enable the profiler should not be enabled by default.  Other 
> actions such as worker restart, debugging, and heap can remain enabled.



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

[jira] [Assigned] (STORM-1430) UI Worker Functions: Replace pick-list with buttons

[Derek Dagit (JIRA)]

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

Derek Dagit reassigned STORM-1430:
--

Assignee: Derek Dagit

> UI Worker Functions: Replace pick-list with buttons
> ---
>
> Key: STORM-1430
> URL: https://issues.apache.org/jira/browse/STORM-1430
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Affects Versions: 0.11.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
>
> The Component Page in the UI has a very useful set of functions that allow us 
> to profile a worker, to restart a worker, to create a stack trace, or to save 
> the heap.
> When there are many workers, finding the correct worker host:port from the 
> pick list is tedious.
> As a user, I would like the worker functions presented as buttons directly in 
> the Executors summary tables, so that I can easily request the functions when 
> there are lots of workers.



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

[jira] [Created] (STORM-1452) Worker "profiler" actions broken by default

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1452:
--

 Summary: Worker "profiler" actions broken by default
 Key: STORM-1452
 URL: https://issues.apache.org/jira/browse/STORM-1452
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 0.11.0
Reporter: Derek Dagit
Priority: Blocker


* The profiler script flight.bash is not packaged by default.
* The default options enable the Oracle specific flight-recorder that requires 
a support subscription.

The option to enable the profiler should not be enabled by default.  Other 
actions such as worker restart, debugging, and heap can remain enabled.



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

[jira] [Commented] (STORM-1452) Worker "profiler" actions broken by default

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1452:


Created as a Blocker since the presentation is very visible on the UI page.

It should not be too hard to fix.

> Worker "profiler" actions broken by default
> ---
>
> Key: STORM-1452
> URL: https://issues.apache.org/jira/browse/STORM-1452
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.11.0
>Reporter: Derek Dagit
>Priority: Blocker
>
> * The profiler script flight.bash is not packaged by default.
> * The default options enable the Oracle specific flight-recorder that 
> requires a support subscription.
> The option to enable the profiler should not be enabled by default.  Other 
> actions such as worker restart, debugging, and heap can remain enabled.



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

[jira] [Commented] (STORM-1452) Worker "profiler" actions broken by default

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1452:


Here is a [partial patch|https://gist.github.com/d2r/ab15f312a5af1d9525af] that 
makes everything work, but we still need to disable the jfr feature by default.

> Worker "profiler" actions broken by default
> ---
>
> Key: STORM-1452
> URL: https://issues.apache.org/jira/browse/STORM-1452
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.11.0
>Reporter: Derek Dagit
>Priority: Blocker
>
> * The profiler script flight.bash is not packaged by default.
> * The default options enable the Oracle specific flight-recorder that 
> requires a support subscription.
> The option to enable the profiler should not be enabled by default.  Other 
> actions such as worker restart, debugging, and heap can remain enabled.



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

[jira] [Updated] (STORM-1422) broken example in storm-starter tutorial

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1422:
---
Assignee: Seth Ammons

> broken example in storm-starter tutorial
> 
>
> Key: STORM-1422
> URL: https://issues.apache.org/jira/browse/STORM-1422
> Project: Apache Storm
>  Issue Type: Bug
> Environment: OSX El Capitan 10.11.2, Java 1.8.0, Storm 0.9.5., Maven 
> 3.3.3
>Reporter: Seth Ammons
>Assignee: Seth Ammons
>Priority: Minor
>  Labels: documentation
>
> The tutorial code is broken giving an error. See:
> http://stackoverflow.com/questions/34467446/apache-storm-classnotfoundexception-on-storm-starter.
>  
> Pull request removing offending instructions:
> https://github.com/apache/storm/pull/979
> Alternative would be to fix them (shrug). 



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

[jira] [Resolved] (STORM-1422) broken example in storm-starter tutorial

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1422.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks, [~sethammons], I merged this to master.

> broken example in storm-starter tutorial
> 
>
> Key: STORM-1422
> URL: https://issues.apache.org/jira/browse/STORM-1422
> Project: Apache Storm
>  Issue Type: Bug
> Environment: OSX El Capitan 10.11.2, Java 1.8.0, Storm 0.9.5., Maven 
> 3.3.3
>Reporter: Seth Ammons
>Assignee: Seth Ammons
>Priority: Minor
>  Labels: documentation
> Fix For: 0.11.0
>
>
> The tutorial code is broken giving an error. See:
> http://stackoverflow.com/questions/34467446/apache-storm-classnotfoundexception-on-storm-starter.
>  
> Pull request removing offending instructions:
> https://github.com/apache/storm/pull/979
> Alternative would be to fix them (shrug). 



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

Re: Failed to bind to: 0.0.0.0/0.0.0.0:6703

[Derek Dagit]

> org.jboss.netty.channel.ChannelException: Failed to bind to: 
> 0.0.0.0/0.0.0.0:6703


If you see this, you can use a tool like lsof to find out what was listening on 
the port.

`lsof -i :6703` as root user.


Most likely, because it was port 6703, it was another worker JVM that was still 
running.


 
-- 
Derek





From: researcher cs 
To: dev@storm.apache.org; u...@storm.apache.org; nat...@nathanmarz.com; Michael 
Vogiatzis ; Michael Vogiatzis  
Sent: Sunday, January 3, 2016 6:09 PM
Subject: Failed to bind to: 0.0.0.0/0.0.0.0:6703



I'm using storm -0.9.0.1 with zookeeper -3.4.6 ubuntu 14.04 
now i ran my topology in local mode with maven commands and worked well 
BUT when i submitted it i got 

org.jboss.netty.channel.ChannelException: Failed to bind to: 
0.0.0.0/0.0.0.0:6703
at org.jboss.netty.bootstrap.ServerBootstrap.bind(ServerBootstrap.java:272) 
~[netty-3.6.3.Final.jar:na]
at backtype.storm.messaging.netty.Server.(Server.java:56) 
~[storm-netty-0.9.0.1.jar:na]
at backtype.storm.messaging.netty.Context.bind(Context.java:27) 
~[storm-netty-0.9.0.1.jar:na]
at 
backtype.storm.messaging.loader$launch_receive_thread_BANG_$fn__2984.invoke(loader.clj:20)
 ~[storm-core-0.9.0.1.jar:na]
at backtype.storm.util$async_loop$fn__444.invoke(util.clj:401) 
~[storm-core-0.9.0.1.jar:na]
at clojure.lang.AFn.run(AFn.java:24) ~[clojure-1.4.0.jar:na]
at java.lang.Thread.run(Thread.java:701) ~[na:1.6.0_37]
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method) ~[na:1.6.0_37]
at sun.nio.ch.Net.bind(Net.java:174) ~[na:1.6.0_37]
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:139) 
~[na:1.6.0_37]
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:77) 
~[na:1.6.0_37]
at 
org.jboss.netty.channel.socket.nio.NioServerBoss$RegisterTask.run(NioServerBoss.java:193)
 ~[netty-3.6.3.Final.jar:na]
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.processTaskQueue(AbstractNioSelector.java:366)
 ~[netty-3.6.3.Final.jar:na]
at 
org.jboss.netty.channel.socket.nio.AbstractNioSelector.run(AbstractNioSelector.java:290)
 ~[netty-3.6.3.Final.jar:na]
at 
org.jboss.netty.channel.socket.nio.NioServerBoss.run(NioServerBoss.java:42) 
~[netty-3.6.3.Final.jar:na]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) 
~[na:1.6.0_37]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) 
~[na:1.6.0_37]
... 1 common frames omitted
2016-01-04 01:52:07 b.s.util [INFO] Halting process: 



the topology using one worker for one supervisor i'm trying to run or submit it 
first in single machine 


so my only storm.yaml is 

storm.zookeeper.servers:

 - "192.168.x.x"

 nimbus.host: "192.168.x.x"
 storm.local.dir: "/var/storm"
 supervisor.childopts: "-Djava.net.preferIPv4Stack=true" 
 nimbus.childopts: "-Djava.net.preferIPv4Stack=true" 
 worker.childopts: "-Djava.net.preferIPv4Stack=true" 
 drpc.servers:

 - "192.168.x.x"

storm.messaging.transport: "backtype.storm.messaging.netty.Context"
 storm.messaging.netty.server_worker_threads: 1
 storm.messaging.netty.client_worker_threads: 1
 storm.messaging.netty.buffer_size: 5242880
 storm.messaging.netty.max_retries: 100
 storm.messaging.netty.max_wait_ms: 1000
 storm.messaging.netty.min_wait_ms: 100


zoo.cfg is 

tickTime=2000
initLimit=10
syncLimit=5
dataDir=/var/zookeeper
clientPort=2181


i tried to use localhost but got same error then tried to use my ip address
i searched to fix it more but got this solution 
can someone illustrate it beacuse i didn't get it well 

[[

It turned out that my logback/cluster.xml configuration had a SocketAppender 
that didn't have a listener on the remote host. Having an appender defined in 
configuration file, even if it is not set up to receive any log messages, will 
cause Storm to block and the above error message.its due to zookeeper you have 
add curator separetly not required its the part of zookeeper
]]


or can someone help me to fix it ? 


importaant thing 


topology using drpc and i tried to submit another topoogies worked well but 
topology with drpc got this error 


the project i'm trying to submit it here 
https://github.com/mvogiatzis/first-stories-twitter

Re: until now i can't solve my problem and no one could fix it . WHY ?!

[Derek Dagit]

> org.zeromq.ZMQException: Address already in use(0x62)


I see this happen when there is already a worker running in the same slot.

For example, there is a JVM process that is listening on 6703, but the 
supervisor tries to launch another worker to listen on port 6703.
 -- 
Derek





From: sam mohel 
To: u...@storm.apache.org; dev@storm.apache.org 
Sent: Saturday, January 2, 2016 6:06 PM
Subject: until now i can't solve my problem and no one could fix it . WHY ?!



i hav topology using drpc i seached really more about fixing it but what i find 
posts without answers ! or one post only with answer that couldn't fix my 
problem 

org.zeromq.ZMQException: Address already in use(0x62)
 at org.zeromq.ZMQ$Socket.bind(Native Method)
 at zilch.mq$bind.invoke(mq.clj:69)
 at backtype.storm.messaging.zmq.ZMQContext.bind(zmq.clj:57) 


i found that i need to downgrade version of zeromq from 2.1.7 to 2.1.4 and it 
didn't help me 

please , Can i find another solution ? 

Re: show system stats in storm ui

[Derek Dagit]

The button sets a cookie 'sys' and reloads the page.  When the 'sys' cookie is 
set, system components like __acker will show up, and such component's stats 
are included in the numbers on the page.

Hiding the system stats unsets the 'sys' cookie, and system component 
information is not shown on the UI.

 
-- 
Derek





From: researcher cs 
To: u...@storm.apache.org; dev@storm.apache.org 
Sent: Sunday, January 3, 2016 5:33 PM
Subject: show system stats in storm ui



what is the purpose of this button ? 
i clicked it found column of emitted after become zeros , it have numbers and 
everythind is ok as i thought but transfered still zeros 

but after hide system status emitted return to zeros again 

thanks 

Re: [DISCUSS] 1.0 release

[Derek Dagit]

I really would like STORM-1430 since after 1.0 there is a feature freeze.
But it should not be a blocker.
 -- 
Derek


- Original Message -
From: P. Taylor Goetz 
To: dev@storm.apache.org; Bobby Evans 
Sent: Monday, January 4, 2016 12:04 PM
Subject: Re: [DISCUSS] 1.0 release

Of the three blockers:

STORM-1141 looks invalid now that 0.10.0 has been released.
STORM-930 also looks invalid, and there aren’t many details to diagnose.
STORM-617 doesn’t seem like a blocker, since there is a workaround for the 
issue.

I will look through JIRA and open pull requests to see if there are any other 
issues we should be tracking for the 1.0 release.

For me, STORM-1406 would be nice to have, but I don’t see it in any way a 
blocker for the 1.0 release. The only thing I have to complete before opening a 
pull request is documentation and sample usage. Again, I’m fine if it doesn’t 
make it into 1.0.

-Taylor



> On Jan 4, 2016, at 12:33 PM, Bobby Evans  wrote:
> 
> I feel we are about ready to do a 1.0 release.
> The only JIRA left on the list 
> (https://cwiki.apache.org/confluence/display/STORM/Storm+Release+1.0) is 
> STORM-1371.  I would also like to see STORM-1202 go in.
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3E%3D%20Blocker
> only shows 3 blockers.  we should review them, but they don't look like real 
> blockers to me.
> Are we missing anything?  If not as soon as STORM-1371 and STORM-1202 I will 
> create a 1.0 branch and we can start work on stabilizing 1.0 enough to 
> release, and in parallel start the JStorm migration work.
>  - Bobby

[jira] [Resolved] (STORM-1409) StormClientErrorHandler is not used

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1409.

   Resolution: Fixed
Fix Version/s: 0.11.0

I merged this to master.

> StormClientErrorHandler is not used
> ---
>
> Key: STORM-1409
> URL: https://issues.apache.org/jira/browse/STORM-1409
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>    Reporter: Derek Dagit
>    Assignee: Derek Dagit
>Priority: Trivial
> Fix For: 0.11.0
>
>
> StormClientErrorHandler was used in the past, but it is no longer used.



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

[jira] [Updated] (STORM-1392) Storm Cassandra Test Timeouts

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1392:
---
Issue Type: Sub-task  (was: Bug)
Parent: STORM-915

> Storm Cassandra Test Timeouts
> -
>
> Key: STORM-1392
> URL: https://issues.apache.org/jira/browse/STORM-1392
> Project: Apache Storm
>  Issue Type: Sub-task
>  Components: storm-cassandra
>Affects Versions: 0.11.0
>    Reporter: Derek Dagit
>Priority: Minor
>  Labels: newbie
>
> Noticed the following error in one of the travis-ci test runs.  If it makes 
> sense, we should adjust the test timeout so that this does not fail as often.
> In org.apache.storm.cassandra.DynamicStatementBuilderTest
> {noformat}
> java.lang.AssertionError: Cassandra daemon did not start within timeout
> {noformat}
> This is annoying because test for unrelated changes can fail, causing 
> confusion.



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

[jira] [Created] (STORM-1410) Add tests to cover multilang functionality

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1410:
--

 Summary: Add tests to cover multilang functionality
 Key: STORM-1410
 URL: https://issues.apache.org/jira/browse/STORM-1410
 Project: Apache Storm
  Issue Type: Test
  Components: storm-core, storm-multilang
Reporter: Derek Dagit


STORM-1401 proposed the removal of multilang-test, which had been causing 
problems with the travis-ci builds.

These tests launched topologies, waited, and stopped them.  A pass was the 
absence of a crash.  If they crashed, they stopped the tests and produced a ton 
of topology.debug ouput that was not helpful.

We should write new unit tests and/or integration tests that cover JavaScript, 
Ruby, and Python that are in storm-multilang, and we should also cover the 
Shell* pieces that are in storm-core.



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

[jira] [Created] (STORM-1409) StormClientErrorHandler is not used

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1409:
--

 Summary: StormClientErrorHandler is not used
 Key: STORM-1409
 URL: https://issues.apache.org/jira/browse/STORM-1409
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Reporter: Derek Dagit
Assignee: Derek Dagit
Priority: Trivial


StormClientErrorHandler was used in the past, but it is no longer used.



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

[jira] [Resolved] (STORM-898) Add priorities and per user resource guarantees to Resource Aware Scheduler

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-898.
---
   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks, [~JerryA], this has been merged to master.

> Add priorities and per user resource guarantees to Resource Aware Scheduler
> ---
>
> Key: STORM-898
> URL: https://issues.apache.org/jira/browse/STORM-898
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>Assignee: Boyang Jerry Peng
> Fix For: 0.11.0
>
> Attachments: Resource Aware Scheduler for Storm.pdf
>
>
> In a multi-tenant environment we would like to be able to give individual 
> users a guarantee of how much CPU/Memory/Network they will be able to use in 
> a cluster.  We would also like to know which topologies a user feels are the 
> most important to keep running if there are not enough resources to run all 
> of their topologies.
> Each user should be able to specify if their topology is production, staging, 
> or development. Within each of those categories a user should be able to give 
> a topology a priority, 0 to 10 with 10 being the highest priority (or 
> something like this).
> If there are not enough resources on a cluster to run a topology assume this 
> topology is running using resources and find the user that is most over their 
> guaranteed resources.  Shoot the lowest priority topology for that user, and 
> repeat until, this topology is able to run, or this topology would be the one 
> shot.   Ideally we don't actually shoot anything until we know that we would 
> have made enough room.
> If the cluster is over-subscribed and everyone is under their guarantee, and 
> this topology would not put the user over their guarantee.  Shoot the lowest 
> priority topology in this workers resource pool until there is enough room to 
> run the topology or this topology is the one that would be shot.  We might 
> also want to think about what to do if we are going to shoot a production 
> topology in an oversubscribed case, and perhaps we can shoot a non-production 
> topology instead even if the other user is not over their guarantee.



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

[jira] [Comment Edited] (STORM-898) Add priorities and per user resource guarantees to Resource Aware Scheduler

[Derek Dagit (JIRA)]

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

Derek Dagit edited comment on STORM-898 at 12/21/15 2:56 PM:
-

Thanks,[~jerrypeng], this has been merged to master.

EDIT: correct usename


was (Author: dagit):
Thanks, [~JerryA], this has been merged to master.

> Add priorities and per user resource guarantees to Resource Aware Scheduler
> ---
>
> Key: STORM-898
> URL: https://issues.apache.org/jira/browse/STORM-898
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>Assignee: Boyang Jerry Peng
> Fix For: 0.11.0
>
> Attachments: Resource Aware Scheduler for Storm.pdf
>
>
> In a multi-tenant environment we would like to be able to give individual 
> users a guarantee of how much CPU/Memory/Network they will be able to use in 
> a cluster.  We would also like to know which topologies a user feels are the 
> most important to keep running if there are not enough resources to run all 
> of their topologies.
> Each user should be able to specify if their topology is production, staging, 
> or development. Within each of those categories a user should be able to give 
> a topology a priority, 0 to 10 with 10 being the highest priority (or 
> something like this).
> If there are not enough resources on a cluster to run a topology assume this 
> topology is running using resources and find the user that is most over their 
> guaranteed resources.  Shoot the lowest priority topology for that user, and 
> repeat until, this topology is able to run, or this topology would be the one 
> shot.   Ideally we don't actually shoot anything until we know that we would 
> have made enough room.
> If the cluster is over-subscribed and everyone is under their guarantee, and 
> this topology would not put the user over their guarantee.  Shoot the lowest 
> priority topology in this workers resource pool until there is enough room to 
> run the topology or this topology is the one that would be shot.  We might 
> also want to think about what to do if we are going to shoot a production 
> topology in an oversubscribed case, and perhaps we can shoot a non-production 
> topology instead even if the other user is not over their guarantee.



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

[jira] [Resolved] (STORM-1400) Netty Context removeClient() called after term() causes NullPointerException.

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1400.

   Resolution: Fixed
Fix Version/s: 0.11.0

Merged to master.

> Netty Context removeClient() called after term() causes NullPointerException.
> -
>
> Key: STORM-1400
> URL: https://issues.apache.org/jira/browse/STORM-1400
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
> Fix For: 0.11.0
>
>
> Under the right conditions, we can throw a NullPointerException when shutting 
> down.
> This was seen in a travis-ci run of messaging-test 
> [here|https://travis-ci.org/apache/storm/jobs/97494930#L1315].



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

[jira] [Created] (STORM-1404) mockito test failures in storm-kafka

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1404:
--

 Summary: mockito test failures in storm-kafka
 Key: STORM-1404
 URL: https://issues.apache.org/jira/browse/STORM-1404
 Project: Apache Storm
  Issue Type: Sub-task
Reporter: Derek Dagit
Priority: Minor


{noformat}
Tests run: 8, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 17.194 sec <<< 
FAILURE! - in storm.kafka.bolt.KafkaBoltTest

executeWithByteArrayKeyAndMessageAsync(storm.kafka.bolt.KafkaBoltTest)  Time 
elapsed: 3.526 sec  <<< FAILURE!

org.mockito.exceptions.verification.WantedButNotInvoked: 

Wanted but not invoked:

collector.ack(

source: null:1, stream: , id: {}, [[B@29e2aabd, [B@603773c6]

);

-> at 
storm.kafka.bolt.KafkaBoltTest.executeWithByteArrayKeyAndMessageAsync(KafkaBoltTest.java:144)

However, there were other interactions with this mock:

-> at backtype.storm.task.OutputCollector.reportError(OutputCollector.java:223)

-> at backtype.storm.task.OutputCollector.fail(OutputCollector.java:218)

at 
storm.kafka.bolt.KafkaBoltTest.executeWithByteArrayKeyAndMessageAsync(KafkaBoltTest.java:144)
{noformat}

Seen [here|https://travis-ci.org/apache/storm/jobs/97734764#L352]

Not sure about how often this happens, but it is definitely not 100% of the 
time.



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

[jira] [Updated] (STORM-1401) Spurious multilang-test crashes on travis-ci

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1401:
---
Issue Type: Sub-task  (was: Bug)
Parent: STORM-915

> Spurious multilang-test crashes on travis-ci
> 
>
> Key: STORM-1401
> URL: https://issues.apache.org/jira/browse/STORM-1401
> Project: Apache Storm
>  Issue Type: Sub-task
>  Components: storm-multilang
>Affects Versions: 0.11.0
>    Reporter: Derek Dagit
>Priority: Minor
>
> One example here: https://travis-ci.org/apache/storm/jobs/97589141#L438
> The test failure does not happen consistently; when they do, they seem to 
> halt the test job.



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

[jira] [Resolved] (STORM-1377) nimbus_auth_test: very short timeouts causing spurious failures

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1377.

   Resolution: Fixed
Fix Version/s: 0.11.0

Merged to master

> nimbus_auth_test: very short timeouts causing spurious failures
> ---
>
> Key: STORM-1377
> URL: https://issues.apache.org/jira/browse/STORM-1377
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.0, 0.11.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
> Fix For: 0.11.0
>
>
> This is caused by a units mismatch.  We are waiting 30 ms for the thrift 
> server to reply when we thought we were waiting 30s.  This means that 
> sometimes when we expect NotAliveException, we instead get 
> TTransportException(SocketTimeoutException), and this fails the assertions.



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

[jira] [Created] (STORM-1400) Netty Context removeClient() called after term() causes NullPointerException.

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1400:
--

 Summary: Netty Context removeClient() called after term() causes 
NullPointerException.
 Key: STORM-1400
 URL: https://issues.apache.org/jira/browse/STORM-1400
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 0.10.0
Reporter: Derek Dagit
Assignee: Derek Dagit
Priority: Minor


Under the right conditions, we can throw a NullPointerException when shutting 
down.

This was seen in a travis-ci run of messaging-test 
[here|https://travis-ci.org/apache/storm/jobs/97494930#L1315].



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

[jira] [Commented] (STORM-1401) Spurious multilang-test crashes on travis-ci

[Derek Dagit (JIRA)]

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

Derek Dagit commented on STORM-1401:


We might have better luck trying to reproduce this on a single-core system.

> Spurious multilang-test crashes on travis-ci
> 
>
> Key: STORM-1401
> URL: https://issues.apache.org/jira/browse/STORM-1401
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-multilang
>Affects Versions: 0.11.0
>    Reporter: Derek Dagit
>Priority: Minor
>
> One example here: https://travis-ci.org/apache/storm/jobs/97589141#L438
> The test failure does not happen consistently; when they do, they seem to 
> halt the test job.



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

[jira] [Created] (STORM-1401) Spurious multilang-test crashes on travis-ci

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1401:
--

 Summary: Spurious multilang-test crashes on travis-ci
 Key: STORM-1401
 URL: https://issues.apache.org/jira/browse/STORM-1401
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-multilang
Affects Versions: 0.11.0
Reporter: Derek Dagit
Priority: Minor


One example here: https://travis-ci.org/apache/storm/jobs/97589141#L438

The test failure does not happen consistently; when they do, they seem to halt 
the test job.



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

[jira] [Resolved] (STORM-1383) Supervisors should not crash if nimbus is unavailable

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1383.

   Resolution: Fixed
Fix Version/s: 0.11.0

Merged to master

> Supervisors should not crash if nimbus is unavailable
> -
>
> Key: STORM-1383
> URL: https://issues.apache.org/jira/browse/STORM-1383
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Affects Versions: 0.11.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
> Fix For: 0.11.0
>
>
> In cases of maintenance or unexpected downtime of nimbus nodes, supervisors 
> will crash in a loop.  This can cause a lot of confusion among users 
> (supervisors crash repeatedly) and admins (monitoring/alerting triggered for 
> the entire cluster).
> Supervisors periodically check with nimbus to synchronize blob versions, and 
> as part of this, a connection is made to the leader nimbus daemon.  Formerly, 
> supervisors did not periodically contact nimbus, and so nimbus downtime did 
> not cascade to cluster-wide supervisor failures.
> It might be nice to handle the case when nimbus cannot be contacted, and 
> continue in the normal loop.



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

[jira] [Created] (STORM-1392) Storm Cassandra Test Timeouts

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1392:
--

 Summary: Storm Cassandra Test Timeouts
 Key: STORM-1392
 URL: https://issues.apache.org/jira/browse/STORM-1392
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-cassandra
Affects Versions: 0.11.0
Reporter: Derek Dagit
Priority: Minor


Noticed the following error in one of the travis-ci test runs.  If it makes 
sense, we should adjust the test timeout so that this does not fail as often.

In org.apache.storm.cassandra.DynamicStatementBuilderTest

{noformat}
java.lang.AssertionError: Cassandra daemon did not start within timeout
{noformat}


This is annoying because test for unrelated changes can fail, causing confusion.



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

Recovering test report XML from travis-ci

[Derek Dagit]

Does anyone know how to do this?

The log captures how many failures or errors happened in each test, but the 
really valuable information is in the test report XML files.

I see there is support for uploading artifacts[1], but I am not sure storm 
builds use it.
 
-- 

Derek

[1] https://docs.travis-ci.com/user/uploading-artifacts/

[jira] [Updated] (STORM-1377) nimbus_auth_test: very short timeouts causing spurious failures

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1377:
---
Description: This is caused by a units mismatch.  We are waiting 30 ms for 
the thrift server to reply when we thought we were waiting 30s.  This means 
that sometimes when we expect NotAliveException, we instead get 
TTransportException(SocketTimeoutException), and this fails the assertions.  
(was: A race condition may lead certain tests to fail in the nimbus-auth-test 
namespace.

{noformat}
Running backtype.storm.security.auth.nimbus-auth-test

75777 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 access 
from:  principal:  operation: submitTopology

75780 [pool-475-thread-1] WARN  b.s.d.nimbus - Topology submission exception. 
(topology name='topo-name') #error {

 :cause nil

 :via

 [{:type backtype.storm.generated.AuthorizationException

   :message nil

   :at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
nimbus.clj 935]}]

 :trace

 [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 935]

  [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 938]

  [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
submitTopologyWithOpts nimbus.clj 1328]

  [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
submitTopology nimbus.clj 1401]

  [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
Nimbus.java 2014]

  [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
Nimbus.java 1998]

  [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]

  [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]

  [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
process SimpleTransportPlugin.java 158]

  [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
AbstractNonblockingServer.java 518]

  [org.apache.thrift.server.Invocation run Invocation.java 18]

  [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
1142]

  [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
617]

  [java.lang.Thread run Thread.java 745]]}

75956 [Thread-191-spout-executor[8 8]-EventThread] WARN  o.a.c.ConnectionState 
- Session expired event received

75959 [Thread-191-spout-executor[8 8]-EventThread] INFO  
o.a.c.f.s.ConnectionStateManager - State change: LOST

75984 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 access 
from:  principal:  operation: submitTopology

75984 [pool-475-thread-2] WARN  b.s.d.nimbus - Topology submission exception. 
(topology name='topo-name') #error {

 :cause nil

 :via

 [{:type backtype.storm.generated.AuthorizationException

   :message nil

   :at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
nimbus.clj 935]}]

 :trace

 [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 935]

  [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 938]

  [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
submitTopologyWithOpts nimbus.clj 1328]

  [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
Nimbus.java 2042]

  [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
Nimbus.java 2026]

  [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]

  [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]

  [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
process SimpleTransportPlugin.java 158]

  [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
AbstractNonblockingServer.java 518]

  [org.apache.thrift.server.Invocation run Invocation.java 18]

  [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
1142]

  [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
617]

  [java.lang.Thread run Thread.java 745]]}

75989 [Thread-191-spout-executor[8 8]-EventThread] INFO  
o.a.c.f.s.ConnectionStateManager - State change: RECONNECTED

76006 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 access 
from:  principal:  operation: fileUpload

76044 [pool-475-thread-4] INFO  b.s.l.ThriftAccessLogger - Request ID: 9 access 
from:  principal:  operation: fileUpload

76049 [pool-475-thread-5] INFO  b.s.l.ThriftAccessLogger - Request ID: 10 
access from:  principal:  operation: fileUpload

76054 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 access 
from:  principal:  operation: fileDownload

76059 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 access 
from:  principal:  operation: fileDownload

76063 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 access 
from:  principal:  operation: getNimbusConf

76068 [pool-475-thread-4] INFO

[jira] [Updated] (STORM-1377) nimbus_auth_test: very short timeouts causing spurious failures

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1377:
---
Summary: nimbus_auth_test: very short timeouts causing spurious failures  
(was: nimbus_auth_test: some tests may access the wrong nimbus test node )

> nimbus_auth_test: very short timeouts causing spurious failures
> ---
>
> Key: STORM-1377
> URL: https://issues.apache.org/jira/browse/STORM-1377
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.0, 0.11.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
>
> A race condition may lead certain tests to fail in the nimbus-auth-test 
> namespace.
> {noformat}
> Running backtype.storm.security.auth.nimbus-auth-test
> 75777 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 
> access from:  principal:  operation: submitTopology
> 75780 [pool-475-thread-1] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopology nimbus.clj 1401]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 2014]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 1998]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75956 [Thread-191-spout-executor[8 8]-EventThread] WARN  
> o.a.c.ConnectionState - Session expired event received
> 75959 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: LOST
> 75984 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 
> access from:  principal:  operation: submitTopology
> 75984 [pool-475-thread-2] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2042]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2026]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75989 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: RECONNECTED
> 76006 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Reque

[jira] [Created] (STORM-1383) Supervisors should not crash if nimbus is unavailable

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1383:
--

 Summary: Supervisors should not crash if nimbus is unavailable
 Key: STORM-1383
 URL: https://issues.apache.org/jira/browse/STORM-1383
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-core
Affects Versions: 0.11.0
Reporter: Derek Dagit
Assignee: Derek Dagit


In cases of maintenance or unexpected downtime of nimbus nodes, supervisors 
will crash in a loop.  This can cause a lot of confusion among users 
(supervisors crash repeatedly) and admins (monitoring/alerting triggered for 
the entire cluster).

Supervisors periodically check with nimbus to synchronize blob versions, and as 
part of this, a connection is made to the leader nimbus daemon.  Formerly, 
supervisors did not periodically contact nimbus, and so nimbus downtime did not 
cascade to cluster-wide supervisor failures.

It might be nice to handle the case when nimbus cannot be contacted, and 
continue in the normal loop.




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

[jira] [Resolved] (STORM-1036) do not remove storm-code in supervisor until kill job

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1036.

Resolution: Duplicate

> do not remove storm-code in supervisor until kill job
> -
>
> Key: STORM-1036
> URL: https://issues.apache.org/jira/browse/STORM-1036
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: XinzeChi
>




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

Re: Welcome new Apache Storm Committers/PMC Members

[Derek Dagit]

Congrats!


 -- 
Derek


- Original Message -
From: P. Taylor Goetz 
To: dev@storm.apache.org
Sent: Tuesday, December 8, 2015 3:50 PM
Subject: Welcome new Apache Storm Committers/PMC Members

I’m pleased to announce that the following individuals have joined as Apache 
Storm Committers/PMC Members:

- Longda Feng
- Arun Mahadevan
- Boyang Jerry Peng
- Matthias J. Sax
- Aaron Dossett

Longda, Arun, Jerry, Matthias, and Aaron have all demonstrated technical merit 
and dedication to Apache Storm and its community, and as PMC members they will 
help drive innovation and community development.

Please join me in welcoming and congratulating Londa, Arun, Jerry, Matthias, 
and Aaron. We look forward to your continued dedication to the Storm community.

-Taylor

[jira] [Updated] (STORM-1377) nimbus_auth_test: some tests may access the wrong nimbus test node

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1377:
---
Affects Version/s: 0.11.0
   0.10.0

> nimbus_auth_test: some tests may access the wrong nimbus test node 
> ---
>
> Key: STORM-1377
> URL: https://issues.apache.org/jira/browse/STORM-1377
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.0, 0.11.0
>    Reporter: Derek Dagit
>Priority: Minor
>
> A race condition may lead certain tests to fail in the nimbus-auth-test 
> namespace.
> {noformat}
> Running backtype.storm.security.auth.nimbus-auth-test
> 75777 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 
> access from:  principal:  operation: submitTopology
> 75780 [pool-475-thread-1] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopology nimbus.clj 1401]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 2014]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 1998]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75956 [Thread-191-spout-executor[8 8]-EventThread] WARN  
> o.a.c.ConnectionState - Session expired event received
> 75959 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: LOST
> 75984 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 
> access from:  principal:  operation: submitTopology
> 75984 [pool-475-thread-2] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2042]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2026]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75989 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: RECONNECTED
> 76006 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 
> access from:  principal:  operation: fileUpload
> 76044 [pool-475-thread-4] INFO  b.s.l.ThriftAccessLogger - Re

[jira] [Created] (STORM-1377) nimbus_auth_test: some tests may access the wrong nimbus test node

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1377:
--

 Summary: nimbus_auth_test: some tests may access the wrong nimbus 
test node 
 Key: STORM-1377
 URL: https://issues.apache.org/jira/browse/STORM-1377
 Project: Apache Storm
  Issue Type: Bug
Reporter: Derek Dagit
Priority: Minor


A race condition may lead certain tests to fail in the nimbus-auth-test 
namespace.

{noformat}
Running backtype.storm.security.auth.nimbus-auth-test

75777 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 access 
from:  principal:  operation: submitTopology

75780 [pool-475-thread-1] WARN  b.s.d.nimbus - Topology submission exception. 
(topology name='topo-name') #error {

 :cause nil

 :via

 [{:type backtype.storm.generated.AuthorizationException

   :message nil

   :at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
nimbus.clj 935]}]

 :trace

 [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 935]

  [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 938]

  [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
submitTopologyWithOpts nimbus.clj 1328]

  [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
submitTopology nimbus.clj 1401]

  [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
Nimbus.java 2014]

  [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
Nimbus.java 1998]

  [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]

  [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]

  [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
process SimpleTransportPlugin.java 158]

  [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
AbstractNonblockingServer.java 518]

  [org.apache.thrift.server.Invocation run Invocation.java 18]

  [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
1142]

  [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
617]

  [java.lang.Thread run Thread.java 745]]}

75956 [Thread-191-spout-executor[8 8]-EventThread] WARN  o.a.c.ConnectionState 
- Session expired event received

75959 [Thread-191-spout-executor[8 8]-EventThread] INFO  
o.a.c.f.s.ConnectionStateManager - State change: LOST

75984 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 access 
from:  principal:  operation: submitTopology

75984 [pool-475-thread-2] WARN  b.s.d.nimbus - Topology submission exception. 
(topology name='topo-name') #error {

 :cause nil

 :via

 [{:type backtype.storm.generated.AuthorizationException

   :message nil

   :at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
nimbus.clj 935]}]

 :trace

 [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 935]

  [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 938]

  [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
submitTopologyWithOpts nimbus.clj 1328]

  [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
Nimbus.java 2042]

  [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
Nimbus.java 2026]

  [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]

  [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]

  [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
process SimpleTransportPlugin.java 158]

  [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
AbstractNonblockingServer.java 518]

  [org.apache.thrift.server.Invocation run Invocation.java 18]

  [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
1142]

  [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
617]

  [java.lang.Thread run Thread.java 745]]}

75989 [Thread-191-spout-executor[8 8]-EventThread] INFO  
o.a.c.f.s.ConnectionStateManager - State change: RECONNECTED

76006 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 access 
from:  principal:  operation: fileUpload

76044 [pool-475-thread-4] INFO  b.s.l.ThriftAccessLogger - Request ID: 9 access 
from:  principal:  operation: fileUpload

76049 [pool-475-thread-5] INFO  b.s.l.ThriftAccessLogger - Request ID: 10 
access from:  principal:  operation: fileUpload

76054 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 access 
from:  principal:  operation: fileDownload

76059 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 access 
from:  principal:  operation: fileDownload

76063 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 access 
from:  principal:  operation: getNimbusConf

76068 [pool-475-thread-4] INFO  b.s.l.ThriftAccessLogger - Request ID: 9 access 
from:  principal:  operation: getClusterInfo

76074 [pool-475-thread-5

[jira] [Updated] (STORM-1377) nimbus_auth_test: some tests may access the wrong nimbus test node

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1377:
---
Component/s: storm-core

> nimbus_auth_test: some tests may access the wrong nimbus test node 
> ---
>
> Key: STORM-1377
> URL: https://issues.apache.org/jira/browse/STORM-1377
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>    Reporter: Derek Dagit
>Priority: Minor
>
> A race condition may lead certain tests to fail in the nimbus-auth-test 
> namespace.
> {noformat}
> Running backtype.storm.security.auth.nimbus-auth-test
> 75777 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 
> access from:  principal:  operation: submitTopology
> 75780 [pool-475-thread-1] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopology nimbus.clj 1401]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 2014]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 1998]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75956 [Thread-191-spout-executor[8 8]-EventThread] WARN  
> o.a.c.ConnectionState - Session expired event received
> 75959 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: LOST
> 75984 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 
> access from:  principal:  operation: submitTopology
> 75984 [pool-475-thread-2] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2042]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2026]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75989 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: RECONNECTED
> 76006 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 
> access from:  principal:  operation: fileUpload
> 76044 [pool-475-thread-4] INFO  b.s.l.ThriftAccessLogger - Request ID: 9 
> access from:  principal:  operation: fileUpload
> 760

[jira] [Assigned] (STORM-1377) nimbus_auth_test: some tests may access the wrong nimbus test node

[Derek Dagit (JIRA)]

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

Derek Dagit reassigned STORM-1377:
--

Assignee: Derek Dagit

> nimbus_auth_test: some tests may access the wrong nimbus test node 
> ---
>
> Key: STORM-1377
> URL: https://issues.apache.org/jira/browse/STORM-1377
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.0, 0.11.0
>    Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
>
> A race condition may lead certain tests to fail in the nimbus-auth-test 
> namespace.
> {noformat}
> Running backtype.storm.security.auth.nimbus-auth-test
> 75777 [pool-475-thread-1] INFO  b.s.l.ThriftAccessLogger - Request ID: 6 
> access from:  principal:  operation: submitTopology
> 75780 [pool-475-thread-1] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopology nimbus.clj 1401]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 2014]
>   [backtype.storm.generated.Nimbus$Processor$submitTopology getResult 
> Nimbus.java 1998]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75956 [Thread-191-spout-executor[8 8]-EventThread] WARN  
> o.a.c.ConnectionState - Session expired event received
> 75959 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: LOST
> 75984 [pool-475-thread-2] INFO  b.s.l.ThriftAccessLogger - Request ID: 7 
> access from:  principal:  operation: submitTopology
> 75984 [pool-475-thread-2] WARN  b.s.d.nimbus - Topology submission exception. 
> (topology name='topo-name') #error {
>  :cause nil
>  :via
>  [{:type backtype.storm.generated.AuthorizationException
>:message nil
>:at [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke 
> nimbus.clj 935]}]
>  :trace
>  [[backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 935]
>   [backtype.storm.daemon.nimbus$check_authorization_BANG_ invoke nimbus.clj 
> 938]
>   [backtype.storm.daemon.nimbus$fn__7019$exec_fn__3205__auto__$reify__7048 
> submitTopologyWithOpts nimbus.clj 1328]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2042]
>   [backtype.storm.generated.Nimbus$Processor$submitTopologyWithOpts getResult 
> Nimbus.java 2026]
>   [org.apache.thrift.ProcessFunction process ProcessFunction.java 39]
>   [org.apache.thrift.TBaseProcessor process TBaseProcessor.java 39]
>   [backtype.storm.security.auth.SimpleTransportPlugin$SimpleWrapProcessor 
> process SimpleTransportPlugin.java 158]
>   [org.apache.thrift.server.AbstractNonblockingServer$FrameBuffer invoke 
> AbstractNonblockingServer.java 518]
>   [org.apache.thrift.server.Invocation run Invocation.java 18]
>   [java.util.concurrent.ThreadPoolExecutor runWorker ThreadPoolExecutor.java 
> 1142]
>   [java.util.concurrent.ThreadPoolExecutor$Worker run ThreadPoolExecutor.java 
> 617]
>   [java.lang.Thread run Thread.java 745]]}
> 75989 [Thread-191-spout-executor[8 8]-EventThread] INFO  
> o.a.c.f.s.ConnectionStateManager - State change: RECONNECTED
> 76006 [pool-475-thread-3] INFO  b.s.l.ThriftAccessLogger - Request ID: 8 
> access from:  principal:  operation: fileUpload
> 76044 [pool-475-thread-4] INFO  b.s.l.ThriftAccessLog

[jira] [Resolved] (STORM-1364) Log storm version on daemon start

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1364.

   Resolution: Fixed
Fix Version/s: 0.11.0

Merged to master

> Log storm version on daemon start
> -
>
> Key: STORM-1364
> URL: https://issues.apache.org/jira/browse/STORM-1364
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>    Reporter: Derek Dagit
>    Assignee: Derek Dagit
>Priority: Minor
> Fix For: 0.11.0
>
>
> As an admin, I would like each storm daemon to log its version of storm, so 
> that I can more easily root cause issues happening near an upgrade of the 
> cluster.



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

[jira] [Resolved] (STORM-756) [multilang] Introduce overflow control mechanism

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-756.
---
   Resolution: Fixed
Fix Version/s: 0.11.0

Merged back to master

> [multilang] Introduce overflow control mechanism
> 
>
> Key: STORM-756
> URL: https://issues.apache.org/jira/browse/STORM-756
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-multilang
>Affects Versions: 0.10.0, 0.9.4, 0.11.0
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
> Fix For: 0.11.0
>
>
> It's from STORM-738, 
> https://issues.apache.org/jira/browse/STORM-738?focusedCommentId=14394106=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14394106
> A. ShellBolt side control
> We can modify ShellBolt to have sent tuple ids list, and stop sending tuples 
> when list exceeds configured max value. In order to achieve this, subprocess 
> should notify "tuple id is complete" to ShellBolt.
> * It introduces new commands for multi-lang, "proceed" (or better name)
> * ShellBolt stores in-progress-of-processing tuples list.
> * Its overhead could be big, subprocess should always notify to ShellBolt 
> when any tuples are processed.
> B. subprocess side control
> We can modify subprocess to check pending queue after reading tuple.
> If it exceeds configured max value, subprocess can request "delay" to 
> ShellBolt for slowing down.
> When ShellBolt receives "delay", BoltWriterRunnable should stop polling 
> pending queue and continue polling later.
> How long ShellBolt wait for resending? Its unit would be "delay time" or 
> "tuple count". I don't know which is better yet.
> * It introduces new commands for multi-lang, "delay" (or better name)
> * I don't think it would be introduced soon, but subprocess can request delay 
> based on own statistics. (ex. pending tuple count * average tuple processed 
> time for time unit, average pending tuple count for count unit)
> ** We can leave when and how much to request "delay" to user. User can make 
> his/her own algorithm to control flooding.
> In my opinion B seems to more natural cause current issue is by subprocess 
> side so it would be better to let subprocess overcome it.



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

[jira] [Created] (STORM-1364) Log storm version on daemon start

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1364:
--

 Summary: Log storm version on daemon start
 Key: STORM-1364
 URL: https://issues.apache.org/jira/browse/STORM-1364
 Project: Apache Storm
  Issue Type: Improvement
  Components: storm-core
Reporter: Derek Dagit
Assignee: Derek Dagit
Priority: Minor


As an admin, I would like each storm daemon to log its version of storm, so 
that I can more easily root cause issues happening near an upgrade of the 
cluster.



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

[jira] [Updated] (STORM-756) [multilang] Introduce overflow control mechanism

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-756:
--
Fix Version/s: (was: 0.11.0)

> [multilang] Introduce overflow control mechanism
> 
>
> Key: STORM-756
> URL: https://issues.apache.org/jira/browse/STORM-756
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-multilang
>Affects Versions: 0.10.0, 0.9.4, 0.11.0
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>
> It's from STORM-738, 
> https://issues.apache.org/jira/browse/STORM-738?focusedCommentId=14394106=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14394106
> A. ShellBolt side control
> We can modify ShellBolt to have sent tuple ids list, and stop sending tuples 
> when list exceeds configured max value. In order to achieve this, subprocess 
> should notify "tuple id is complete" to ShellBolt.
> * It introduces new commands for multi-lang, "proceed" (or better name)
> * ShellBolt stores in-progress-of-processing tuples list.
> * Its overhead could be big, subprocess should always notify to ShellBolt 
> when any tuples are processed.
> B. subprocess side control
> We can modify subprocess to check pending queue after reading tuple.
> If it exceeds configured max value, subprocess can request "delay" to 
> ShellBolt for slowing down.
> When ShellBolt receives "delay", BoltWriterRunnable should stop polling 
> pending queue and continue polling later.
> How long ShellBolt wait for resending? Its unit would be "delay time" or 
> "tuple count". I don't know which is better yet.
> * It introduces new commands for multi-lang, "delay" (or better name)
> * I don't think it would be introduced soon, but subprocess can request delay 
> based on own statistics. (ex. pending tuple count * average tuple processed 
> time for time unit, average pending tuple count for count unit)
> ** We can leave when and how much to request "delay" to user. User can make 
> his/her own algorithm to control flooding.
> In my opinion B seems to more natural cause current issue is by subprocess 
> side so it would be better to let subprocess overcome it.



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

[jira] [Reopened] (STORM-756) [multilang] Introduce overflow control mechanism

[Derek Dagit (JIRA)]

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

Derek Dagit reopened STORM-756:
---

Reopening since the original change had to be reverted.  We just need to fix 
the failing test, and then it can go back in.

> [multilang] Introduce overflow control mechanism
> 
>
> Key: STORM-756
> URL: https://issues.apache.org/jira/browse/STORM-756
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-multilang
>Affects Versions: 0.10.0, 0.9.4, 0.11.0
>Reporter: Jungtaek Lim
>Assignee: Jungtaek Lim
>
> It's from STORM-738, 
> https://issues.apache.org/jira/browse/STORM-738?focusedCommentId=14394106=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14394106
> A. ShellBolt side control
> We can modify ShellBolt to have sent tuple ids list, and stop sending tuples 
> when list exceeds configured max value. In order to achieve this, subprocess 
> should notify "tuple id is complete" to ShellBolt.
> * It introduces new commands for multi-lang, "proceed" (or better name)
> * ShellBolt stores in-progress-of-processing tuples list.
> * Its overhead could be big, subprocess should always notify to ShellBolt 
> when any tuples are processed.
> B. subprocess side control
> We can modify subprocess to check pending queue after reading tuple.
> If it exceeds configured max value, subprocess can request "delay" to 
> ShellBolt for slowing down.
> When ShellBolt receives "delay", BoltWriterRunnable should stop polling 
> pending queue and continue polling later.
> How long ShellBolt wait for resending? Its unit would be "delay time" or 
> "tuple count". I don't know which is better yet.
> * It introduces new commands for multi-lang, "delay" (or better name)
> * I don't think it would be introduced soon, but subprocess can request delay 
> based on own statistics. (ex. pending tuple count * average tuple processed 
> time for time unit, average pending tuple count for count unit)
> ** We can leave when and how much to request "delay" to user. User can make 
> his/her own algorithm to control flooding.
> In my opinion B seems to more natural cause current issue is by subprocess 
> side so it would be better to let subprocess overcome it.



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

[jira] [Resolved] (STORM-1217) making small fixes in RAS

[Derek Dagit (JIRA)]

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

Derek Dagit resolved STORM-1217.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~jerrypeng], I merged this to master.

> making small fixes in RAS
> -
>
> Key: STORM-1217
> URL: https://issues.apache.org/jira/browse/STORM-1217
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Reporter: Boyang Jerry Peng
>Assignee: Boyang Jerry Peng
>Priority: Minor
> Fix For: 0.11.0
>
>




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

[jira] [Updated] (STORM-1217) making small fixes in RAS

[Derek Dagit (JIRA)]

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

Derek Dagit updated STORM-1217:
---
Component/s: storm-core

> making small fixes in RAS
> -
>
> Key: STORM-1217
> URL: https://issues.apache.org/jira/browse/STORM-1217
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Reporter: Boyang Jerry Peng
>Assignee: Boyang Jerry Peng
>Priority: Minor
>




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

Re: [VOTE] Storm 2.0 plan

[Derek Dagit]

I am OK with this plan.
 
-- 
Derek



From: Bobby Evans 
To: Dev  
Sent: Monday, November 23, 2015 3:40 PM
Subject: [VOTE] Storm 2.0 plan


Sorry for spaming everyone with all the JIRA creations today.  I have filed all 
of the JIRA corresponding to the plan for JStorm merger listed here.
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328109
The bylaws 
https://github.com/apache/storm/blob/master/docs/documentation/BYLAWS.md don't 
cover a vote on the direction of the project like this.  They cover the merger 
of each pull request that would be made, but not a direction change. As such 
this vote is more symbolic than anything, and I would love to hear from 
everyone involved.

The current plan is to finish merging in features for a 1.0 release.  

https://cwiki.apache.org/confluence/display/STORM/Storm+Release+1.0
is supposed to cover this, but I think it is missing some features others want, 
so please let us know if you really want to get your feature in before this 
happens.  As such the time frame is a bit flexible but I would like to shoot 
for doing a storm-1.0 release before mid December.
After that we would begin merging in the clojure->java transition JIRA.  Once 
those are complete the feature freeze would be lifted and JStorm features would 
be merged in along with other features.  Hopefully we would have a Storm 2.0 
release by mid February to mid March, depending on how things go. 

I am +1 on this plan (if you couldn't tell)
 - Bobby

New website HTTPS mixed content & firefox

[Derek Dagit]

https://storm.apache.org/



Firefox is telling me it has blocked some items that are not delivered via 
HTTPS, and I noticed that possibly the font used for bullet lists did not load 
correctly.



Does anyone else see something similar?

 -- 
Derek

[jira] [Created] (STORM-1208) UI: NPE seen when aggregating bolt streams stats

[Derek Dagit (JIRA)]

Derek Dagit created STORM-1208:
--

 Summary: UI: NPE seen when aggregating bolt streams stats
 Key: STORM-1208
 URL: https://issues.apache.org/jira/browse/STORM-1208
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-core
Affects Versions: 0.11.0
Reporter: Derek Dagit
Assignee: Derek Dagit


A stack trace is seen on the UI via its thrift connection to nimbus.

On nimbus, a stack trace similar to the following is seen:

{noformat}
2015-11-09 19:26:48.921 o.a.t.s.TThreadPoolServer [ERROR] Error occurred during 
processing of message.
java.lang.NullPointerException
at 
backtype.storm.stats$agg_bolt_streams_lat_and_count$iter__2219__2223$fn__2224.invoke(stats.clj:346)
 ~[storm-core-0.10.1.jar:0.10.1]
at clojure.lang.LazySeq.sval(LazySeq.java:40) ~[clojure-1.6.0.jar:?]
at clojure.lang.LazySeq.seq(LazySeq.java:49) ~[clojure-1.6.0.jar:?]
at clojure.lang.RT.seq(RT.java:484) ~[clojure-1.6.0.jar:?]
at clojure.core$seq.invoke(core.clj:133) ~[clojure-1.6.0.jar:?]
at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30) 
~[clojure-1.6.0.jar:?]
at clojure.core.protocols$fn__6078.invoke(protocols.clj:54) 
~[clojure-1.6.0.jar:?]
at 
clojure.core.protocols$fn__6031$G__6026__6044.invoke(protocols.clj:13) 
~[clojure-1.6.0.jar:?]
at clojure.core$reduce.invoke(core.clj:6289) ~[clojure-1.6.0.jar:?]
at clojure.core$into.invoke(core.clj:6341) ~[clojure-1.6.0.jar:?]
at 
backtype.storm.stats$agg_bolt_streams_lat_and_count.invoke(stats.clj:344) 
~[storm-core-0.10.1.jar:0.10.1]
at 
backtype.storm.stats$agg_pre_merge_comp_page_bolt.invoke(stats.clj:439) 
~[storm-core-0.10.1.jar:0.10.1]
at backtype.storm.stats$fn__2578.invoke(stats.clj:1093) 
~[storm-core-0.10.1.jar:0.10.1]
at clojure.lang.MultiFn.invoke(MultiFn.java:241) ~[clojure-1.6.0.jar:?]
at clojure.lang.AFn.applyToHelper(AFn.java:165) ~[clojure-1.6.0.jar:?]
at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
at clojure.core$apply.invoke(core.clj:628) ~[clojure-1.6.0.jar:?]
at clojure.core$partial$fn__4230.doInvoke(core.clj:2470) 
~[clojure-1.6.0.jar:?]
at clojure.lang.RestFn.invoke(RestFn.java:421) ~[clojure-1.6.0.jar:?]
at clojure.core.protocols$fn__6086.invoke(protocols.clj:143) 
~[clojure-1.6.0.jar:?]
at 
clojure.core.protocols$fn__6057$G__6052__6066.invoke(protocols.clj:19) 
~[clojure-1.6.0.jar:?]
at clojure.core.protocols$seq_reduce.invoke(protocols.clj:31) 
~[clojure-1.6.0.jar:?]
at clojure.core.protocols$fn__6078.invoke(protocols.clj:54) 
~[clojure-1.6.0.jar:?]
at 
clojure.core.protocols$fn__6031$G__6026__6044.invoke(protocols.clj:13) 
~[clojure-1.6.0.jar:?]
at clojure.core$reduce.invoke(core.clj:6289) ~[clojure-1.6.0.jar:?]
at 
backtype.storm.stats$aggregate_comp_stats_STAR_.invoke(stats.clj:1106) 
~[storm-core-0.10.1.jar:0.10.1]
at clojure.lang.AFn.applyToHelper(AFn.java:165) ~[clojure-1.6.0.jar:?]
at clojure.lang.AFn.applyTo(AFn.java:144) ~[clojure-1.6.0.jar:?]
at clojure.core$apply.invoke(core.clj:624) ~[clojure-1.6.0.jar:?]
at backtype.storm.stats$fn__2589.doInvoke(stats.clj:1127) 
~[storm-core-0.10.1.jar:0.10.1]
at clojure.lang.RestFn.invoke(RestFn.java:436) ~[clojure-1.6.0.jar:?]
at clojure.lang.MultiFn.invoke(MultiFn.java:236) ~[clojure-1.6.0.jar:?]
at backtype.storm.stats$agg_comp_execs_stats.invoke(stats.clj:1303) 
~[storm-core-0.10.1.jar:0.10.1]
at 
backtype.storm.daemon.nimbus$fn__5893$exec_fn__1502__auto__$reify__5917.getComponentPageInfo(nimbus.clj:1715)
 ~[storm-core-0.10.1.jar:0.10.1]
at 
backtype.storm.generated.Nimbus$Processor$getComponentPageInfo.getResult(Nimbus.java:3677)
 ~[storm-core-0.10.1.jar:0.10.1]
at 
backtype.storm.generated.Nimbus$Processor$getComponentPageInfo.getResult(Nimbus.java:3661)
 ~[storm-core-0.10.1.jar:0.10.1]
at org.apache.thrift7.ProcessFunction.process(ProcessFunction.java:39) 
~[storm-core-0.10.1.jar:0.10.1]
at org.apache.thrift7.TBaseProcessor.process(TBaseProcessor.java:39) 
~[storm-core-0.10.1.jar:0.10.1]
at 
backtype.storm.security.auth.SaslTransportPlugin$TUGIWrapProcessor.process(SaslTransportPlugin.java:143)
 ~[storm-core-0.10.1.jar:0.10.1]
at 
org.apache.thrift7.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:285)
 [storm-core-0.10.1.jar:0.10.1]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[?:1.8.0_40]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[?:1.8.0_40]
at java.lang.Thread.run(Thread.java:745) [?:1.8.0_40]
{noformat}




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