[GitHub] storm pull request: Windows fork option
Github user d2r commented on the pull request: https://github.com/apache/storm/pull/335#issuecomment-81726578 Looks like this needs a JIRA also. @JamisonWhite , If you have an account at issues.apache.org, would you create a STORM JIRA issue and update the title of this pull request with [STORM-X] ? --- 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: SimpleTransportPlugin Using TThreadPoolServer
Github user d2r commented on the pull request: https://github.com/apache/storm/pull/430#issuecomment-81730400 -0 unless we have evidence of a real performance issue that needs fixing here. @darionyaphet, If this pull request is related to an existing JIRA issue, it would help us out if you would update the title of this pull request with [STORM-X]. Here is a [link](https://issues.apache.org/jira/browse/STORM-510?jql=project%20%3D%20STORM%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC) to some currently unresolved issues in the JIRA system, for reference. --- 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-510) Netty messaging client blocks transfer thread on reconnect
[ https://issues.apache.org/jira/browse/STORM-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1436#comment-1436 ] ASF GitHub Bot commented on STORM-510: -- Github user d2r commented on the pull request: https://github.com/apache/storm/pull/430#issuecomment-81730400 -0 unless we have evidence of a real performance issue that needs fixing here. @darionyaphet, If this pull request is related to an existing JIRA issue, it would help us out if you would update the title of this pull request with [STORM-X]. Here is a [link](https://issues.apache.org/jira/browse/STORM-510?jql=project%20%3D%20STORM%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20priority%20DESC) to some currently unresolved issues in the JIRA system, for reference. > Netty messaging client blocks transfer thread on reconnect > -- > > Key: STORM-510 > URL: https://issues.apache.org/jira/browse/STORM-510 > Project: Apache Storm > Issue Type: Sub-task >Affects Versions: 0.9.2-incubating, 0.9.3 >Reporter: Robert Joseph Evans >Priority: Critical > > The latest netty client code will attempt to reestablish the connection on > failure as part of the send method call. It will block until the connection > is established or a timeout happens, by default this is about 30 seconds, > which is also the default tuple timeout. > This is exacerbated by the read lock that is held during the send, that > prevents the node->socket mapping from changing while we are sending. This > is mostly so that we don't close connections while we are trying to write to > them, which would cause an exception. But this makes it so if there are > multiple workers on a node that all get rescheduled we will wait the full 30 > seconds to timeout for each worker. > send must be non-blocking in the current design of the worker, or it will > prevent other messages from being delivered, and is likely to cause many many > messages to timeout on a reschedule. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: Fix bug related to error handling in js multil...
Github user d2r commented on the pull request: https://github.com/apache/storm/pull/341#issuecomment-81731274 @anyatch any update? --- 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
[
https://issues.apache.org/jira/browse/STORM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363338#comment-14363338
]
ASF GitHub Bot commented on STORM-329:
--
Github user d2r commented on the pull request:
https://github.com/apache/storm/pull/268#issuecomment-81733977
@miguno, @tedxia I am scanning through open pull requests: It seems #429
has been merged instead of this pull request and STORM-329 has been resolved.
If this is correct, and we no longer need these changes, can we close this
pull request?
> 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, 0.9.4
>
> 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)
[GitHub] storm pull request: STORM-329 : buffer message in client and recon...
Github user miguno commented on the pull request: https://github.com/apache/storm/pull/268#issuecomment-81736347 @d2r And btw I don't have permissions on GitHub to close this PR. --- 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-329 : buffer message in client and recon...
Github user d2r commented on the pull request: https://github.com/apache/storm/pull/268#issuecomment-81733977 @miguno, @tedxia I am scanning through open pull requests: It seems #429 has been merged instead of this pull request and STORM-329 has been resolved. If this is correct, and we no longer need these changes, can we close this pull request? --- 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-707) Client (Netty): improve logging to help troubleshooting connection woes
[ https://issues.apache.org/jira/browse/STORM-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363346#comment-14363346 ] ASF GitHub Bot commented on STORM-707: -- Github user miguno commented on the pull request: https://github.com/apache/storm/pull/463#issuecomment-81739459 I created [STORM-707](https://issues.apache.org/jira/browse/STORM-707) to track this. > Client (Netty): improve logging to help troubleshooting connection woes > --- > > Key: STORM-707 > URL: https://issues.apache.org/jira/browse/STORM-707 > Project: Apache Storm > Issue Type: Improvement >Affects Versions: 0.9.3 >Reporter: Michael Noll >Assignee: Michael Noll >Priority: Minor > > The current code in Client.java has a few places where we lack proper logging > to troubleshoot connection issues (like we had to do for STORM-329). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (STORM-329) Fix cascading Storm failure by improving reconnection strategy and buffering messages
[
https://issues.apache.org/jira/browse/STORM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363342#comment-14363342
]
ASF GitHub Bot commented on STORM-329:
--
Github user miguno commented on the pull request:
https://github.com/apache/storm/pull/268#issuecomment-81736347
@d2r And btw I don't have permissions on GitHub to close this PR.
> 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, 0.9.4
>
> 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)
[GitHub] storm pull request: STORM-329 : buffer message in client and recon...
Github user miguno commented on the pull request: https://github.com/apache/storm/pull/268#issuecomment-81735980 Yes, this pull request can be closed. --- 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
[
https://issues.apache.org/jira/browse/STORM-329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363341#comment-14363341
]
ASF GitHub Bot commented on STORM-329:
--
Github user miguno commented on the pull request:
https://github.com/apache/storm/pull/268#issuecomment-81735980
Yes, this pull request can be closed.
> 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, 0.9.4
>
> 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)
[GitHub] storm pull request: STORM-707: Client (Netty): improve logging to ...
Github user miguno commented on the pull request: https://github.com/apache/storm/pull/463#issuecomment-81739459 I created [STORM-707](https://issues.apache.org/jira/browse/STORM-707) to track this. --- 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-707) Client (Netty): improve logging to help troubleshooting connection woes
[ https://issues.apache.org/jira/browse/STORM-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363347#comment-14363347 ] Michael Noll commented on STORM-707: These logging statements are not on a hot path, and INFO is the default log level of Storm. These logging statements are filling a gap that facilitates understanding connection woes in a Storm cluster (cf. our work on STORM-329). > Client (Netty): improve logging to help troubleshooting connection woes > --- > > Key: STORM-707 > URL: https://issues.apache.org/jira/browse/STORM-707 > Project: Apache Storm > Issue Type: Improvement >Affects Versions: 0.9.3 >Reporter: Michael Noll >Assignee: Michael Noll >Priority: Minor > > The current code in Client.java has a few places where we lack proper logging > to troubleshoot connection issues (like we had to do for STORM-329). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (STORM-707) Client (Netty): improve logging to help troubleshooting connection woes
Michael Noll created STORM-707: -- Summary: Client (Netty): improve logging to help troubleshooting connection woes Key: STORM-707 URL: https://issues.apache.org/jira/browse/STORM-707 Project: Apache Storm Issue Type: Improvement Affects Versions: 0.9.3 Reporter: Michael Noll Assignee: Michael Noll Priority: Minor The current code in Client.java has a few places where we lack proper logging to troubleshoot connection issues (like we had to do for STORM-329). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: 0.8.3
Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/300 --- 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: 0.8.3
Github user d2r commented on the pull request: https://github.com/apache/storm/pull/300#issuecomment-81761267 Closed due to inactivity/no JIRA --- 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-699: storm-jdbc should support custom in...
Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/458 --- 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-699) storm-jdbc should support customer insert queries.
[ https://issues.apache.org/jira/browse/STORM-699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363459#comment-14363459 ] ASF GitHub Bot commented on STORM-699: -- Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/458 > storm-jdbc should support customer insert queries. > -- > > Key: STORM-699 > URL: https://issues.apache.org/jira/browse/STORM-699 > Project: Apache Storm > Issue Type: Improvement >Affects Versions: 0.10.0 >Reporter: Parth Brahmbhatt >Assignee: Parth Brahmbhatt >Priority: Minor > > Currently storm-jdbc insert bolt/state only supports to specify a table name > and constructs a query of the form "insert into tablename values(?,?,?)" > based on table's schema. This fails to support use cases like "insert into as > select * from" or special cases like Phoenix that has a jdbc driver but only > supports "upsert into". > We should add a way so the users can specify their own custom query for the > insert bolt. This was already pointed out by [~revans2] during the PR review > and we now have concrete cases that will be benefited by this feature. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (STORM-583) Add spout and bolt implementation for Azure Eventhubs
[ https://issues.apache.org/jira/browse/STORM-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] P. Taylor Goetz updated STORM-583: -- Attachment: storm-eventhubs.tar.gz Attach code for IP clearance. > Add spout and bolt implementation for Azure Eventhubs > - > > Key: STORM-583 > URL: https://issues.apache.org/jira/browse/STORM-583 > Project: Apache Storm > Issue Type: Bug >Affects Versions: 0.9.3 >Reporter: shanyu zhao >Assignee: shanyu zhao > Fix For: 0.10.0 > > Attachments: Storm-EventHubsDesign.docx, storm-eventhubs.tar.gz > > > Add spout and bolt implementations for Azure Eventhubs - a messaging service > that supports AMQP protocol. Just like storm-kafka/storm-hbase, we need to > add the project to the /external folder. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: STORM-706 . Clarify examples README.
GitHub user jayunit100 opened a pull request: https://github.com/apache/storm/pull/465 STORM-706 . Clarify examples README. STORM-706 You can merge this pull request into a Git repository by running: $ git pull https://github.com/jayunit100/storm STORM-706 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/465.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 #465 commit ca1a1aee1f4883343144c51c627bdac1a3fe90cf Author: jay vyas Date: 2015-03-15T03:20:12Z STORM-706. Clarify examples README. --- 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-706) Clarify IntelliJ instructions for example running.
[ https://issues.apache.org/jira/browse/STORM-706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363690#comment-14363690 ] ASF GitHub Bot commented on STORM-706: -- GitHub user jayunit100 opened a pull request: https://github.com/apache/storm/pull/465 STORM-706 . Clarify examples README. STORM-706 You can merge this pull request into a Git repository by running: $ git pull https://github.com/jayunit100/storm STORM-706 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/465.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 #465 commit ca1a1aee1f4883343144c51c627bdac1a3fe90cf Author: jay vyas Date: 2015-03-15T03:20:12Z STORM-706. Clarify examples README. > Clarify IntelliJ instructions for example running. > -- > > Key: STORM-706 > URL: https://issues.apache.org/jira/browse/STORM-706 > Project: Apache Storm > Issue Type: Bug >Reporter: jay vyas > > Since the defaults for the examples topology assume maven scope is provided, > you have to comment out the "provided" part in order to load the classes and > run them via any IDE. > This should be clarified in the README. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] storm pull request: STORM-707: Client (Netty): improve logging to ...
Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/463 --- 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-707) Client (Netty): improve logging to help troubleshooting connection woes
[ https://issues.apache.org/jira/browse/STORM-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14363754#comment-14363754 ] ASF GitHub Bot commented on STORM-707: -- Github user asfgit closed the pull request at: https://github.com/apache/storm/pull/463 > Client (Netty): improve logging to help troubleshooting connection woes > --- > > Key: STORM-707 > URL: https://issues.apache.org/jira/browse/STORM-707 > Project: Apache Storm > Issue Type: Improvement >Affects Versions: 0.9.3 >Reporter: Michael Noll >Assignee: Michael Noll >Priority: Minor > > The current code in Client.java has a few places where we lack proper logging > to troubleshoot connection issues (like we had to do for STORM-329). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (STORM-707) Client (Netty): improve logging to help troubleshooting connection woes
[ https://issues.apache.org/jira/browse/STORM-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kyle Nusbaum closed STORM-707. -- Resolution: Done > Client (Netty): improve logging to help troubleshooting connection woes > --- > > Key: STORM-707 > URL: https://issues.apache.org/jira/browse/STORM-707 > Project: Apache Storm > Issue Type: Improvement >Affects Versions: 0.9.3 >Reporter: Michael Noll >Assignee: Michael Noll >Priority: Minor > > The current code in Client.java has a few places where we lack proper logging > to troubleshoot connection issues (like we had to do for STORM-329). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (STORM-708) CORS support for Storm UI
Sriharsha Chintalapani created STORM-708: Summary: CORS support for Storm UI Key: STORM-708 URL: https://issues.apache.org/jira/browse/STORM-708 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-708. CORS support for STORM UI.
GitHub user harshach opened a pull request: https://github.com/apache/storm/pull/466 STORM-708. CORS support for STORM UI. You can merge this pull request into a Git repository by running: $ git pull https://github.com/harshach/incubator-storm STORM-708 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/466.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 #466 commit 0201a90aec9a73c75ec7bed640ddf70efb1874d8 Author: Sriharsha Chintalapani Date: 2015-03-16T22:33:31Z STORM-708. CORS support for STORM UI. --- 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-708) CORS support for Storm UI
[ https://issues.apache.org/jira/browse/STORM-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364114#comment-14364114 ] ASF GitHub Bot commented on STORM-708: -- GitHub user harshach opened a pull request: https://github.com/apache/storm/pull/466 STORM-708. CORS support for STORM UI. You can merge this pull request into a Git repository by running: $ git pull https://github.com/harshach/incubator-storm STORM-708 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/storm/pull/466.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 #466 commit 0201a90aec9a73c75ec7bed640ddf70efb1874d8 Author: Sriharsha Chintalapani Date: 2015-03-16T22:33:31Z STORM-708. CORS support for STORM UI. > CORS support for Storm UI > - > > Key: STORM-708 > URL: https://issues.apache.org/jira/browse/STORM-708 > 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-708. CORS support for STORM UI.
Github user Parth-Brahmbhatt commented on the pull request: https://github.com/apache/storm/pull/466#issuecomment-81979574 +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-708) CORS support for Storm UI
[ https://issues.apache.org/jira/browse/STORM-708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14364142#comment-14364142 ] ASF GitHub Bot commented on STORM-708: -- Github user Parth-Brahmbhatt commented on the pull request: https://github.com/apache/storm/pull/466#issuecomment-81979574 +1. > CORS support for Storm UI > - > > Key: STORM-708 > URL: https://issues.apache.org/jira/browse/STORM-708 > 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)
