Start contributing to storm

[Sumedh Shekhar <su...@gmail.com>]

Hi,

I have been using storm for the past year and now want to start
contributing towards it's development as well. I went through the newbie
section of issues but found that most of them already have a pull request
attached to it. Can someone direct me where else I can start contributing.

Thanks,
Sumedh Shekhar

Re: Start contributing to storm

[Sumedh Shekhar <su...@gmail.com>]

Hi,

I did a little work on resolving checkstyle violations in ‘storm-webapp’
module. I have created an issue regarding this(
https://issues.apache.org/jira/browse/STORM-2537). Here is the link to the
pull request - https://github.com/apache/storm/pull/2146.

On 29-May-2017, at 11:15 PM, Stig Døssing <ge...@gmail.com> wrote:

Hi Sumedh,

Resolving checkstyle violations would probably be pretty doable? Resolving
some would be a matter of running the build for a module, and then fixing
the issues listed in target/checkstyle-report.xml.

I also think it would be good to add support for tuple timeout resets to
the writer bolts Storm ships with, though that may be a little more
involved (see https://issues.apache.org/jira/browse/STORM-2359 and the
attached document). Ideally the bolts would be capable of calling
OutputCollector.resetTimeout on tuples they're processing if the service
they're writing to is slow or temporarily unavailable.

There are also still some clojure files in storm-core that would be nice to
get ported to Java. I think (someone can correct me) that porting some of
the tests would be possible without having to touch too much other code.
For instance this one
https://github.com/apache/storm/blob/master/storm-core/
test/clj/integration/org/apache/storm/integration_test.clj

Also more of a loose idea right now, but I'd like to investigate getting
rid of compaction in the tuple windowing code at
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/
storm/windowing/WindowManager.java#L168.
It has no effect when the windowing bolt is using watermarks, or when the
window is based on tuple count. It's only really doing anything when the
window is based on tuple reception timestamps (
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/
storm/windowing/TimeTriggerPolicy.java
and
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/
storm/windowing/TimeEvictionPolicy.java),
and I think that case would be better handled by allowing the user to
combine the time trigger policy with a max tuple count. If you're
interested in looking at this there's a comment about it in the first post
here https://github.com/apache/storm/pull/2127

I hope some of this catches your interest :)

2017-05-29 18:31 GMT+02:00 Sumedh Shekhar <su...@gmail.com>:

Hi,

I have been using storm for the past year and now want to start
contributing towards it's development as well. I went through the newbie
section of issues but found that most of them already have a pull request
attached to it. Can someone direct me where else I can start contributing.

Thanks,
Sumedh Shekhar

Re: Start contributing to storm

[Stig Døssing <ge...@gmail.com>]

Hi Sumedh,

Resolving checkstyle violations would probably be pretty doable? Resolving
some would be a matter of running the build for a module, and then fixing
the issues listed in target/checkstyle-report.xml.

I also think it would be good to add support for tuple timeout resets to
the writer bolts Storm ships with, though that may be a little more
involved (see https://issues.apache.org/jira/browse/STORM-2359 and the
attached document). Ideally the bolts would be capable of calling
OutputCollector.resetTimeout on tuples they're processing if the service
they're writing to is slow or temporarily unavailable.

There are also still some clojure files in storm-core that would be nice to
get ported to Java. I think (someone can correct me) that porting some of
the tests would be possible without having to touch too much other code.
For instance this one
https://github.com/apache/storm/blob/master/storm-core/test/clj/integration/org/apache/storm/integration_test.clj

Also more of a loose idea right now, but I'd like to investigate getting
rid of compaction in the tuple windowing code at
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/windowing/WindowManager.java#L168.
It has no effect when the windowing bolt is using watermarks, or when the
window is based on tuple count. It's only really doing anything when the
window is based on tuple reception timestamps (
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/windowing/TimeTriggerPolicy.java
and
https://github.com/apache/storm/blob/master/storm-client/src/jvm/org/apache/storm/windowing/TimeEvictionPolicy.java),
and I think that case would be better handled by allowing the user to
combine the time trigger policy with a max tuple count. If you're
interested in looking at this there's a comment about it in the first post
here https://github.com/apache/storm/pull/2127

I hope some of this catches your interest :)

2017-05-29 18:31 GMT+02:00 Sumedh Shekhar <su...@gmail.com>:

> Hi,
>
> I have been using storm for the past year and now want to start
> contributing towards it's development as well. I went through the newbie
> section of issues but found that most of them already have a pull request
> attached to it. Can someone direct me where else I can start contributing.
>
> Thanks,
> Sumedh Shekhar
>