[GitHub] storm pull request: STORM-329: fix cascading Storm failure by impr...

[miguno]

Github user miguno commented on the pull request:

https://github.com/apache/storm/pull/429#issuecomment-75022795
  
FYI: I took the opportunity to update 
[DEVELOPER.md](https://github.com/apache/storm/blob/master/DEVELOPER.md#building)
 with documentation how to run tests selectively in the REPL.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-329) Fix cascading Storm failure by improving reconnection strategy and buffering messages

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-329:
--

Github user miguno commented on the pull request:

https://github.com/apache/storm/pull/429#issuecomment-75022795
  
FYI: I took the opportunity to update 
[DEVELOPER.md](https://github.com/apache/storm/blob/master/DEVELOPER.md#building)
 with documentation how to run tests selectively in the REPL.


> Fix cascading Storm failure by improving reconnection strategy and buffering 
> messages
> -
>
> Key: STORM-329
> URL: https://issues.apache.org/jira/browse/STORM-329
> Project: Apache Storm
>  Issue Type: Improvement
>Affects Versions: 0.9.2-incubating, 0.9.3
>Reporter: Sean Zhong
>Assignee: Michael Noll
>  Labels: Netty
> Fix For: 0.10.0
>
> Attachments: storm-329.patch, worker-kill-recover3.jpg
>
>
> _Note: The original title of this ticket was: "Add Option to Config Message 
> handling strategy when connection timeout"._
> This is to address a [concern brought 
> up|https://github.com/apache/incubator-storm/pull/103#issuecomment-43632986] 
> during the work at STORM-297:
> {quote}
> [~revans2] wrote: Your logic makes since to me on why these calls are 
> blocking. My biggest concern around the blocking is in the case of a worker 
> crashing. If a single worker crashes this can block the entire topology from 
> executing until that worker comes back up. In some cases I can see that being 
> something that you would want. In other cases I can see speed being the 
> primary concern and some users would like to get partial data fast, rather 
> then accurate data later.
> Could we make it configurable on a follow up JIRA where we can have a max 
> limit to the buffering that is allowed, before we block, or throw data away 
> (which is what zeromq does)?
> {quote}
> If some worker crash suddenly, how to handle the message which was supposed 
> to be delivered to the worker?
> 1. Should we buffer all message infinitely?
> 2. Should we block the message sending until the connection is resumed?
> 3. Should we config a buffer limit, try to buffer the message first, if the 
> limit is met, then block?
> 4. Should we neither block, nor buffer too much, but choose to drop the 
> messages, and use the built-in storm failover mechanism? 



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

[jira] [Created] (STORM-679) Enforce JDK 1.7 for storm-kafka

[jayapriya surendran (JIRA)]

jayapriya surendran created STORM-679:
-

 Summary: Enforce JDK 1.7 for storm-kafka
 Key: STORM-679
 URL: https://issues.apache.org/jira/browse/STORM-679
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-kafka
Affects Versions: 0.10.0
Reporter: jayapriya surendran
Assignee: jayapriya surendran
Priority: Minor


ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
which is specific to JDK 7. 
{code}
public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
  return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
}
{code}

As per the comment in this commit 
https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
we should enforce JDK 1.7 as the minimum requirement for storm-kafka.

Alternate fix is to change Long.compare() method to Long.compareTo() which is 
compatible with JDK 1.6.



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

[jira] [Created] (STORM-680) Enforce JDK 1.7 for storm-kafka

[jayapriya surendran (JIRA)]

jayapriya surendran created STORM-680:
-

 Summary: Enforce JDK 1.7 for storm-kafka
 Key: STORM-680
 URL: https://issues.apache.org/jira/browse/STORM-680
 Project: Apache Storm
  Issue Type: Bug
  Components: storm-kafka
Affects Versions: 0.10.0
Reporter: jayapriya surendran
Assignee: jayapriya surendran
Priority: Minor


ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
which is specific to JDK 7. 
{code}
public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
  return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
}
{code}

As per the comment in this commit 
https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
we should enforce JDK 1.7 as the minimum requirement for storm-kafka.

Alternate fix is to change Long.compare() method to Long.compareTo() which is 
compatible with JDK 1.6.



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

[jira] [Updated] (STORM-680) storm-kafka fails to compile with JDK 1.6

[jayapriya surendran (JIRA)]

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

jayapriya surendran updated STORM-680:
--
Summary: storm-kafka fails to compile with JDK 1.6  (was: Enforce JDK 1.7 
for storm-kafka)

> storm-kafka fails to compile with JDK 1.6
> -
>
> Key: STORM-680
> URL: https://issues.apache.org/jira/browse/STORM-680
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-kafka
>Affects Versions: 0.10.0
>Reporter: jayapriya surendran
>Assignee: jayapriya surendran
>Priority: Minor
>  Labels: easyfix
>
> ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
> which is specific to JDK 7. 
> {code}
> public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
>   return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
> }
> {code}
> As per the comment in this commit 
> https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
> we should enforce JDK 1.7 as the minimum requirement for storm-kafka.
> Alternate fix is to change Long.compare() method to Long.compareTo() which is 
> compatible with JDK 1.6.



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

[GitHub] storm pull request: Storm-616 : Storm-jdbc connector.

[Crystark]

Github user Crystark commented on the pull request:

https://github.com/apache/storm/pull/374#issuecomment-75028911
  
Works like a charm :)


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request: STORM-680: storm-kafka fails to compile with J...

[jayapriya90]

GitHub user jayapriya90 opened a pull request:

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

STORM-680: storm-kafka fails to compile with JDK 1.6

Replaced Long.compare() method of JDK 7 with compareTo() method of JDK 6.

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

$ git pull https://github.com/jayapriya90/storm STORM-680

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

https://github.com/apache/storm/pull/435.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #435


commit 2dd091d17c0953ddd6f863a2825cb90ec7d48978
Author: Jayapriya Surendran 
Date:   2015-02-19T10:25:39Z

STORM-680: storm-kafka fails to compile with JDK 1.6




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-680) storm-kafka fails to compile with JDK 1.6

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-680:
--

GitHub user jayapriya90 opened a pull request:

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

STORM-680: storm-kafka fails to compile with JDK 1.6

Replaced Long.compare() method of JDK 7 with compareTo() method of JDK 6.

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

$ git pull https://github.com/jayapriya90/storm STORM-680

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

https://github.com/apache/storm/pull/435.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #435


commit 2dd091d17c0953ddd6f863a2825cb90ec7d48978
Author: Jayapriya Surendran 
Date:   2015-02-19T10:25:39Z

STORM-680: storm-kafka fails to compile with JDK 1.6




> storm-kafka fails to compile with JDK 1.6
> -
>
> Key: STORM-680
> URL: https://issues.apache.org/jira/browse/STORM-680
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-kafka
>Affects Versions: 0.10.0
>Reporter: jayapriya surendran
>Assignee: jayapriya surendran
>Priority: Minor
>  Labels: easyfix
>
> ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
> which is specific to JDK 7. 
> {code}
> public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
>   return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
> }
> {code}
> As per the comment in this commit 
> https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
> we should enforce JDK 1.7 as the minimum requirement for storm-kafka.
> Alternate fix is to change Long.compare() method to Long.compareTo() which is 
> compatible with JDK 1.6.



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

[jira] [Resolved] (STORM-680) storm-kafka fails to compile with JDK 1.6

[jayapriya surendran (JIRA)]

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

jayapriya surendran resolved STORM-680.
---
Resolution: Duplicate

Resolving the issue as it is duplicate of STORM-670.

> storm-kafka fails to compile with JDK 1.6
> -
>
> Key: STORM-680
> URL: https://issues.apache.org/jira/browse/STORM-680
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-kafka
>Affects Versions: 0.10.0
>Reporter: jayapriya surendran
>Assignee: jayapriya surendran
>Priority: Minor
>  Labels: easyfix
>
> ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
> which is specific to JDK 7. 
> {code}
> public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
>   return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
> }
> {code}
> As per the comment in this commit 
> https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
> we should enforce JDK 1.7 as the minimum requirement for storm-kafka.
> Alternate fix is to change Long.compare() method to Long.compareTo() which is 
> compatible with JDK 1.6.



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

[GitHub] storm pull request: STORM-680: storm-kafka fails to compile with J...

[jayapriya90]

Github user jayapriya90 closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request: STORM-680: storm-kafka fails to compile with J...

[jayapriya90]

Github user jayapriya90 commented on the pull request:

https://github.com/apache/storm/pull/435#issuecomment-75030469
  
Closing pull request as it is duplicate of STORM-670. #431 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-680) storm-kafka fails to compile with JDK 1.6

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-680:
--

Github user jayapriya90 commented on the pull request:

https://github.com/apache/storm/pull/435#issuecomment-75030469
  
Closing pull request as it is duplicate of STORM-670. #431 


> storm-kafka fails to compile with JDK 1.6
> -
>
> Key: STORM-680
> URL: https://issues.apache.org/jira/browse/STORM-680
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-kafka
>Affects Versions: 0.10.0
>Reporter: jayapriya surendran
>Assignee: jayapriya surendran
>Priority: Minor
>  Labels: easyfix
>
> ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
> which is specific to JDK 7. 
> {code}
> public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
>   return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
> }
> {code}
> As per the comment in this commit 
> https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
> we should enforce JDK 1.7 as the minimum requirement for storm-kafka.
> Alternate fix is to change Long.compare() method to Long.compareTo() which is 
> compatible with JDK 1.6.



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

[jira] [Commented] (STORM-680) storm-kafka fails to compile with JDK 1.6

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-680:
--

Github user jayapriya90 closed the pull request at:

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


> storm-kafka fails to compile with JDK 1.6
> -
>
> Key: STORM-680
> URL: https://issues.apache.org/jira/browse/STORM-680
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-kafka
>Affects Versions: 0.10.0
>Reporter: jayapriya surendran
>Assignee: jayapriya surendran
>Priority: Minor
>  Labels: easyfix
>
> ExponentialBackoffMsgRetryManager.java uses Long.compare(long1, long2) method 
> which is specific to JDK 7. 
> {code}
> public int compare(MessageRetryRecord record1, MessageRetryRecord record2) {
>   return Long.compare(record1.retryTimeUTC, record2.retryTimeUTC);
> }
> {code}
> As per the comment in this commit 
> https://github.com/apache/storm/commit/fd066985a74c3140f61a465cfc49c83a6ddfa713
> we should enforce JDK 1.7 as the minimum requirement for storm-kafka.
> Alternate fix is to change Long.compare() method to Long.compareTo() which is 
> compatible with JDK 1.6.



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

[jira] [Commented] (STORM-677) Maximum retries strategy may cause data loss

[Michael Noll (JIRA)]

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

Michael Noll commented on STORM-677:


I will reply to the matter at hand in a separate comment.  For now I'd like to 
ask a question that may or may not be related to this issue:  How does a worker 
(or a Netty client) determine that it is actually connected to correct remote 
worker (Netty server)?  While debugging STORM-329 I noticed that under certain 
conditions (think: connection/restart race condition) a worker may end up 
connecting to the wrong remote worker.

> Maximum retries strategy may cause data loss
> 
>
> Key: STORM-677
> URL: https://issues.apache.org/jira/browse/STORM-677
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Michael Noll
>Priority: Minor
>  Labels: Netty
>
> h3. Background
> Storm currently supports the configuration setting 
> storm.messaging.netty.max_retries.  This setting is supposed to limit the 
> number of reconnection attempts a Netty client will perform in case of a 
> connection loss.
> Unfortunately users have run into situations where this behavior will result 
> in data loss:
> {quote}
> https://github.com/apache/storm/pull/429/files#r24681006
> This could be a separate JIRA, but we ran into a situation where we hit the 
> maximum number of reconnection attempts, and the exception was eaten because 
> it was thrown from a background thread and it just killed the background 
> thread. This code appears to do the same thing.
> {quote}
> The problem can be summarized by the following example:  Once a Netty client 
> hits the maximum number of connection retries, it will stop trying to 
> reconnect (as intended) but will also continue to run forever without being 
> able to send any messages to its designated remote targets.  At this point 
> data will be lost because any messages that the Netty client is supposed to 
> send will be dropped (by design).  And since the Netty client is still alive 
> and thus considered "functional", Storm is not able to do something about 
> this data loss situation.
> For a more detailed description please take a look at the discussion in 
> https://github.com/apache/storm/pull/429/files#r24742354.
> h3. Possible solutions
> (Most of this section is copy-pasted from an [earlier discussion on this 
> problem|https://github.com/apache/storm/pull/429/files#r24742354].)
> There are at least three approaches we may consider:
> # Let the Netty client die if max retries is reached, so that the Storm task 
> has the chance to re-create a client and thus break out of the client's 
> discard-messages-forever state.
> # Let the "parent" Storm task die if (one of its possibly many) Netty clients 
> dies, so that by restarting the task we'll also get a new Netty client.
> # Remove the max retries semantics as well as the corresponding setting from 
> Storm's configuration. Here, a Netty client will continue to reconnect to a 
> remote destination forever. The possible negative impact of these reconnects 
> (e.g. number of TCP connection attempts in a cluster) are kept in check by 
> our exponential backoff policy for such connection retries.
> My personal opinion on these three approaches:
> - I do not like (1) because I feel it introduces potentially confusing 
> semantics: We keep having a max retries setting, but it is not really a hard 
> limit anymore. It rather becomes a "max retries until we recreate a Netty 
> client", and would also reset any exponential backoff strategy of the 
> "previous" Netty client instance (cf. StormBoundedExponentialBackoffRetry). 
> If we do want such resets (but I don't think we do at this point), then a 
> cleaner approach would be to implement such resetting inside the retry policy 
> (again, cf. StormBoundedExponentialBackoffRetry).
> - I do not like (2) because a single "bad" Netty client would be able to take 
> down a Storm task, which among other things would also impact any other, 
> working Netty clients of the Storm task.
> - Option (3) seems a reasonable approach, although it breaks backwards 
> compatibility with regard to Storm's configuration (because we'd now ignore 
> storm.messaging.netty.max_retries).
> Here's initial feedback from other developers:
> {quote}
> https://github.com/apache/storm/pull/429/files#r24824540
> revans2: I personally prefer option 3, no maximum number of reconnection 
> attempts. Having the client decide that it is done, before nimbus does feels 
> like it is asking for trouble.
> {quote}
> {quote}
> https://github.com/ptgoetz
> ptgoetz: I'm in favor of option 3 as well. I'm not that concerned about 
> storm.messaging.netty.max_retries being ignored. We could probably just log a 
> warning tha

HdfsBolt and hdfs in HA mode

[clay teahouse]

Hi All,
Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
which hdfs node is the active node?

thanks
Clay

[jira] [Created] (STORM-681) Auto insert license header with genthrift.sh

[Kai Sasaki (JIRA)]

Kai Sasaki created STORM-681:


 Summary: Auto insert license header with genthrift.sh
 Key: STORM-681
 URL: https://issues.apache.org/jira/browse/STORM-681
 Project: Apache Storm
  Issue Type: Improvement
Affects Versions: 0.10.0, 0.9.3-rc2
Reporter: Kai Sasaki
Assignee: Kai Sasaki
Priority: Minor


Current genthrift.sh does not insert license headers into generated source 
codes. These java codes and python codes should have license headers. 
And documentation about this command.



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

[GitHub] storm pull request: [STORM-681] Auto insert license header with ge...

[Lewuathe]

GitHub user Lewuathe opened a pull request:

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

[STORM-681] Auto insert license header with genthrift.sh

Current genthrift.sh does not insert license headers into generated source 
codes. These java codes and python codes should have license headers. 
And documentation about this command.

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

$ git pull https://github.com/Lewuathe/storm auto-insert-license-declaration

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

https://github.com/apache/storm/pull/436.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #436


commit 0ba5bc1bea44414776efa97f3e66ba08e7384260
Author: lewuathe 
Date:   2015-02-19T13:13:08Z

[STORM-681] Auto insert license header with genthrift.sh




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-681) Auto insert license header with genthrift.sh

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-681:
--

GitHub user Lewuathe opened a pull request:

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

[STORM-681] Auto insert license header with genthrift.sh

Current genthrift.sh does not insert license headers into generated source 
codes. These java codes and python codes should have license headers. 
And documentation about this command.

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

$ git pull https://github.com/Lewuathe/storm auto-insert-license-declaration

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

https://github.com/apache/storm/pull/436.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #436


commit 0ba5bc1bea44414776efa97f3e66ba08e7384260
Author: lewuathe 
Date:   2015-02-19T13:13:08Z

[STORM-681] Auto insert license header with genthrift.sh




> Auto insert license header with genthrift.sh
> 
>
> Key: STORM-681
> URL: https://issues.apache.org/jira/browse/STORM-681
> Project: Apache Storm
>  Issue Type: Improvement
>Affects Versions: 0.10.0, 0.9.3-rc2
>Reporter: Kai Sasaki
>Assignee: Kai Sasaki
>Priority: Minor
>  Labels: documentaion, thrift
>
> Current genthrift.sh does not insert license headers into generated source 
> codes. These java codes and python codes should have license headers. 
> And documentation about this command.



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

Re: HdfsBolt and hdfs in HA mode

[Bobby Evans]

HDFS HA provides fail-over for the name node and the client determines which 
name node is the active one but should be completely transparent to you if the 
client is configured correctly.
 - Bobby
 

 On Thursday, February 19, 2015 6:47 AM, clay teahouse 
 wrote:
   

 Hi All,
Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
which hdfs node is the active node?

thanks
Clay


   

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Bobby Evans]

+1 - Bobby
 

 On Wednesday, February 18, 2015 3:47 PM, P. Taylor Goetz 
 wrote:
   

 As a follow-up to the previous discussion regarding adopting project bylaws, 
I’d like to start an official VOTE to formally adopt the bylaws as listed below.
Please vote on adopting the proposed bylaws.
[+1] Adopt the bylaws as listed[+0] No opinion[-1] Do not adopt the bylaws 
because…
This vote will be 2/3 Majority as described below, and open for 6 days.
-Taylor
-
# Apache Storm Project Bylaws


## Roles and Responsibilities

Apache projects define a set of roles with associated rights and 
responsibilities. These roles govern what tasks an individual may perform 
within the project. The roles are defined in the following sections:

### Users:

The most important participants in the project are people who use our software. 
The majority of our developers start out as users and guide their development 
efforts from the user's perspective.

Users contribute to the Apache projects by providing feedback to developers in 
the form of bug reports and feature suggestions. As well, users participate in 
the Apache community by helping other users on mailing lists and user support 
forums.

### Contributors:

Contributors are all of the volunteers who are contributing time, code, 
documentation, or resources to the Storm Project. A contributor that makes 
sustained, welcome contributions to the project may be invited to become a 
Committer, though the exact timing of such invitations depends on many factors.

### Committers:

The project's Committers are responsible for the project's technical 
management. Committers have access to all project source repositories. 
Committers may cast binding votes on any technical discussion regarding storm.

Committer access is by invitation only and must be approved by lazy consensus 
of the active PMC members. A Committer is considered emeritus by their own 
declaration or by not contributing in any form to the project for over six 
months. An emeritus Committer may request reinstatement of commit access from 
the PMC. Such reinstatement is subject to lazy consensus approval of active PMC 
members.

All Apache Committers are required to have a signed Contributor License 
Agreement (CLA) on file with the Apache Software Foundation. There is a 
[Committers' FAQ](https://www.apache.org/dev/committers.html) which provides 
more details on the requirements for Committers.

A Committer who makes a sustained contribution to the project may be invited to 
become a member of the PMC. The form of contribution is not limited to code. It 
can also include code review, helping out users on the mailing lists, 
documentation, testing, etc.

### Project Management Committee(PMC):

The PMC is responsible to the board and the ASF for the management and 
oversight of the Apache Storm codebase. The responsibilities of the PMC include:

 * Deciding what is distributed as products of the Apache Storm project. In 
particular all releases must be approved by the PMC.
 * Maintaining the project's shared resources, including the codebase 
repository, mailing lists, websites.
 * Speaking on behalf of the project.
 * Resolving license disputes regarding products of the project.
 * Nominating new PMC members and Committers.
 * Maintaining these bylaws and other guidelines of the project.

Membership of the PMC is by invitation only and must be approved by a consensus 
approval of active PMC members. A PMC member is considered "emeritus" by their 
own declaration or by not contributing in any form to the project for over six 
months. An emeritus member may request reinstatement to the PMC. Such 
reinstatement is subject to consensus approval of the active PMC members.

The chair of the PMC is appointed by the ASF board. The chair is an office 
holder of the Apache Software Foundation (Vice President, Apache Storm) and has 
primary responsibility to the board for the management of the projects within 
the scope of the Storm PMC. The chair reports to the board quarterly on 
developments within the Storm project.

The chair of the PMC is rotated annually. When the chair is rotated or if the 
current chair of the PMC resigns, the PMC votes to recommend a new chair using 
Single Transferable Vote (STV) voting. See 
http://wiki.apache.org/general/BoardVoting for specifics. The decision must be 
ratified by the Apache board.

## Voting

Decisions regarding the project are made by votes on the primary project 
development mailing list (dev@storm.apache.org). Where necessary, PMC voting 
may take place on the private Storm PMC mailing list. Votes are clearly 
indicated by subject line starting with [VOTE]. Votes may contain multiple 
items for approval and these should be clearly separated. Voting is carried out 
by replying to the vote mail. Voting may take four flavors:

| Vote | Meaning |
|--|-|
| +1 | 'Yes,' 'Agree,' or 'the action should be performed.' |
| +0 | Neutral a

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Andy Feng]

+1

Andy Feng

Sent from my iPhone

> On Feb 18, 2015, at 1:43 PM, P. Taylor Goetz  wrote:
> 
> As a follow-up to the previous discussion regarding adopting project bylaws, 
> I’d like to start an official VOTE to formally adopt the bylaws as listed 
> below.
> 
> Please vote on adopting the proposed bylaws.
> 
> [+1] Adopt the bylaws as listed
> [+0] No opinion
> [-1] Do not adopt the bylaws because…
> 
> This vote will be 2/3 Majority as described below, and open for 6 days.
> 
> -Taylor
> 
> -
> 
> # Apache Storm Project Bylaws
> 
> 
> ## Roles and Responsibilities
> 
> Apache projects define a set of roles with associated rights and 
> responsibilities. These roles govern what tasks an individual may perform 
> within the project. The roles are defined in the following sections:
> 
> ### Users:
> 
> The most important participants in the project are people who use our 
> software. The majority of our developers start out as users and guide their 
> development efforts from the user's perspective.
> 
> Users contribute to the Apache projects by providing feedback to developers 
> in the form of bug reports and feature suggestions. As well, users 
> participate in the Apache community by helping other users on mailing lists 
> and user support forums.
> 
> ### Contributors:
> 
> Contributors are all of the volunteers who are contributing time, code, 
> documentation, or resources to the Storm Project. A contributor that makes 
> sustained, welcome contributions to the project may be invited to become a 
> Committer, though the exact timing of such invitations depends on many 
> factors.
> 
> ### Committers:
> 
> The project's Committers are responsible for the project's technical 
> management. Committers have access to all project source repositories. 
> Committers may cast binding votes on any technical discussion regarding storm.
> 
> Committer access is by invitation only and must be approved by lazy consensus 
> of the active PMC members. A Committer is considered emeritus by their own 
> declaration or by not contributing in any form to the project for over six 
> months. An emeritus Committer may request reinstatement of commit access from 
> the PMC. Such reinstatement is subject to lazy consensus approval of active 
> PMC members.
> 
> All Apache Committers are required to have a signed Contributor License 
> Agreement (CLA) on file with the Apache Software Foundation. There is a 
> [Committers' FAQ](https://www.apache.org/dev/committers.html) which provides 
> more details on the requirements for Committers.
> 
> A Committer who makes a sustained contribution to the project may be invited 
> to become a member of the PMC. The form of contribution is not limited to 
> code. It can also include code review, helping out users on the mailing 
> lists, documentation, testing, etc.
> 
> ### Project Management Committee(PMC):
> 
> The PMC is responsible to the board and the ASF for the management and 
> oversight of the Apache Storm codebase. The responsibilities of the PMC 
> include:
> 
>  * Deciding what is distributed as products of the Apache Storm project. In 
> particular all releases must be approved by the PMC.
>  * Maintaining the project's shared resources, including the codebase 
> repository, mailing lists, websites.
>  * Speaking on behalf of the project.
>  * Resolving license disputes regarding products of the project.
>  * Nominating new PMC members and Committers.
>  * Maintaining these bylaws and other guidelines of the project.
> 
> Membership of the PMC is by invitation only and must be approved by a 
> consensus approval of active PMC members. A PMC member is considered 
> "emeritus" by their own declaration or by not contributing in any form to the 
> project for over six months. An emeritus member may request reinstatement to 
> the PMC. Such reinstatement is subject to consensus approval of the active 
> PMC members.
> 
> The chair of the PMC is appointed by the ASF board. The chair is an office 
> holder of the Apache Software Foundation (Vice President, Apache Storm) and 
> has primary responsibility to the board for the management of the projects 
> within the scope of the Storm PMC. The chair reports to the board quarterly 
> on developments within the Storm project.
> 
> The chair of the PMC is rotated annually. When the chair is rotated or if the 
> current chair of the PMC resigns, the PMC votes to recommend a new chair 
> using Single Transferable Vote (STV) voting. See 
> http://wiki.apache.org/general/BoardVoting for specifics. The decision must 
> be ratified by the Apache board.
> 
> ## Voting
> 
> Decisions regarding the project are made by votes on the primary project 
> development mailing list (dev@storm.apache.org). Where necessary, PMC voting 
> may take place on the private Storm PMC mailing list. Votes are clearly 
> indicated by subject line starting with [VOTE]. Votes may contain multiple 
> items for approval and these should 

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Nathan Marz]

+1

On Thu, Feb 19, 2015 at 8:15 AM, Andy Feng  wrote:

> +1
>
> Andy Feng
>
> Sent from my iPhone
>
> > On Feb 18, 2015, at 1:43 PM, P. Taylor Goetz  wrote:
> >
> > As a follow-up to the previous discussion regarding adopting project
> bylaws, I’d like to start an official VOTE to formally adopt the bylaws as
> listed below.
> >
> > Please vote on adopting the proposed bylaws.
> >
> > [+1] Adopt the bylaws as listed
> > [+0] No opinion
> > [-1] Do not adopt the bylaws because…
> >
> > This vote will be 2/3 Majority as described below, and open for 6 days.
> >
> > -Taylor
> >
> > -
> >
> > # Apache Storm Project Bylaws
> >
> >
> > ## Roles and Responsibilities
> >
> > Apache projects define a set of roles with associated rights and
> responsibilities. These roles govern what tasks an individual may perform
> within the project. The roles are defined in the following sections:
> >
> > ### Users:
> >
> > The most important participants in the project are people who use our
> software. The majority of our developers start out as users and guide their
> development efforts from the user's perspective.
> >
> > Users contribute to the Apache projects by providing feedback to
> developers in the form of bug reports and feature suggestions. As well,
> users participate in the Apache community by helping other users on mailing
> lists and user support forums.
> >
> > ### Contributors:
> >
> > Contributors are all of the volunteers who are contributing time, code,
> documentation, or resources to the Storm Project. A contributor that makes
> sustained, welcome contributions to the project may be invited to become a
> Committer, though the exact timing of such invitations depends on many
> factors.
> >
> > ### Committers:
> >
> > The project's Committers are responsible for the project's technical
> management. Committers have access to all project source repositories.
> Committers may cast binding votes on any technical discussion regarding
> storm.
> >
> > Committer access is by invitation only and must be approved by lazy
> consensus of the active PMC members. A Committer is considered emeritus by
> their own declaration or by not contributing in any form to the project for
> over six months. An emeritus Committer may request reinstatement of commit
> access from the PMC. Such reinstatement is subject to lazy consensus
> approval of active PMC members.
> >
> > All Apache Committers are required to have a signed Contributor License
> Agreement (CLA) on file with the Apache Software Foundation. There is a
> [Committers' FAQ](https://www.apache.org/dev/committers.html) which
> provides more details on the requirements for Committers.
> >
> > A Committer who makes a sustained contribution to the project may be
> invited to become a member of the PMC. The form of contribution is not
> limited to code. It can also include code review, helping out users on the
> mailing lists, documentation, testing, etc.
> >
> > ### Project Management Committee(PMC):
> >
> > The PMC is responsible to the board and the ASF for the management and
> oversight of the Apache Storm codebase. The responsibilities of the PMC
> include:
> >
> >  * Deciding what is distributed as products of the Apache Storm project.
> In particular all releases must be approved by the PMC.
> >  * Maintaining the project's shared resources, including the codebase
> repository, mailing lists, websites.
> >  * Speaking on behalf of the project.
> >  * Resolving license disputes regarding products of the project.
> >  * Nominating new PMC members and Committers.
> >  * Maintaining these bylaws and other guidelines of the project.
> >
> > Membership of the PMC is by invitation only and must be approved by a
> consensus approval of active PMC members. A PMC member is considered
> "emeritus" by their own declaration or by not contributing in any form to
> the project for over six months. An emeritus member may request
> reinstatement to the PMC. Such reinstatement is subject to consensus
> approval of the active PMC members.
> >
> > The chair of the PMC is appointed by the ASF board. The chair is an
> office holder of the Apache Software Foundation (Vice President, Apache
> Storm) and has primary responsibility to the board for the management of
> the projects within the scope of the Storm PMC. The chair reports to the
> board quarterly on developments within the Storm project.
> >
> > The chair of the PMC is rotated annually. When the chair is rotated or
> if the current chair of the PMC resigns, the PMC votes to recommend a new
> chair using Single Transferable Vote (STV) voting. See
> http://wiki.apache.org/general/BoardVoting for specifics. The decision
> must be ratified by the Apache board.
> >
> > ## Voting
> >
> > Decisions regarding the project are made by votes on the primary project
> development mailing list (dev@storm.apache.org). Where necessary, PMC
> voting may take place on the private Storm PMC mailing list. Votes are
> cle

[jira] [Commented] (STORM-677) Maximum retries strategy may cause data loss

[Nathan Marz (JIRA)]

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

Nathan Marz commented on STORM-677:
---

Option 2 doesn't have to be long term as it should be easy to implement. I do 
not view the options as looking very similar as I think Option 2 will be 
significantly more robust – getting out of a weird state as fast as possible is 
really important.

"If that itself can cause other workers to give up on a connection it could 
result in the topology never reaching a stable state." –> This is exactly why 
the amount of time attempting to make a connection must be related to the start 
timeout for a worker. 

> Maximum retries strategy may cause data loss
> 
>
> Key: STORM-677
> URL: https://issues.apache.org/jira/browse/STORM-677
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Michael Noll
>Priority: Minor
>  Labels: Netty
>
> h3. Background
> Storm currently supports the configuration setting 
> storm.messaging.netty.max_retries.  This setting is supposed to limit the 
> number of reconnection attempts a Netty client will perform in case of a 
> connection loss.
> Unfortunately users have run into situations where this behavior will result 
> in data loss:
> {quote}
> https://github.com/apache/storm/pull/429/files#r24681006
> This could be a separate JIRA, but we ran into a situation where we hit the 
> maximum number of reconnection attempts, and the exception was eaten because 
> it was thrown from a background thread and it just killed the background 
> thread. This code appears to do the same thing.
> {quote}
> The problem can be summarized by the following example:  Once a Netty client 
> hits the maximum number of connection retries, it will stop trying to 
> reconnect (as intended) but will also continue to run forever without being 
> able to send any messages to its designated remote targets.  At this point 
> data will be lost because any messages that the Netty client is supposed to 
> send will be dropped (by design).  And since the Netty client is still alive 
> and thus considered "functional", Storm is not able to do something about 
> this data loss situation.
> For a more detailed description please take a look at the discussion in 
> https://github.com/apache/storm/pull/429/files#r24742354.
> h3. Possible solutions
> (Most of this section is copy-pasted from an [earlier discussion on this 
> problem|https://github.com/apache/storm/pull/429/files#r24742354].)
> There are at least three approaches we may consider:
> # Let the Netty client die if max retries is reached, so that the Storm task 
> has the chance to re-create a client and thus break out of the client's 
> discard-messages-forever state.
> # Let the "parent" Storm task die if (one of its possibly many) Netty clients 
> dies, so that by restarting the task we'll also get a new Netty client.
> # Remove the max retries semantics as well as the corresponding setting from 
> Storm's configuration. Here, a Netty client will continue to reconnect to a 
> remote destination forever. The possible negative impact of these reconnects 
> (e.g. number of TCP connection attempts in a cluster) are kept in check by 
> our exponential backoff policy for such connection retries.
> My personal opinion on these three approaches:
> - I do not like (1) because I feel it introduces potentially confusing 
> semantics: We keep having a max retries setting, but it is not really a hard 
> limit anymore. It rather becomes a "max retries until we recreate a Netty 
> client", and would also reset any exponential backoff strategy of the 
> "previous" Netty client instance (cf. StormBoundedExponentialBackoffRetry). 
> If we do want such resets (but I don't think we do at this point), then a 
> cleaner approach would be to implement such resetting inside the retry policy 
> (again, cf. StormBoundedExponentialBackoffRetry).
> - I do not like (2) because a single "bad" Netty client would be able to take 
> down a Storm task, which among other things would also impact any other, 
> working Netty clients of the Storm task.
> - Option (3) seems a reasonable approach, although it breaks backwards 
> compatibility with regard to Storm's configuration (because we'd now ignore 
> storm.messaging.netty.max_retries).
> Here's initial feedback from other developers:
> {quote}
> https://github.com/apache/storm/pull/429/files#r24824540
> revans2: I personally prefer option 3, no maximum number of reconnection 
> attempts. Having the client decide that it is done, before nimbus does feels 
> like it is asking for trouble.
> {quote}
> {quote}
> https://github.com/ptgoetz
> ptgoetz: I'm in favor of option 3 as well. I'm not that concerned about 
> storm.messaging

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Melan Nimesh]

+1

On Thu, Feb 19, 2015 at 9:08 PM, Nathan Marz  wrote:

> +1
>
> On Thu, Feb 19, 2015 at 8:15 AM, Andy Feng  wrote:
>
> > +1
> >
> > Andy Feng
> >
> > Sent from my iPhone
> >
> > > On Feb 18, 2015, at 1:43 PM, P. Taylor Goetz 
> wrote:
> > >
> > > As a follow-up to the previous discussion regarding adopting project
> > bylaws, I’d like to start an official VOTE to formally adopt the bylaws
> as
> > listed below.
> > >
> > > Please vote on adopting the proposed bylaws.
> > >
> > > [+1] Adopt the bylaws as listed
> > > [+0] No opinion
> > > [-1] Do not adopt the bylaws because…
> > >
> > > This vote will be 2/3 Majority as described below, and open for 6 days.
> > >
> > > -Taylor
> > >
> > > -
> > >
> > > # Apache Storm Project Bylaws
> > >
> > >
> > > ## Roles and Responsibilities
> > >
> > > Apache projects define a set of roles with associated rights and
> > responsibilities. These roles govern what tasks an individual may perform
> > within the project. The roles are defined in the following sections:
> > >
> > > ### Users:
> > >
> > > The most important participants in the project are people who use our
> > software. The majority of our developers start out as users and guide
> their
> > development efforts from the user's perspective.
> > >
> > > Users contribute to the Apache projects by providing feedback to
> > developers in the form of bug reports and feature suggestions. As well,
> > users participate in the Apache community by helping other users on
> mailing
> > lists and user support forums.
> > >
> > > ### Contributors:
> > >
> > > Contributors are all of the volunteers who are contributing time, code,
> > documentation, or resources to the Storm Project. A contributor that
> makes
> > sustained, welcome contributions to the project may be invited to become
> a
> > Committer, though the exact timing of such invitations depends on many
> > factors.
> > >
> > > ### Committers:
> > >
> > > The project's Committers are responsible for the project's technical
> > management. Committers have access to all project source repositories.
> > Committers may cast binding votes on any technical discussion regarding
> > storm.
> > >
> > > Committer access is by invitation only and must be approved by lazy
> > consensus of the active PMC members. A Committer is considered emeritus
> by
> > their own declaration or by not contributing in any form to the project
> for
> > over six months. An emeritus Committer may request reinstatement of
> commit
> > access from the PMC. Such reinstatement is subject to lazy consensus
> > approval of active PMC members.
> > >
> > > All Apache Committers are required to have a signed Contributor License
> > Agreement (CLA) on file with the Apache Software Foundation. There is a
> > [Committers' FAQ](https://www.apache.org/dev/committers.html) which
> > provides more details on the requirements for Committers.
> > >
> > > A Committer who makes a sustained contribution to the project may be
> > invited to become a member of the PMC. The form of contribution is not
> > limited to code. It can also include code review, helping out users on
> the
> > mailing lists, documentation, testing, etc.
> > >
> > > ### Project Management Committee(PMC):
> > >
> > > The PMC is responsible to the board and the ASF for the management and
> > oversight of the Apache Storm codebase. The responsibilities of the PMC
> > include:
> > >
> > >  * Deciding what is distributed as products of the Apache Storm
> project.
> > In particular all releases must be approved by the PMC.
> > >  * Maintaining the project's shared resources, including the codebase
> > repository, mailing lists, websites.
> > >  * Speaking on behalf of the project.
> > >  * Resolving license disputes regarding products of the project.
> > >  * Nominating new PMC members and Committers.
> > >  * Maintaining these bylaws and other guidelines of the project.
> > >
> > > Membership of the PMC is by invitation only and must be approved by a
> > consensus approval of active PMC members. A PMC member is considered
> > "emeritus" by their own declaration or by not contributing in any form to
> > the project for over six months. An emeritus member may request
> > reinstatement to the PMC. Such reinstatement is subject to consensus
> > approval of the active PMC members.
> > >
> > > The chair of the PMC is appointed by the ASF board. The chair is an
> > office holder of the Apache Software Foundation (Vice President, Apache
> > Storm) and has primary responsibility to the board for the management of
> > the projects within the scope of the Storm PMC. The chair reports to the
> > board quarterly on developments within the Storm project.
> > >
> > > The chair of the PMC is rotated annually. When the chair is rotated or
> > if the current chair of the PMC resigns, the PMC votes to recommend a new
> > chair using Single Transferable Vote (STV) voting. See
> > http://wiki.apache.org/general/BoardVoting for specifics. 

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Harsha]

+1
-Harsha

On Thu, Feb 19, 2015, at 07:48 AM, Melan Nimesh wrote:
> +1
> 
> On Thu, Feb 19, 2015 at 9:08 PM, Nathan Marz 
> wrote:
> 
> > +1
> >
> > On Thu, Feb 19, 2015 at 8:15 AM, Andy Feng  wrote:
> >
> > > +1
> > >
> > > Andy Feng
> > >
> > > Sent from my iPhone
> > >
> > > > On Feb 18, 2015, at 1:43 PM, P. Taylor Goetz 
> > wrote:
> > > >
> > > > As a follow-up to the previous discussion regarding adopting project
> > > bylaws, I’d like to start an official VOTE to formally adopt the bylaws
> > as
> > > listed below.
> > > >
> > > > Please vote on adopting the proposed bylaws.
> > > >
> > > > [+1] Adopt the bylaws as listed
> > > > [+0] No opinion
> > > > [-1] Do not adopt the bylaws because…
> > > >
> > > > This vote will be 2/3 Majority as described below, and open for 6 days.
> > > >
> > > > -Taylor
> > > >
> > > > -
> > > >
> > > > # Apache Storm Project Bylaws
> > > >
> > > >
> > > > ## Roles and Responsibilities
> > > >
> > > > Apache projects define a set of roles with associated rights and
> > > responsibilities. These roles govern what tasks an individual may perform
> > > within the project. The roles are defined in the following sections:
> > > >
> > > > ### Users:
> > > >
> > > > The most important participants in the project are people who use our
> > > software. The majority of our developers start out as users and guide
> > their
> > > development efforts from the user's perspective.
> > > >
> > > > Users contribute to the Apache projects by providing feedback to
> > > developers in the form of bug reports and feature suggestions. As well,
> > > users participate in the Apache community by helping other users on
> > mailing
> > > lists and user support forums.
> > > >
> > > > ### Contributors:
> > > >
> > > > Contributors are all of the volunteers who are contributing time, code,
> > > documentation, or resources to the Storm Project. A contributor that
> > makes
> > > sustained, welcome contributions to the project may be invited to become
> > a
> > > Committer, though the exact timing of such invitations depends on many
> > > factors.
> > > >
> > > > ### Committers:
> > > >
> > > > The project's Committers are responsible for the project's technical
> > > management. Committers have access to all project source repositories.
> > > Committers may cast binding votes on any technical discussion regarding
> > > storm.
> > > >
> > > > Committer access is by invitation only and must be approved by lazy
> > > consensus of the active PMC members. A Committer is considered emeritus
> > by
> > > their own declaration or by not contributing in any form to the project
> > for
> > > over six months. An emeritus Committer may request reinstatement of
> > commit
> > > access from the PMC. Such reinstatement is subject to lazy consensus
> > > approval of active PMC members.
> > > >
> > > > All Apache Committers are required to have a signed Contributor License
> > > Agreement (CLA) on file with the Apache Software Foundation. There is a
> > > [Committers' FAQ](https://www.apache.org/dev/committers.html) which
> > > provides more details on the requirements for Committers.
> > > >
> > > > A Committer who makes a sustained contribution to the project may be
> > > invited to become a member of the PMC. The form of contribution is not
> > > limited to code. It can also include code review, helping out users on
> > the
> > > mailing lists, documentation, testing, etc.
> > > >
> > > > ### Project Management Committee(PMC):
> > > >
> > > > The PMC is responsible to the board and the ASF for the management and
> > > oversight of the Apache Storm codebase. The responsibilities of the PMC
> > > include:
> > > >
> > > >  * Deciding what is distributed as products of the Apache Storm
> > project.
> > > In particular all releases must be approved by the PMC.
> > > >  * Maintaining the project's shared resources, including the codebase
> > > repository, mailing lists, websites.
> > > >  * Speaking on behalf of the project.
> > > >  * Resolving license disputes regarding products of the project.
> > > >  * Nominating new PMC members and Committers.
> > > >  * Maintaining these bylaws and other guidelines of the project.
> > > >
> > > > Membership of the PMC is by invitation only and must be approved by a
> > > consensus approval of active PMC members. A PMC member is considered
> > > "emeritus" by their own declaration or by not contributing in any form to
> > > the project for over six months. An emeritus member may request
> > > reinstatement to the PMC. Such reinstatement is subject to consensus
> > > approval of the active PMC members.
> > > >
> > > > The chair of the PMC is appointed by the ASF board. The chair is an
> > > office holder of the Apache Software Foundation (Vice President, Apache
> > > Storm) and has primary responsibility to the board for the management of
> > > the projects within the scope of the Storm PMC. The chair reports to the
> > > board quarterly on developm

[jira] [Commented] (STORM-677) Maximum retries strategy may cause data loss

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans commented on STORM-677:
---

Periodically, every 10 seconds at least, the current compiled topology is 
downloaded, if it changed, by all workers from zookeeper and the 
routing/connections are updated.  Connections not needed any longer are closed, 
and new connections are created.  If a worker receives any tuples that are not 
for it, they are discarded and an error message is logged.  If a connection is 
to the wrong worker, in my experience, it has always been because workers were 
reassigned and the remote supervisor launched new workers faster then the 
current worker could update the routing.  This is also why it is important that 
the send method in the client not bock, because of the way locking is handled 
in storm if it does block, it can block the routing/connections from being 
updated and incorrect connections can persist longer than the typical 10 second 
maximum.

Also secure versions of storm optionally use SASL when creating connections, so 
any connection to a worker of a different topology will never be established in 
the first place.

> Maximum retries strategy may cause data loss
> 
>
> Key: STORM-677
> URL: https://issues.apache.org/jira/browse/STORM-677
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.9.3, 0.10.0
>Reporter: Michael Noll
>Priority: Minor
>  Labels: Netty
>
> h3. Background
> Storm currently supports the configuration setting 
> storm.messaging.netty.max_retries.  This setting is supposed to limit the 
> number of reconnection attempts a Netty client will perform in case of a 
> connection loss.
> Unfortunately users have run into situations where this behavior will result 
> in data loss:
> {quote}
> https://github.com/apache/storm/pull/429/files#r24681006
> This could be a separate JIRA, but we ran into a situation where we hit the 
> maximum number of reconnection attempts, and the exception was eaten because 
> it was thrown from a background thread and it just killed the background 
> thread. This code appears to do the same thing.
> {quote}
> The problem can be summarized by the following example:  Once a Netty client 
> hits the maximum number of connection retries, it will stop trying to 
> reconnect (as intended) but will also continue to run forever without being 
> able to send any messages to its designated remote targets.  At this point 
> data will be lost because any messages that the Netty client is supposed to 
> send will be dropped (by design).  And since the Netty client is still alive 
> and thus considered "functional", Storm is not able to do something about 
> this data loss situation.
> For a more detailed description please take a look at the discussion in 
> https://github.com/apache/storm/pull/429/files#r24742354.
> h3. Possible solutions
> (Most of this section is copy-pasted from an [earlier discussion on this 
> problem|https://github.com/apache/storm/pull/429/files#r24742354].)
> There are at least three approaches we may consider:
> # Let the Netty client die if max retries is reached, so that the Storm task 
> has the chance to re-create a client and thus break out of the client's 
> discard-messages-forever state.
> # Let the "parent" Storm task die if (one of its possibly many) Netty clients 
> dies, so that by restarting the task we'll also get a new Netty client.
> # Remove the max retries semantics as well as the corresponding setting from 
> Storm's configuration. Here, a Netty client will continue to reconnect to a 
> remote destination forever. The possible negative impact of these reconnects 
> (e.g. number of TCP connection attempts in a cluster) are kept in check by 
> our exponential backoff policy for such connection retries.
> My personal opinion on these three approaches:
> - I do not like (1) because I feel it introduces potentially confusing 
> semantics: We keep having a max retries setting, but it is not really a hard 
> limit anymore. It rather becomes a "max retries until we recreate a Netty 
> client", and would also reset any exponential backoff strategy of the 
> "previous" Netty client instance (cf. StormBoundedExponentialBackoffRetry). 
> If we do want such resets (but I don't think we do at this point), then a 
> cleaner approach would be to implement such resetting inside the retry policy 
> (again, cf. StormBoundedExponentialBackoffRetry).
> - I do not like (2) because a single "bad" Netty client would be able to take 
> down a Storm task, which among other things would also impact any other, 
> working Netty clients of the Storm task.
> - Option (3) seems a reasonable approach, although it breaks backwards 
> compatibility wit

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Derek Dagit]

+1
-- 
Derek 




From: P. Taylor Goetz 
To: dev@storm.apache.org 
Sent: Wednesday, February 18, 2015 3:43 PM
Subject: [VOTE] Adopt Apache Storm Project Bylaws



As a follow-up to the previous discussion regarding adopting project bylaws, 
I’d like to start an official VOTE to formally adopt the bylaws as listed below.

Please vote on adopting the proposed bylaws.

[+1] Adopt the bylaws as listed
[+0] No opinion
[-1] Do not adopt the bylaws because…

This vote will be 2/3 Majority as described below, and open for 6 days.

-Taylor

-

# Apache Storm Project Bylaws ## Roles and Responsibilities Apache projects 
define a set of roles with associated rights and responsibilities. These roles 
govern what tasks an individual may perform within the project. The roles are 
defined in the following sections: ### Users: The most important participants 
in the project are people who use our software. The majority of our developers 
start out as users and guide their development efforts from the user's 
perspective. Users contribute to the Apache projects by providing feedback to 
developers in the form of bug reports and feature suggestions. As well, users 
participate in the Apache community by helping other users on mailing lists and 
user support forums. ### Contributors: Contributors are all of the volunteers 
who are contributing time, code, documentation, or resources to the Storm 
Project. A contributor that makes sustained, welcome contributions to the 
project may be invited to become a Committer, though the exact timing of such 
invitations depends on many factors. ### Committers: The project's Committers 
are responsible for the project's technical management. Committers have access 
to all project source repositories. Committers may cast binding votes on any 
technical discussion regarding storm. Committer access is by invitation only 
and must be approved by lazy consensus of the active PMC members. A Committer 
is considered emeritus by their own declaration or by not contributing in any 
form to the project for over six months. An emeritus Committer may request 
reinstatement of commit access from the PMC. Such reinstatement is subject to 
lazy consensus approval of active PMC members. All Apache Committers are 
required to have a signed Contributor License Agreement (CLA) on file with the 
Apache Software Foundation. There is a [Committers' 
FAQ](https://www.apache.org/dev/committers.html) which provides more details on 
the requirements for Committers. A Committer who makes a sustained contribution 
to the project may be invited to become a member of the PMC. The form of 
contribution is not limited to code. It can also include code review, helping 
out users on the mailing lists, documentation, testing, etc. ### Project 
Management Committee(PMC): The PMC is responsible to the board and the ASF for 
the management and oversight of the Apache Storm codebase. The responsibilities 
of the PMC include: * Deciding what is distributed as products of the Apache 
Storm project. In particular all releases must be approved by the PMC. * 
Maintaining the project's shared resources, including the codebase repository, 
mailing lists, websites. * Speaking on behalf of the project. * Resolving 
license disputes regarding products of the project. * Nominating new PMC 
members and Committers. * Maintaining these bylaws and other guidelines of the 
project. Membership of the PMC is by invitation only and must be approved by a 
consensus approval of active PMC members. A PMC member is considered "emeritus" 
by their own declaration or by not contributing in any form to the project for 
over six months. An emeritus member may request reinstatement to the PMC. Such 
reinstatement is subject to consensus approval of the active PMC members. The 
chair of the PMC is appointed by the ASF board. The chair is an office holder 
of the Apache Software Foundation (Vice President, Apache Storm) and has 
primary responsibility to the board for the management of the projects within 
the scope of the Storm PMC. The chair reports to the board quarterly on 
developments within the Storm project. The chair of the PMC is rotated 
annually. When the chair is rotated or if the current chair of the PMC resigns, 
the PMC votes to recommend a new chair using Single Transferable Vote (STV) 
voting. See http://wiki.apache.org/general/BoardVoting for specifics. The 
decision must be ratified by the Apache board. ## Voting Decisions regarding 
the project are made by votes on the primary project development mailing list 
(dev@storm.apache.org). Where necessary, PMC voting may take place on the 
private Storm PMC mailing list. Votes are clearly indicated by subject line 
starting with [VOTE]. Votes may contain multiple items for approval and these 
should be clearly separated. Voting is carried out by replying to the vote 
mail. Voting may take four flavors: | Vote | Meaning |
|--|-

Re: HdfsBolt and hdfs in HA mode

[clay teahouse]

Bobby,
What do you mean by client here? In this context, do you consider hdfsbolt
a client? If yes, then which configuration you are referring to? I've seen
the following, but I am not sure if I follow.


   - *dfs.client.failover.proxy.provider.[nameservice ID]* - the Java class
   that HDFS clients use to contact the Active NameNode

   Configure the name of the Java class which will be used by the DFS
   Client to determine which NameNode is the current Active, and therefore
   which NameNode is currently serving client requests. The only
   implementation which currently ships with Hadoop is the
   *ConfiguredFailoverProxyProvider*, so use this unless you are using a
   custom one. For example:

   
 dfs.client.failover.proxy.provider.mycluster
 
org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
   


thanks,
Clay


On Thu, Feb 19, 2015 at 8:38 AM, Bobby Evans 
wrote:

> HDFS HA provides fail-over for the name node and the client determines
> which name node is the active one but should be completely transparent to
> you if the client is configured correctly.
>  - Bobby
>
>
>  On Thursday, February 19, 2015 6:47 AM, clay teahouse <
> clayteaho...@gmail.com> wrote:
>
>
>  Hi All,
> Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
> which hdfs node is the active node?
>
> thanks
> Clay
>
>
>
>

Re: HdfsBolt and hdfs in HA mode

[Bobby Evans]

Hadoop has lots of different configurations in core-site.xml, hdfs-site.xml, 
... all of which eventually get loaded into the Configuration object used to 
create a FileSystem instance.  There are so many different configurations 
related to security, HA, etc. that it is almost impossible for me to guess 
exactly which ones you need to have set correctly to make this work.  Typically 
what we do for storm to be able to talk to HDFS is to package the complete set 
of configs that appear on a Hadoop Gateway with the topology jar when it is 
shipped.  This guarantees that the config is the same as on the gateway and 
should behave the same way.  You can also grab them from the name node or any 
of the hadoop compute nodes. 
 This will work for the HdfsBolt that loads default configurations from the 
classpath before overriding them with any custom configurations you set for 
that bolt.

- Bobby
 

 On Thursday, February 19, 2015 10:42 AM, clay teahouse 
 wrote:
   

 Bobby,What do you mean by client here? In this context, do you consider 
hdfsbolt a client? If yes, then which configuration you are referring to? I've 
seen the following, but I am not sure if I follow.
   
   - dfs.client.failover.proxy.provider.[nameservice ID] - the Java class that 
HDFS clients use to contact the Active NameNodeConfigure the name of the Java 
class which will be used by the DFS Client to determine which NameNode is the 
current Active, and therefore which NameNode is currently serving client 
requests. The only implementation which currently ships with Hadoop is the 
ConfiguredFailoverProxyProvider, so use this unless you are using a custom one. 
For example:   
  dfs.client.failover.proxy.provider.mycluster
  
org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider

thanks,Clay

On Thu, Feb 19, 2015 at 8:38 AM, Bobby Evans  
wrote:

HDFS HA provides fail-over for the name node and the client determines which 
name node is the active one but should be completely transparent to you if the 
client is configured correctly.
 - Bobby


     On Thursday, February 19, 2015 6:47 AM, clay teahouse 
 wrote:


 Hi All,
Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
which hdfs node is the active node?

thanks
Clay


   



   

Re: HdfsBolt and hdfs in HA mode

[Parth Brahmbhatt]

Following links should help
http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.1.1/bk_user-guide/conte
nt/ch_storm-using-hdfs-connector.html
http://docs.hortonworks.com/HDPDocuments/HDP2/HDP-2.1.1/bk_user-guide/conte
nt/ch_storm-using-packaging-topologies.html

Thanks
Parth

On 2/19/15, 8:58 AM, "Bobby Evans"  wrote:

>Hadoop has lots of different configurations in core-site.xml,
>hdfs-site.xml, ... all of which eventually get loaded into the
>Configuration object used to create a FileSystem instance.  There are so
>many different configurations related to security, HA, etc. that it is
>almost impossible for me to guess exactly which ones you need to have set
>correctly to make this work.  Typically what we do for storm to be able
>to talk to HDFS is to package the complete set of configs that appear on
>a Hadoop Gateway with the topology jar when it is shipped.  This
>guarantees that the config is the same as on the gateway and should
>behave the same way.  You can also grab them from the name node or any of
>the hadoop compute nodes.
> This will work for the HdfsBolt that loads default configurations from
>the classpath before overriding them with any custom configurations you
>set for that bolt.
>
>- Bobby
> 
>
> On Thursday, February 19, 2015 10:42 AM, clay teahouse
> wrote:
>   
>
> Bobby,What do you mean by client here? In this context, do you consider
>hdfsbolt a client? If yes, then which configuration you are referring to?
>I've seen the following, but I am not sure if I follow.
>   
>   - dfs.client.failover.proxy.provider.[nameservice ID] - the Java class
>that HDFS clients use to contact the Active NameNodeConfigure the name of
>the Java class which will be used by the DFS Client to determine which
>NameNode is the current Active, and therefore which NameNode is currently
>serving client requests. The only implementation which currently ships
>with Hadoop is the ConfiguredFailoverProxyProvider, so use this unless
>you are using a custom one. For example:   
>  dfs.client.failover.proxy.provider.mycluster
>  
>org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyPr
>ovider
>
>thanks,Clay
>
>On Thu, Feb 19, 2015 at 8:38 AM, Bobby Evans
> wrote:
>
>HDFS HA provides fail-over for the name node and the client determines
>which name node is the active one but should be completely transparent to
>you if the client is configured correctly.
> - Bobby
>
>
> On Thursday, February 19, 2015 6:47 AM, clay teahouse
> wrote:
>
>
> Hi All,
>Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
>which hdfs node is the active node?
>
>thanks
>Clay
>
>
>   
>
>
>
>   

Re: HdfsBolt and hdfs in HA mode

[Harsha]

Clay,
 When you are using storm-hdfs connector you need to package
 core-site.xml and hdfs-site.xml form you cluster into your topology
 jar . You can configure the storm-hdfs bolt to pass nameserviceID

HdfsBolt bolt = new HdfsBolt()
   .withFsURL("hdfs://myNameserviceID")
   .withFileNameFormat(fileNameformat)
   .withRecordFormat(format)
   .withRotationPolicy(rotationPolicy)
   .withSynPolicy(syncPolicy);

The above is all that needed to use namenode HA with your storm-hdfs. 

-Harsha

On Thu, Feb 19, 2015, at 08:58 AM, Bobby Evans wrote:
> Hadoop has lots of different configurations in core-site.xml,
> hdfs-site.xml, ... all of which eventually get loaded into the
> Configuration object used to create a FileSystem instance.  There are so
> many different configurations related to security, HA, etc. that it is
> almost impossible for me to guess exactly which ones you need to have set
> correctly to make this work.  Typically what we do for storm to be able
> to talk to HDFS is to package the complete set of configs that appear on
> a Hadoop Gateway with the topology jar when it is shipped.  This
> guarantees that the config is the same as on the gateway and should
> behave the same way.  You can also grab them from the name node or any of
> the hadoop compute nodes. 
>  This will work for the HdfsBolt that loads default configurations from the 
> classpath before overriding them with any custom configurations you set for 
> that bolt.
> 
> - Bobby
>  
> 
>  On Thursday, February 19, 2015 10:42 AM, clay teahouse
>   wrote:
>
> 
>  Bobby,What do you mean by client here? In this context, do you consider
>  hdfsbolt a client? If yes, then which configuration you are referring
>  to? I've seen the following, but I am not sure if I follow.
>
>- dfs.client.failover.proxy.provider.[nameservice ID] - the Java class
>that HDFS clients use to contact the Active NameNodeConfigure the name
>of the Java class which will be used by the DFS Client to determine
>which NameNode is the current Active, and therefore which NameNode is
>currently serving client requests. The only implementation which
>currently ships with Hadoop is the ConfiguredFailoverProxyProvider, so
>use this unless you are using a custom one. For example:   
>   dfs.client.failover.proxy.provider.mycluster
>   
> org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
> 
> thanks,Clay
> 
> On Thu, Feb 19, 2015 at 8:38 AM, Bobby Evans
>  wrote:
> 
> HDFS HA provides fail-over for the name node and the client determines
> which name node is the active one but should be completely transparent to
> you if the client is configured correctly.
>  - Bobby
> 
> 
>      On Thursday, February 19, 2015 6:47 AM, clay teahouse 
>  wrote:
> 
> 
>  Hi All,
> Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
> which hdfs node is the active node?
> 
> thanks
> Clay
> 
> 
>    
> 
> 
> 
>

Re: [VOTE] Adopt Apache Storm Project Bylaws

[P. Taylor Goetz]

+1

-Taylor

On Feb 18, 2015, at 4:43 PM, P. Taylor Goetz  wrote:

> As a follow-up to the previous discussion regarding adopting project bylaws, 
> I’d like to start an official VOTE to formally adopt the bylaws as listed 
> below.
> 
> Please vote on adopting the proposed bylaws.
> 
> [+1] Adopt the bylaws as listed
> [+0] No opinion
> [-1] Do not adopt the bylaws because…
> 
> This vote will be 2/3 Majority as described below, and open for 6 days.
> 
> -Taylor
> 
> -
> 
> # Apache Storm Project Bylaws
> 
> 
> ## Roles and Responsibilities
> 
> Apache projects define a set of roles with associated rights and 
> responsibilities. These roles govern what tasks an individual may perform 
> within the project. The roles are defined in the following sections:
> 
> ### Users:
> 
> The most important participants in the project are people who use our 
> software. The majority of our developers start out as users and guide their 
> development efforts from the user's perspective.
> 
> Users contribute to the Apache projects by providing feedback to developers 
> in the form of bug reports and feature suggestions. As well, users 
> participate in the Apache community by helping other users on mailing lists 
> and user support forums.
> 
> ### Contributors:
> 
> Contributors are all of the volunteers who are contributing time, code, 
> documentation, or resources to the Storm Project. A contributor that makes 
> sustained, welcome contributions to the project may be invited to become a 
> Committer, though the exact timing of such invitations depends on many 
> factors.
> 
> ### Committers:
> 
> The project's Committers are responsible for the project's technical 
> management. Committers have access to all project source repositories. 
> Committers may cast binding votes on any technical discussion regarding storm.
> 
> Committer access is by invitation only and must be approved by lazy consensus 
> of the active PMC members. A Committer is considered emeritus by their own 
> declaration or by not contributing in any form to the project for over six 
> months. An emeritus Committer may request reinstatement of commit access from 
> the PMC. Such reinstatement is subject to lazy consensus approval of active 
> PMC members.
> 
> All Apache Committers are required to have a signed Contributor License 
> Agreement (CLA) on file with the Apache Software Foundation. There is a 
> [Committers' FAQ](https://www.apache.org/dev/committers.html) which provides 
> more details on the requirements for Committers.
> 
> A Committer who makes a sustained contribution to the project may be invited 
> to become a member of the PMC. The form of contribution is not limited to 
> code. It can also include code review, helping out users on the mailing 
> lists, documentation, testing, etc.
> 
> ### Project Management Committee(PMC):
> 
> The PMC is responsible to the board and the ASF for the management and 
> oversight of the Apache Storm codebase. The responsibilities of the PMC 
> include:
> 
>  * Deciding what is distributed as products of the Apache Storm project. In 
> particular all releases must be approved by the PMC.
>  * Maintaining the project's shared resources, including the codebase 
> repository, mailing lists, websites.
>  * Speaking on behalf of the project.
>  * Resolving license disputes regarding products of the project.
>  * Nominating new PMC members and Committers.
>  * Maintaining these bylaws and other guidelines of the project.
> 
> Membership of the PMC is by invitation only and must be approved by a 
> consensus approval of active PMC members. A PMC member is considered 
> "emeritus" by their own declaration or by not contributing in any form to the 
> project for over six months. An emeritus member may request reinstatement to 
> the PMC. Such reinstatement is subject to consensus approval of the active 
> PMC members.
> 
> The chair of the PMC is appointed by the ASF board. The chair is an office 
> holder of the Apache Software Foundation (Vice President, Apache Storm) and 
> has primary responsibility to the board for the management of the projects 
> within the scope of the Storm PMC. The chair reports to the board quarterly 
> on developments within the Storm project.
> 
> The chair of the PMC is rotated annually. When the chair is rotated or if the 
> current chair of the PMC resigns, the PMC votes to recommend a new chair 
> using Single Transferable Vote (STV) voting. See 
> http://wiki.apache.org/general/BoardVoting for specifics. The decision must 
> be ratified by the Apache board.
> 
> ## Voting
> 
> Decisions regarding the project are made by votes on the primary project 
> development mailing list (dev@storm.apache.org). Where necessary, PMC voting 
> may take place on the private Storm PMC mailing list. Votes are clearly 
> indicated by subject line starting with [VOTE]. Votes may contain multiple 
> items for approval and these should be clearly separated. Votin

Re: [VOTE] Adopt Apache Storm Project Bylaws

[Parth Brahmbhatt]

+1.

Thanks
Parth

From: "P. Taylor Goetz" mailto:ptgo...@apache.org>>
Reply-To: mailto:dev@storm.apache.org>>
Date: Thursday, February 19, 2015 at 9:25 AM
To: mailto:dev@storm.apache.org>>
Subject: Re: [VOTE] Adopt Apache Storm Project Bylaws

+1

-Taylor

On Feb 18, 2015, at 4:43 PM, P. Taylor Goetz 
mailto:ptgo...@apache.org>> wrote:

As a follow-up to the previous discussion regarding adopting project bylaws, 
I’d like to start an official VOTE to formally adopt the bylaws as listed below.

Please vote on adopting the proposed bylaws.

[+1] Adopt the bylaws as listed
[+0] No opinion
[-1] Do not adopt the bylaws because…

This vote will be 2/3 Majority as described below, and open for 6 days.

-Taylor

-


# Apache Storm Project Bylaws


## Roles and Responsibilities

Apache projects define a set of roles with associated rights and 
responsibilities. These roles govern what tasks an individual may perform 
within the project. The roles are defined in the following sections:

### Users:

The most important participants in the project are people who use our software. 
The majority of our developers start out as users and guide their development 
efforts from the user's perspective.

Users contribute to the Apache projects by providing feedback to developers in 
the form of bug reports and feature suggestions. As well, users participate in 
the Apache community by helping other users on mailing lists and user support 
forums.

### Contributors:

Contributors are all of the volunteers who are contributing time, code, 
documentation, or resources to the Storm Project. A contributor that makes 
sustained, welcome contributions to the project may be invited to become a 
Committer, though the exact timing of such invitations depends on many factors.

### Committers:

The project's Committers are responsible for the project's technical 
management. Committers have access to all project source repositories. 
Committers may cast binding votes on any technical discussion regarding storm.

Committer access is by invitation only and must be approved by lazy consensus 
of the active PMC members. A Committer is considered emeritus by their own 
declaration or by not contributing in any form to the project for over six 
months. An emeritus Committer may request reinstatement of commit access from 
the PMC. Such reinstatement is subject to lazy consensus approval of active PMC 
members.

All Apache Committers are required to have a signed Contributor License 
Agreement (CLA) on file with the Apache Software Foundation. There is a 
[Committers' FAQ](https://www.apache.org/dev/committers.html) which provides 
more details on the requirements for Committers.

A Committer who makes a sustained contribution to the project may be invited to 
become a member of the PMC. The form of contribution is not limited to code. It 
can also include code review, helping out users on the mailing lists, 
documentation, testing, etc.

### Project Management Committee(PMC):

The PMC is responsible to the board and the ASF for the management and 
oversight of the Apache Storm codebase. The responsibilities of the PMC include:

 * Deciding what is distributed as products of the Apache Storm project. In 
particular all releases must be approved by the PMC.
 * Maintaining the project's shared resources, including the codebase 
repository, mailing lists, websites.
 * Speaking on behalf of the project.
 * Resolving license disputes regarding products of the project.
 * Nominating new PMC members and Committers.
 * Maintaining these bylaws and other guidelines of the project.

Membership of the PMC is by invitation only and must be approved by a consensus 
approval of active PMC members. A PMC member is considered "emeritus" by their 
own declaration or by not contributing in any form to the project for over six 
months. An emeritus member may request reinstatement to the PMC. Such 
reinstatement is subject to consensus approval of the active PMC members.

The chair of the PMC is appointed by the ASF board. The chair is an office 
holder of the Apache Software Foundation (Vice President, Apache Storm) and has 
primary responsibility to the board for the management of the projects within 
the scope of the Storm PMC. The chair reports to the board quarterly on 
developments within the Storm project.

The chair of the PMC is rotated annually. When the chair is rotated or if the 
current chair of the PMC resigns, the PMC votes to recommend a new chair using 
Single Transferable Vote (STV) voting. See 
http://wiki.apache.org/general/BoardVoting for specifics. The decision must be 
ratified by the Apache board.

## Voting

Decisions regarding the project are made by votes on the primary project 
development mailing list (dev@storm.apache.org). 
Where necessary, PMC voting may take place on the private Storm PMC mailing 
list. Votes are clearly indicated by subject line starting with [VOTE]. Votes 
m

[jira] [Commented] (STORM-678) Storm UI Spengo filter doesn't invalidate user session immediately upon kinit as a different user

[Manish Nema (JIRA)]

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

Manish Nema commented on STORM-678:
---

[~harsha_ch] Thanks, this seems to be working as expected, 

This might be required as one can dedicate few nodes as edge/gateway node where 
users can login and submit/view their job in secured cluster.

This change requires change in jinja scripts comes with Ambari 

>  Storm UI Spengo filter doesn't invalidate user session immediately upon 
> kinit as a different user
> --
>
> Key: STORM-678
> URL: https://issues.apache.org/jira/browse/STORM-678
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.9.3
> Environment: CentOS 6.6 64bit
> Java jdk1.7.0_67
> Kerberos enabled
>Reporter: Manish Nema
>Assignee: Sriharsha Chintalapani
>  Labels: Security, Storm, storm-security
>
> I am using HDP 2.2 which includes fixes of  
> https://issues.apache.org/jira/browse/STORM-216. 
> Install STORM with Nagios and Ganglia, there is no HDFS, Hadoop installed on 
> the cluster, cluster is made of three nodes. 
> Enable security as guided by Ambari, kerberize the cluster this covers 
> everything as specified in the 
> https://github.com/apache/storm/blob/security/SECURITY.md . 
> Now submit job from 'test' user principal from the gateway node. Open Storm 
> UI in firefox or google-chrome it shows the topology running as 'test' user. 
> Now kinit with another user 'test2' refresh the UI. It still says the 'test' 
> user . Even closing and re-opening firefox /chrome doesnt help. It lets 
> 'test2' user kill topology of 'test' user.
> This behaviour is not observed when using storm kill command in command line



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

[GitHub] storm pull request: Storm-456 cannot navigate to topology page whe...

[NareshKosgi]

Github user NareshKosgi commented on the pull request:

https://github.com/apache/storm/pull/318#issuecomment-75109471
  
@revans2 @Parth-Brahmbhatt I was able to build and run by using mvn 
install.  I checked with topo name with space and '%' sign.  They are working.  
Do I just close the pull request and jira ticket in that case?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request: Storm-456 cannot navigate to topology page whe...

[Parth-Brahmbhatt]

Github user Parth-Brahmbhatt commented on the pull request:

https://github.com/apache/storm/pull/318#issuecomment-75109743
  
@NareshKosgi Thanks for testing the feature, yes you can just close it.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request: Storm-456 cannot navigate to topology page whe...

[NareshKosgi]

Github user NareshKosgi closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Re: HdfsBolt and hdfs in HA mode

[clay teahouse]

I am already using hdfsbolt successfully (without hdfs HA). So, I assume
this the client java class in already in my classpath if it comes with the
hadoop jar files that I load when I run my topology, unless there is jar
specific to the hadoop HA classes which would have
dfs.clent.failover.proxy.provider class.  I mean I don't need to take any
specific action aside from configuring my dfs-site.xml.

thanks,
Clay

On Thu, Feb 19, 2015 at 11:14 AM, Harsha  wrote:

>
> Clay,
>  When you are using storm-hdfs connector you need to package
>  core-site.xml and hdfs-site.xml form you cluster into your topology
>  jar . You can configure the storm-hdfs bolt to pass nameserviceID
>
> HdfsBolt bolt = new HdfsBolt()
>.withFsURL("hdfs://myNameserviceID")
>.withFileNameFormat(fileNameformat)
>.withRecordFormat(format)
>.withRotationPolicy(rotationPolicy)
>.withSynPolicy(syncPolicy);
>
> The above is all that needed to use namenode HA with your storm-hdfs.
>
> -Harsha
>
> On Thu, Feb 19, 2015, at 08:58 AM, Bobby Evans wrote:
> > Hadoop has lots of different configurations in core-site.xml,
> > hdfs-site.xml, ... all of which eventually get loaded into the
> > Configuration object used to create a FileSystem instance.  There are so
> > many different configurations related to security, HA, etc. that it is
> > almost impossible for me to guess exactly which ones you need to have set
> > correctly to make this work.  Typically what we do for storm to be able
> > to talk to HDFS is to package the complete set of configs that appear on
> > a Hadoop Gateway with the topology jar when it is shipped.  This
> > guarantees that the config is the same as on the gateway and should
> > behave the same way.  You can also grab them from the name node or any of
> > the hadoop compute nodes.
> >  This will work for the HdfsBolt that loads default configurations from
> the classpath before overriding them with any custom configurations you set
> for that bolt.
> >
> > - Bobby
> >
> >
> >  On Thursday, February 19, 2015 10:42 AM, clay teahouse
> >   wrote:
> >
> >
> >  Bobby,What do you mean by client here? In this context, do you consider
> >  hdfsbolt a client? If yes, then which configuration you are referring
> >  to? I've seen the following, but I am not sure if I follow.
> >
> >- dfs.client.failover.proxy.provider.[nameservice ID] - the Java class
> >that HDFS clients use to contact the Active NameNodeConfigure the name
> >of the Java class which will be used by the DFS Client to determine
> >which NameNode is the current Active, and therefore which NameNode is
> >currently serving client requests. The only implementation which
> >currently ships with Hadoop is the ConfiguredFailoverProxyProvider, so
> >use this unless you are using a custom one. For example:   
> >   dfs.client.failover.proxy.provider.mycluster
> >
>  
> org.apache.hadoop.hdfs.server.namenode.ha.ConfiguredFailoverProxyProvider
> > 
> > thanks,Clay
> >
> > On Thu, Feb 19, 2015 at 8:38 AM, Bobby Evans
> >  wrote:
> >
> > HDFS HA provides fail-over for the name node and the client determines
> > which name node is the active one but should be completely transparent to
> > you if the client is configured correctly.
> >  - Bobby
> >
> >
> >  On Thursday, February 19, 2015 6:47 AM, clay teahouse <
> clayteaho...@gmail.com> wrote:
> >
> >
> >  Hi All,
> > Has anyone used HdfsBolt with hdfs in HA mode? How would you determine
> > which hdfs node is the active node?
> >
> > thanks
> > Clay
> >
> >
> >
> >
> >
> >
> >
>

[GitHub] storm pull request: [STORM-681] Auto insert license header with ge...

[Parth-Brahmbhatt]

Github user Parth-Brahmbhatt commented on the pull request:

https://github.com/apache/storm/pull/436#issuecomment-75147379
  
+1. I am not sure if the date change is something we want to include for 
all the existing files that has no other change.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-681) Auto insert license header with genthrift.sh

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-681:
--

Github user Parth-Brahmbhatt commented on the pull request:

https://github.com/apache/storm/pull/436#issuecomment-75147379
  
+1. I am not sure if the date change is something we want to include for 
all the existing files that has no other change.


> Auto insert license header with genthrift.sh
> 
>
> Key: STORM-681
> URL: https://issues.apache.org/jira/browse/STORM-681
> Project: Apache Storm
>  Issue Type: Improvement
>Affects Versions: 0.10.0, 0.9.3-rc2
>Reporter: Kai Sasaki
>Assignee: Kai Sasaki
>Priority: Minor
>  Labels: documentaion, thrift
>
> Current genthrift.sh does not insert license headers into generated source 
> codes. These java codes and python codes should have license headers. 
> And documentation about this command.



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

[GitHub] storm pull request: [STORM-681] Auto insert license header with ge...

[Lewuathe]

Github user Lewuathe commented on the pull request:

https://github.com/apache/storm/pull/436#issuecomment-75162992
  
@Parth-Brahmbhatt Yes, I'm not sure too. But I think it is better to 
include the files generated by new `genthrift.sh` script in order to keep and 
confirm whole source code consistency.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-681) Auto insert license header with genthrift.sh

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-681:
--

Github user Lewuathe commented on the pull request:

https://github.com/apache/storm/pull/436#issuecomment-75162992
  
@Parth-Brahmbhatt Yes, I'm not sure too. But I think it is better to 
include the files generated by new `genthrift.sh` script in order to keep and 
confirm whole source code consistency.


> Auto insert license header with genthrift.sh
> 
>
> Key: STORM-681
> URL: https://issues.apache.org/jira/browse/STORM-681
> Project: Apache Storm
>  Issue Type: Improvement
>Affects Versions: 0.10.0, 0.9.3-rc2
>Reporter: Kai Sasaki
>Assignee: Kai Sasaki
>Priority: Minor
>  Labels: documentaion, thrift
>
> Current genthrift.sh does not insert license headers into generated source 
> codes. These java codes and python codes should have license headers. 
> And documentation about this command.



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

[GitHub] storm pull request: [STORM-639] storm-maven-plugin not found

[Lewuathe]

Github user Lewuathe commented on the pull request:

https://github.com/apache/storm/pull/403#issuecomment-75163410
  
I changed documentation. Can someone review it?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-639) storm-maven-plugin not found

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-639:
--

Github user Lewuathe commented on the pull request:

https://github.com/apache/storm/pull/403#issuecomment-75163410
  
I changed documentation. Can someone review it?


> storm-maven-plugin not found
> 
>
> Key: STORM-639
> URL: https://issues.apache.org/jira/browse/STORM-639
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.10.0
>Reporter: Kai Sasaki
>Assignee: Kai Sasaki
>Priority: Minor
>  Labels: maven, plugin
>
> storm-maven-plugin is required by storm-core, but it cannot be found.
> ```
> [ERROR] Error resolving version for plugin 
> 'org.apache.storm:storm-maven-plugins' from the repositories [local 
> (/Users/sasakikai/.m2/repository), central 
> (https://repo.maven.apache.org/maven2)]: Plugin not found in any plugin 
> repository -> [Help 1]
> org.apache.maven.plugin.version.PluginVersionResolutionException: Error 
> resolving version for plugin 'org.apache.storm:storm-maven-plugins' from the 
> repositories [local (/Users/sasakikai/.m2/repository), central 
> (https://repo.maven.apache.org/maven2)]: Plugin not found in any plugin 
> repository
> at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.selectVersion(DefaultPluginVersionResolver.java:236)
> at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolveFromRepository(DefaultPluginVersionResolver.java:148)
> at 
> org.apache.maven.plugin.version.internal.DefaultPluginVersionResolver.resolve(DefaultPluginVersionResolver.java:96)
> at 
> org.apache.maven.lifecycle.internal.LifecyclePluginResolver.resolveMissingPluginVersions(LifecyclePluginResolver.java:71)
> at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:116)
> at 
> org.apache.maven.lifecycle.internal.DefaultLifecycleExecutionPlanCalculator.calculateExecutionPlan(DefaultLifecycleExecutionPlanCalculator.java:135)
> at 
> org.apache.maven.lifecycle.internal.builder.BuilderCommon.resolveBuildPlan(BuilderCommon.java:97)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:109)
> at 
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80)
> at 
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51)
> at 
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:347)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:154)
> at org.apache.maven.cli.MavenCli.execute(MavenCli.java:582)
> at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
> at 
> org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
> [ERROR]
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> ```
> This plugin should be installed in local repository before compile storm-core.



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

[GitHub] storm pull request: STORM-670: restore java 1.6 compatibility (sto...

[harshach]

Github user harshach commented on the pull request:

https://github.com/apache/storm/pull/431#issuecomment-75184764
  
+1


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-670) [storm-kafka] Restore Java 1.6 compatibility

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-670:
--

Github user harshach commented on the pull request:

https://github.com/apache/storm/pull/431#issuecomment-75184764
  
+1


> [storm-kafka] Restore Java 1.6 compatibility
> 
>
> Key: STORM-670
> URL: https://issues.apache.org/jira/browse/STORM-670
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-kafka
>Affects Versions: 0.10.0
>Reporter: P. Taylor Goetz
>Assignee: P. Taylor Goetz
>
> java.lang.Long.compare(Long, Long) is only available in Java 1.7



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

[GitHub] storm pull request: Storm-616 : Storm-jdbc connector.

[harshach]

Github user harshach commented on the pull request:

https://github.com/apache/storm/pull/374#issuecomment-75185107
  
+1.  @Parth-Brahmbhatt  Thanks for the quick fix . @Crystark  Thanks for 
review and nice catch.
@revans2  @ptgoetz  I think this is ready to merge it in will give it a day 
or two before pushing it to master. 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] storm pull request: STORM-648. storm examples BasicDRPCTopology fa...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-648) storm examples BasicDRPCTopology fails without running

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-648:
--

Github user asfgit closed the pull request at:

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


> storm examples BasicDRPCTopology fails without running
> --
>
> Key: STORM-648
> URL: https://issues.apache.org/jira/browse/STORM-648
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
>Priority: Trivial
>




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

[GitHub] storm pull request: STORM-651: Rename "ui" service to "storm ui" a...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-651) improvements to storm.cmd

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-651:
--

Github user asfgit closed the pull request at:

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


> improvements to storm.cmd
> -
>
> Key: STORM-651
> URL: https://issues.apache.org/jira/browse/STORM-651
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Parth Brahmbhatt
>Priority: Minor
>




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

[GitHub] storm pull request: STORM-633. Nimbus - HTTP Error 413 full HEAD i...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-633) Nimbus - HTTP Error 413 full HEAD if using kerberos authentication

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-633:
--

Github user asfgit closed the pull request at:

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


> Nimbus - HTTP Error 413 full HEAD if using kerberos authentication
> --
>
> Key: STORM-633
> URL: https://issues.apache.org/jira/browse/STORM-633
> Project: Apache Storm
>  Issue Type: Bug
>Affects Versions: 0.9.3
>Reporter: Kevin Risden
>Assignee: Sriharsha Chintalapani
>
> When trying to access Nimbus that is kerberized, a HTTP 413 full HEAD error 
> is received. This seems related to the issue outlined in HADOOP-8816.
> Setting the Jetty header buffer size with ring-jetty is outlined on 
> Stackoverflow here: 
> http://stackoverflow.com/questions/9285096/clojure-ring-using-the-ring-jetty-adapter-large-requests-give-me-a-413-full-h
> The setting could be exposed like the host as done in STORM-575.



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

[GitHub] storm pull request: Storm-649: Storm HDFS test topologies should w...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (STORM-640) Storm UI vulnerable to poodle attack

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-640:
--

Github user asfgit closed the pull request at:

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


> Storm UI vulnerable to poodle attack
> 
>
> Key: STORM-640
> URL: https://issues.apache.org/jira/browse/STORM-640
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Sriharsha Chintalapani
>Assignee: Sriharsha Chintalapani
>Priority: Trivial
>
> More info on this page http://en.wikipedia.org/wiki/POODLE . 
> Steps to verify
> 1 Enable storm ui or logviewer to listen in SSL
> 2. openssl s_client -connect host:port | grep Protocol
> 3. If SSLv3 shows up you have the vulnerability, TLS protocol versions are OK.



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

[GitHub] storm pull request: STORM-640. Storm UI vulnerable to poodle attac...

[asfgit]

Github user asfgit closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---