[GitHub] [storm] krichter722 commented on a change in pull request #3035: STORM-3417: Fix checkstyle violations in sql-core
krichter722 commented on a change in pull request #3035: STORM-3417: Fix checkstyle violations in sql-core URL: https://github.com/apache/storm/pull/3035#discussion_r297374751 ## File path: sql/storm-sql-core/src/jvm/org/apache/storm/sql/javac/CompilingClassLoader.java ## @@ -125,7 +125,8 @@ public CompilingClassLoader( } /** - * @return Whether compilation was successful. + * Compiles source code to byte code. Review comment: We removed the rule to add missing Javadoc on public methods and classes. The rules to validate already present Javadoc were present and remained untouched. I think this makes sense because if Javadoc is present it should be valid. It could also be removed but deciding that slows down the PR workflow in my opinion. This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] krichter722 opened a new pull request #3041: STORM-3427: integration-test: fix all checkstyle warnings
krichter722 opened a new pull request #3041: STORM-3427: integration-test: fix all checkstyle warnings URL: https://github.com/apache/storm/pull/3041 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] RuiLi8080 opened a new pull request #3040: Storm 3423 improve logviewer directory cleaner logging
RuiLi8080 opened a new pull request #3040: Storm 3423 improve logviewer directory cleaner logging URL: https://github.com/apache/storm/pull/3040 Used to be: 2019-06-20T20:38:11.626Z gsbl839n04.blue.ygrid.yahoo.com [logviewer][99056] No more files able to delete this round, but this directory is over quota by 5269.82825999 MB 2019-06-20T20:38:11.626Z gsbl839n04.blue.ygrid.yahoo.com [logviewer][99056] No more files able to delete this round, but this directory is over quota by 5269.82825999 MB 2019-06-20T20:38:11.626Z gsbl839n04.blue.ygrid.yahoo.com [logviewer][99056] No more files able to delete this round, but this directory is over quota by 5269.82825999 MB Now: 2019-06-25 20:00:02.135 o.a.s.d.l.u.DirectoryCleaner logviewer-cleanup [WARN] No more files eligible to be deleted this round, but worker directory: /home/y/var/storm/workers-artifacts/wc-1-1560810826/6700 is over per-worker quota by 77.559234 MB 2019-06-25 20:00:02.135 o.a.s.d.l.u.DirectoryCleaner logviewer-cleanup [WARN] No more files eligible to be deleted this round, but worker directory: /home/y/var/storm/workers-artifacts/wc-1-1560810826/6700 is over per-worker quota by 77.559234 MB This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] krichter722 opened a new pull request #3039: STORM-3424: storm-submit-tools: fix all checkstyle warnings
krichter722 opened a new pull request #3039: STORM-3424: storm-submit-tools: fix all checkstyle warnings URL: https://github.com/apache/storm/pull/3039 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] srdo commented on issue #3034: STORM-3422: TupleCaptureBolt is not thread-safe
srdo commented on issue #3034: STORM-3422: TupleCaptureBolt is not thread-safe URL: https://github.com/apache/storm/pull/3034#issuecomment-505580871 I think I like the ListMultiMap approach a little better, since it's not as easy to forget to synchronize a reference to the map. I would also expect there to be some contention on the map field, as it will be updated by every tuple in the local topology. You're right that using a static field for this is a bit hacky. Best alternative I can think of would be creating a field in LocalCluster, and figuring out a way to share it with these bolts. It would probably be more complicated though. Either way, I don't think this is too bad, as the TupleCaptureBolt isn't supposed to be used outside a LocalCluster, and we can make sure to e.g. clear the field between topology submissions. If you can think of a good alternative, I don't think anyone would miss this bolt :) This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] srdo commented on a change in pull request #3035: STORM-3417: Fix checkstyle violations in sql-core
srdo commented on a change in pull request #3035: STORM-3417: Fix checkstyle violations in sql-core URL: https://github.com/apache/storm/pull/3035#discussion_r297352148 ## File path: sql/storm-sql-core/src/jvm/org/apache/storm/sql/javac/CompilingClassLoader.java ## @@ -125,7 +125,8 @@ public CompilingClassLoader( } /** - * @return Whether compilation was successful. + * Compiles source code to byte code. Review comment: Wasn't this check disabled? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] krichter722 opened a new pull request #3038: STORM-3419: Fix checkstyle violations in storm-opentsdb
krichter722 opened a new pull request #3038: STORM-3419: Fix checkstyle violations in storm-opentsdb URL: https://github.com/apache/storm/pull/3038 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] krichter722 opened a new pull request #3037: STORM-3420: Fix checkstyle violations in storm-mqtt
krichter722 opened a new pull request #3037: STORM-3420: Fix checkstyle violations in storm-mqtt URL: https://github.com/apache/storm/pull/3037 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] krichter722 opened a new pull request #3036: STORM-3421: Fix checkstyle violations in storm-kinesis
krichter722 opened a new pull request #3036: STORM-3421: Fix checkstyle violations in storm-kinesis URL: https://github.com/apache/storm/pull/3036 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] krichter722 opened a new pull request #3035: STORM-3417: Fix checkstyle violations in sql-core
krichter722 opened a new pull request #3035: STORM-3417: Fix checkstyle violations in sql-core URL: https://github.com/apache/storm/pull/3035 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] JanecekPetr opened a new pull request #3034: STORM-3422: TupleCaptureBolt is not thread-safe
JanecekPetr opened a new pull request #3034: STORM-3422: TupleCaptureBolt is not thread-safe URL: https://github.com/apache/storm/pull/3034 Fixes [STORM-3422](https://issues.apache.org/jira/browse/STORM-3422). Note, **this is a preview PR meant as a base for more discussion**. There are two commits, two different approaches to the same problem, please take a look. The latter, I believe, is simpler and easier to understand. The synchronization is expected to be completely uncontended, we simply need a way to safely publish the changes made by one thread or the other. Either way, the usage of the class feels dirty, but there isn't much we can do now, is there? This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [Discuss] ARM CI for Storm
It sounds pretty low risk for us, if you're volunteering to help fix any ARM-specific CI failures that may crop up. Will this include helping to fix ARM test failures in PRs? Most people are unlikely to have an ARM environment they can use to test, and I'd prefer not to ask contributors to fix ARM test failures themselves. Den tir. 25. jun. 2019 kl. 11.08 skrev Yikun Jiang : > Sorry for late reply, actually, we have a developer team that willing to > work on this, and I'm the owner of storm ARM CI in the OpenLab team. We not > only want to enable the OpenLab CI, but also want to maintain the arm CI > job and fix the CI issue in Storm project. That means if the storm project > has some ARM compatible problem, I will very happy to fix it. > > As I mentioned before, one of the OpenLab goal is to make more open source > software to be more compatible for aarch64 platform. And the Storm project > is one of the most important one in BigData area, so we would like to > propose to work on aarch64 related works in Storm. we plan to start the > aarch64 related work from to add aarch64 build job for Storm, and our > initial plan as below: > > 1. We first propose enable a periodical job in OpenLab project to make sure > the storm can compile and build successfully in arm64 env. > 2. We hope can run the OpenLab CI in every pr to ensure that any pr after > Step 1 will not break the arm64 build. > 3. We can add more complex test cases on aarch64, like unit tests and > functional tests, step by step. It's a log term works. > > Of course, welcome another developers join to maintain the aarch64 CI, and > take effort on aarch64 work together. > > Thanks for your attention. > > Regards, > Yikun > > Jiang Yikun（Kero） > Mail: yikunk...@gmail.com > > > Stig Rohde Døssing 于2019年6月21日周五 上午2:23写道： > > > I guess there is no interest in maintaining ARM compatibility, or at > least > > no one currently wants to take on the effort. Let's not add the Openlab > CI > > then, we can always do it later if someone expresses interest (and > > willingness to maintain). > > > > Den ons. 12. jun. 2019 kl. 17.11 skrev Stig Rohde Døssing < > > stigdoess...@gmail.com>: > > > > > Good point, let's see if there's anyone with an ARM environment. > > > > > > Den tir. 11. jun. 2019 kl. 23.07 skrev Jungtaek Lim >: > > > > > >> I guess the point is not related to open CI build. The point is > whether > > we > > >> really want to support ARM. I'm seeing OpenLab request for other > Apache > > >> projects as well, so I'd rather not treat their request as commitment > of > > >> putting efforts to make builds on ARM green. > > >> > > >> I'm a bit hesitant to add some environment on the support list unless > > >> there're enough engineers willing to work on maintaining. If the work > is > > >> left to existing maintainers, we will be stuck on failing tests on ARM > > CI > > >> but no environment to play locally. > > >> > > >> So I'd be +1 if there're at least two folks experienced with ARM env. > > >> volunteer to maintain the compatibility part. Otherwise -1 here. > > >> > > >> Thanks, > > >> Jungtaek Lim (HeartSaVioR) > > >> > > >> On Mon, Jun 10, 2019 at 7:27 PM Stig Rohde Døssing < > > >> stigdoess...@gmail.com> > > >> wrote: > > >> > > >> > Hi, > > >> > > > >> > An issue was opened suggesting adding ARM CI to the Storm build, > using > > >> > OpenLab https://issues.apache.org/jira/browse/STORM-3401, > associated > > PR > > >> > here https://github.com/apache/storm/pull/3023 > > >> > > > >> > As far as I can tell, we need to allow OpenLab access to the Github > > PRs, > > >> > similar to how Travis has permission to access our PRs. The app that > > >> needs > > >> > access is https://github.com/apps/theopenlab-ci. Note that the app > > will > > >> > have access to the PRs only, not the repo code. > > >> > > > >> > Is anyone opposed to me asking infra to allow OpenLab access to our > > PRs? > > >> > I'll let this thread sit for a week or so, if there is no opposition > > >> I'll > > >> > ask infra to give the app access. > > >> > > > >> > > >> > > >> -- > > >> Name : Jungtaek Lim > > >> Blog : http://medium.com/@heartsavior > > >> Twitter : http://twitter.com/heartsavior > > >> LinkedIn : http://www.linkedin.com/in/heartsavior > > >> > > > > > >
[GitHub] [storm] srdo merged pull request #3024: STORM-3408 - update rocks version
srdo merged pull request #3024: STORM-3408 - update rocks version URL: https://github.com/apache/storm/pull/3024 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
[GitHub] [storm] srdo commented on issue #3024: STORM-3408 - update rocks version
srdo commented on issue #3024: STORM-3408 - update rocks version URL: https://github.com/apache/storm/pull/3024#issuecomment-505546939 The changes look good, and going by https://github.com/facebook/rocksdb/wiki/RocksDB-Compatibility-Between-Different-Releases we should be fine to upgrade to new versions without requiring users to do any manual migration steps. +1 This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org With regards, Apache Git Services
Re: [VOTE] Release Apache Storm 1.2.3 (rc2)
Friendly reminder on this one. Roshan Sent from Yahoo Mail for iPhone On Saturday, June 15, 2019, 9:15 AM, P. Taylor Goetz wrote: This vote is now closed and passes with 3 binding +1 votes and 1 non-binding +1 vote. I will release the artifacts and create a release announcement. -Taylor > On May 10, 2019, at 12:20 PM, P. Taylor Goetz wrote: > > This is a call to vote on releasing Apache Storm 1.2.3 (rc2) > > Full list of changes in this release: > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.2.3-rc2/RELEASE_NOTES.html > > The tag/commit to be voted upon is v1.2.3: > > https://git-wip-us.apache.org/repos/asf?p=storm.git;a=tree;h=ac0e39d7cad48b3ec863c8a3b711d36511d4daf6;hb=4e162a47c8219546ab9639401363a8f1b5e51119 > > The source archive being voted upon can be found here: > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.2.3-rc2/apache-storm-1.2.3-src.tar.gz > > Other release files, signatures and digests can be found here: > > https://dist.apache.org/repos/dist/dev/storm/apache-storm-1.2.3-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-1081 > > Please vote on releasing this package as Apache Storm 1.2.3. > > 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 1.2.3 > [ ] 0 No opinion > [ ] -1 Do not release this package because... > > Thanks to everyone who contributed to this release. > > -Taylor
Re: [Discuss] ARM CI for Storm
Sorry for late reply, actually, we have a developer team that willing to work on this, and I'm the owner of storm ARM CI in the OpenLab team. We not only want to enable the OpenLab CI, but also want to maintain the arm CI job and fix the CI issue in Storm project. That means if the storm project has some ARM compatible problem, I will very happy to fix it. As I mentioned before, one of the OpenLab goal is to make more open source software to be more compatible for aarch64 platform. And the Storm project is one of the most important one in BigData area, so we would like to propose to work on aarch64 related works in Storm. we plan to start the aarch64 related work from to add aarch64 build job for Storm, and our initial plan as below: 1. We first propose enable a periodical job in OpenLab project to make sure the storm can compile and build successfully in arm64 env. 2. We hope can run the OpenLab CI in every pr to ensure that any pr after Step 1 will not break the arm64 build. 3. We can add more complex test cases on aarch64, like unit tests and functional tests, step by step. It's a log term works. Of course, welcome another developers join to maintain the aarch64 CI, and take effort on aarch64 work together. Thanks for your attention. Regards, Yikun Jiang Yikun（Kero） Mail: yikunk...@gmail.com Stig Rohde Døssing 于2019年6月21日周五 上午2:23写道： > I guess there is no interest in maintaining ARM compatibility, or at least > no one currently wants to take on the effort. Let's not add the Openlab CI > then, we can always do it later if someone expresses interest (and > willingness to maintain). > > Den ons. 12. jun. 2019 kl. 17.11 skrev Stig Rohde Døssing < > stigdoess...@gmail.com>: > > > Good point, let's see if there's anyone with an ARM environment. > > > > Den tir. 11. jun. 2019 kl. 23.07 skrev Jungtaek Lim : > > > >> I guess the point is not related to open CI build. The point is whether > we > >> really want to support ARM. I'm seeing OpenLab request for other Apache > >> projects as well, so I'd rather not treat their request as commitment of > >> putting efforts to make builds on ARM green. > >> > >> I'm a bit hesitant to add some environment on the support list unless > >> there're enough engineers willing to work on maintaining. If the work is > >> left to existing maintainers, we will be stuck on failing tests on ARM > CI > >> but no environment to play locally. > >> > >> So I'd be +1 if there're at least two folks experienced with ARM env. > >> volunteer to maintain the compatibility part. Otherwise -1 here. > >> > >> Thanks, > >> Jungtaek Lim (HeartSaVioR) > >> > >> On Mon, Jun 10, 2019 at 7:27 PM Stig Rohde Døssing < > >> stigdoess...@gmail.com> > >> wrote: > >> > >> > Hi, > >> > > >> > An issue was opened suggesting adding ARM CI to the Storm build, using > >> > OpenLab https://issues.apache.org/jira/browse/STORM-3401, associated > PR > >> > here https://github.com/apache/storm/pull/3023 > >> > > >> > As far as I can tell, we need to allow OpenLab access to the Github > PRs, > >> > similar to how Travis has permission to access our PRs. The app that > >> needs > >> > access is https://github.com/apps/theopenlab-ci. Note that the app > will > >> > have access to the PRs only, not the repo code. > >> > > >> > Is anyone opposed to me asking infra to allow OpenLab access to our > PRs? > >> > I'll let this thread sit for a week or so, if there is no opposition > >> I'll > >> > ask infra to give the app access. > >> > > >> > >> > >> -- > >> Name : Jungtaek Lim > >> Blog : http://medium.com/@heartsavior > >> Twitter : http://twitter.com/heartsavior > >> LinkedIn : http://www.linkedin.com/in/heartsavior > >> > > >
