[GitHub] storm pull request: STORM:1463 added file scehma to log4j config f...

[satishd]

GitHub user satishd opened a pull request:

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

STORM:1463 added file scehma to log4j config files for windows env



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

$ git pull https://github.com/satishd/storm STORM-1463

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

https://github.com/apache/storm/pull/1004.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 #1004


commit 96372fa7a3c5a87eef9a97acada44ea17deb9306
Author: Satish Duggana 
Date:   2016-01-12T07:20:55Z

STORM:1463 added file scehma to log4j config files for windows env




---
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-1463) log4j dir uri should always have file schema

[Satish Duggana (JIRA)]

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

Satish Duggana commented on STORM-1463:
---

This issue exists on Windows environment.

> log4j dir uri should always have file schema
> 
>
> Key: STORM-1463
> URL: https://issues.apache.org/jira/browse/STORM-1463
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Satish Duggana
>Assignee: Satish Duggana
>




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

[jira] [Commented] (STORM-1175) State store for windowing operations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1175:
---

Github user arunmahadevan commented on the pull request:

https://github.com/apache/storm/pull/939#issuecomment-170810010
  
@Parth-Brahmbhatt Fixed the merge conflicts. 

Also had to refactor most of the code since the package name changed from 
backtype.storm -> org.apache.storm in master. Ran the sample topologies after 
the package name refactoring and things look good.


> State store for windowing operations
> 
>
> Key: STORM-1175
> URL: https://issues.apache.org/jira/browse/STORM-1175
> Project: Apache Storm
>  Issue Type: Sub-task
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
>
> Windowing operations should be able to save the results of partial 
> computations in a state store. This should persist across restarts and bolts 
> should be able to look up the values from the store.



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

[GitHub] storm pull request: [STORM-1175] State store for windowing operati...

[arunmahadevan]

Github user arunmahadevan commented on the pull request:

https://github.com/apache/storm/pull/939#issuecomment-170810010
  
@Parth-Brahmbhatt Fixed the merge conflicts. 

Also had to refactor most of the code since the package name changed from 
backtype.storm -> org.apache.storm in master. Ran the sample topologies after 
the package name refactoring and things look good.


---
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] [Created] (STORM-1463) log4j dir uri should always have file schema

[Satish Duggana (JIRA)]

Satish Duggana created STORM-1463:
-

 Summary: log4j dir uri should always have file schema
 Key: STORM-1463
 URL: https://issues.apache.org/jira/browse/STORM-1463
 Project: Apache Storm
  Issue Type: Bug
Reporter: Satish Duggana
Assignee: Satish Duggana






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

RE: 1.x storm and jstorm merger

[刘键(Basti Liu)]

Hi Bobby,

It is great to see that we are going to finalize Storm 1.x and start the 
migration.
Just to synchronize current status of migration in Alibaba, the migration of 
Nimbus and Supervisor part is in progress(around 50% is completed).
Besides it, we'd like to confirm the handling of following bug fixes in 
branch-1.x. Who is responsible to migrate the fix from branch-1.x to mater 
branch(2.0.0-snapshot)? the owner of the JIRA in branch-1.x or the owner of 
corresponding migration JIRA in master branch?

Regards
Basti

-Original Message-
From: Bobby Evans [mailto:ev...@yahoo-inc.com.INVALID] 
Sent: Tuesday, January 12, 2016 5:39 AM
To: Dev
Subject: 1.x storm and jstorm merger

I think we are finally at the point were this is going to start happening.
I have merged in as many JIRA/PULL requests that looked like they were ready.  
The most disruptive of these is probably STORM-1202, which translated 
backtype.storm to org.apache.storm and storm.trident to 
org.apache.storm.trident  There is some hack code that we will remove in the 
future that when submitting a topology using the new client it will translate 
your jar for you to the new namespaces.  You can enable it by setting 
`client.jartransformer.class` to `org.apache.storm.hack.StormShadeTransformer`

With that I changed the 0.11.0 tag to 1.0.0.  And I created a branch-1.x branch 
in the main repo.  I have not started creating a release candidate just yet as 
there still are a few outstanding bugs that I would like to see resolved before 
hand.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20type%20%3D%20Bug%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3E%3D%20Blocker

Of them only STORM-1452 really feels like a blocker, but I am open to others 
opinions as we work towards a release.  I would encourage everyone to kick the 
tires on it and file JIRA if you do find any issues.



I also changed the version on master to 2.0.0-SNAPSHOT in preparation for the 
migration to java and the JStorm merger.  This means that we are now open to 
start pulling in java migration pull requests as outlined on the wiki
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328109
I know that my team is going to start working on this process now to try and 
shorten the time of the transition as much as possible.  From this point on 
until the transition to java is complete there will be a moratorium on new 
features going into storm.  This is not a hard moratorium.  If your changes 
only touch java code, like in the external projects, etc.  I don't think anyone 
will complain if new features go in, but this is mostly to reduce churn in the 
code so the transition is a smooth as possible.  To help with this, and because 
there was some discussion about style guidelines, etc I through together a wiki 
for some conventions/guidelines.

https://cwiki.apache.org/confluence/display/STORM/Java+Migration+Guidelines
I put it together mostly to have a place for it.  I am not religious about the 
guidelines, I just want us to have some as we go forward, and I don't really 
want to wait for someone to reformat all of the files and put checks in place 
for them.  If others disagree we can modify them as we see fit.
As far as coordination in doing the translation I will try to update the JIRAs 
that I filed to match what is currently out on master.  When you do pick up a 
JIRA to work on please assign it to yourself and move the state to "In 
Progress" so everyone knows that you are working on it.  If you want to pick up 
something but it depends on something someone else is doing and it is not being 
completed in a timely manor, please comment on the JIRA before doing anything 
to ask for a status update.  If they are unable to respond within a few days 
feel free to take over the JIRA.  I personally thing moving quickly is more 
important than hurt feelings.  So please pay attention to comments on the JIRA 
you are working on. - Bobby

Transferred and Acked is zeros !

[researcher cs]

After i submitted topology i got numbers in Emitted and executed coumns but
got zeros in Acked and Transferred columns

How can i fix it ?

[jira] [Commented] (STORM-1175) State store for windowing operations

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1175:
---

Github user Parth-Brahmbhatt commented on the pull request:

https://github.com/apache/storm/pull/939#issuecomment-170755274
  
@arunmahadevan I am still +1 but the up merge is failing for 
storm-core/src/jvm/org/apache/storm/topology/TopologyBuilder.java can you 
please upmerge the last time and I can merge this into master.


> State store for windowing operations
> 
>
> Key: STORM-1175
> URL: https://issues.apache.org/jira/browse/STORM-1175
> Project: Apache Storm
>  Issue Type: Sub-task
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
>
> Windowing operations should be able to save the results of partial 
> computations in a state store. This should persist across restarts and bolts 
> should be able to look up the values from the store.



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

[GitHub] storm pull request: [STORM-1175] State store for windowing operati...

[Parth-Brahmbhatt]

Github user Parth-Brahmbhatt commented on the pull request:

https://github.com/apache/storm/pull/939#issuecomment-170755274
  
@arunmahadevan I am still +1 but the up merge is failing for 
storm-core/src/jvm/org/apache/storm/topology/TopologyBuilder.java can you 
please upmerge the last time and I can merge this into 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.
---

[jira] [Commented] (STORM-1453) nimbus.clj/wait-for-desired-code-replication print wrong log message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1453:
---

Github user caofangkun commented on the pull request:

https://github.com/apache/storm/pull/996#issuecomment-170755067
  
Updated as PR #1003 

Close this PR .


> nimbus.clj/wait-for-desired-code-replication print wrong log message
> 
>
> Key: STORM-1453
> URL: https://issues.apache.org/jira/browse/STORM-1453
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0
>Reporter: caofangkun
>Assignee: caofangkun
>Priority: Trivial
>
> https://github.com/apache/storm/blob/master/storm-core/src/clj/backtype/storm/daemon/nimbus.clj#L516



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

[GitHub] storm pull request: [STORM-1453] nimbus.clj/wait-for-desired-code-...

[caofangkun]

Github user caofangkun commented on the pull request:

https://github.com/apache/storm/pull/996#issuecomment-170755067
  
Updated as PR #1003 

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.
---

[jira] [Commented] (STORM-1453) nimbus.clj/wait-for-desired-code-replication print wrong log message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1453:
---

Github user caofangkun closed the pull request at:

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


> nimbus.clj/wait-for-desired-code-replication print wrong log message
> 
>
> Key: STORM-1453
> URL: https://issues.apache.org/jira/browse/STORM-1453
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0
>Reporter: caofangkun
>Assignee: caofangkun
>Priority: Trivial
>
> https://github.com/apache/storm/blob/master/storm-core/src/clj/backtype/storm/daemon/nimbus.clj#L516



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

[GitHub] storm pull request: [STORM-1453] nimbus.clj/wait-for-desired-code-...

[caofangkun]

Github user caofangkun closed the pull request at:

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


---
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-1453) nimbus.clj/wait-for-desired-code-replication print wrong log message

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1453:
---

GitHub user caofangkun opened a pull request:

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

[STORM-1453] nimbus.clj/wait-for-desired-code-replication print wrong log 
message



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

$ git pull https://github.com/caofangkun/apache-storm storm-1453-1

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

https://github.com/apache/storm/pull/1003.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 #1003


commit 64a57a39fe1d4b0a1f3d15a264eb3335d72e1af6
Author: ablecao 
Date:   2016-01-12T01:38:41Z

[STORM-1453] nimbus.clj/wait-for-desired-code-replication print wrong log 
message




> nimbus.clj/wait-for-desired-code-replication print wrong log message
> 
>
> Key: STORM-1453
> URL: https://issues.apache.org/jira/browse/STORM-1453
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 1.0.0
>Reporter: caofangkun
>Assignee: caofangkun
>Priority: Trivial
>
> https://github.com/apache/storm/blob/master/storm-core/src/clj/backtype/storm/daemon/nimbus.clj#L516



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

[GitHub] storm pull request: [STORM-1453] nimbus.clj/wait-for-desired-code-...

[caofangkun]

GitHub user caofangkun opened a pull request:

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

[STORM-1453] nimbus.clj/wait-for-desired-code-replication print wrong log 
message



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

$ git pull https://github.com/caofangkun/apache-storm storm-1453-1

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

https://github.com/apache/storm/pull/1003.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 #1003


commit 64a57a39fe1d4b0a1f3d15a264eb3335d72e1af6
Author: ablecao 
Date:   2016-01-12T01:38:41Z

[STORM-1453] nimbus.clj/wait-for-desired-code-replication print wrong log 
message




---
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.
---

How can i monitor topology in storm ui ?

[master researcher]

Thanks in advance for any help , i have topology submitted it but need to
know if i made change int the code an need to submitted new one how can i
compare between old and new topology

should i compare between it through Executed latency only or what ?

if someone has links or vidoes for someone illustrate monitioring well ,
i'll apperciate it

Waiting Your Reply ...

Re: Java 8 for Storm 2.x?

[Jungtaek Lim]

+1 to Kyle.

Personally I was seeing many places that uses JRE 7, and some places even
uses JRE 6 yet.
Let's keep JDK 7 compatible, but borrow JDK 1.8's interface so that we can
easily migrate later.

Thanks,
Jungtaek Lim (HeartSaVioR)

On Tue, Jan 12, 2016 at 8:43 AM, P. Taylor Goetz  wrote:

> +1 for Derek and Kyle's comments.
>
> I think it's important to keep at least one level of JVM backward
> compatibility. I would love to dive straight in to JDK 1.8+, but that would
> be at the expense of users who may have infrastructure constraints that
> would prevent that.
>
> As mentioned earlier it is possible to mimick those features and APIs, and
> help pave the way for migration later. I'd be +1 for that approach.
>
> -Taylor
>
> > On Jan 11, 2016, at 5:56 PM, Kyle Nusbaum 
> wrote:
> >
> > I agree with Derek.
> > There are still a lot of people using Java 7. However, if you could make
> it sort of Java 8 compatible so that when we do move to Java 8 we can do so
> with relative ease.
> >  -- Kyle
> >
> >On Monday, January 11, 2016 4:46 PM, Derek Dagit
>  wrote:
> >
> >
> > I am not sure it makes sense to move to Java 8 merely because of the
> clojure->java translation, but it might be good timing so I would be OK
> with it.
> >
> > --
> > Derek
> >
> >
> > - Original Message -
> > From: Reza Farivar 
> > To: Dev 
> > Sent: Monday, January 11, 2016 4:40 PM
> > Subject: Java 8 for Storm 2.x?
> >
> > I have started work on translating the util.clj to java (STORM-1226). I
> see some instances when translating the functional behavior of clojure to
> Java requires code that is already part of java 8.
> > For instance, there are many cases where a predicate function is passed
> around (e.g. in find-first). I can go ahead and implement a Predicate
> interface and use that, but Java 8 has already exactly that functionality
> implemented.
> > Would it make sense to move to Java 8 for the post-clojure branch 2.x?
> > --Reza
> >
> >
>



-- 
Name : Jungtaek Lim
Blog : http://medium.com/@heartsavior
Twitter : http://twitter.com/heartsavior
LinkedIn : http://www.linkedin.com/in/heartsavior

Re: HDFS Bolts -- partitioning output

[Erik Weathers]

Awesome Aaron, I can send you what we have done offline!

- Erik

On Thu, Jan 7, 2016 at 11:12 AM, Aaron.Dossett 
wrote:

> Thanks, Erik.  Your “Partitioner” is exactly what I had in mind and even
> what I named my stubbed out interface :-)  Since Target has decided against
> this approach for other reasons, it will have to be a side project for me
> for now.
>
> Best, Aaron
>
> From: Erik Weathers 
> Reply-To: "u...@storm.apache.org" 
> Date: Wednesday, January 6, 2016 at 5:48 PM
> To: "u...@storm.apache.org" 
> Cc: "dev@storm.apache.org" 
> Subject: Re: HDFS Bolts -- partitioning output
>
> hey Aaron,
>
> We've also written a similar bolt at Groupon, we aren't super satisfied
> with the implementation though. :)  We are begrudgingly using it because
> there is no partitioning support in the OSS storm-hdfs bolt.
>
> Though one thing I do like about our implementation is having the ability
> to define your own "Partitioner" in each topology to do various types of
> partitioning (date-based, message ID-based, topic-based, whatever).  It
> would be great if your implementation had such logic too.  e.g., when
> deciding the HDFS path for a tuple's data, the Partitioner is called to
> determine the HDFS path.  For example, it can take the Tuple object and an
> opaque key/value Configuration hash that can pass items like a kafka topic
> name to be included into the HDFS path.
>
> - Erik
>
> On Tue, Dec 29, 2015 at 7:12 AM, Aaron.Dossett 
> wrote:
>
>> Hi,
>>
>> My team was exploring changes to the HDFS bolts that would allow for
>> partitioning the output, for example into directories corresponding to
>> day.  This is different that the existing functionality to rotate files
>> based on a set length of time.  For unrelated reasons, we are probably not
>> going to pursue this further.  However, I have some code changes that
>> implement most of this functionality for at least some partitioning use
>> cases.  If there is interest from the user or developer community for this
>> feature, I could get in shape for a PR to get feedback about our
>> implementation approach.
>>
>> Any feedback on this idea is welcome.  Thanks! -Aaron
>>
>
>

Re: Java 8 for Storm 2.x?

[P. Taylor Goetz]

+1 for Derek and Kyle's comments.

I think it's important to keep at least one level of JVM backward 
compatibility. I would love to dive straight in to JDK 1.8+, but that would be 
at the expense of users who may have infrastructure constraints that would 
prevent that.

As mentioned earlier it is possible to mimick those features and APIs, and help 
pave the way for migration later. I'd be +1 for that approach.

-Taylor

> On Jan 11, 2016, at 5:56 PM, Kyle Nusbaum  
> wrote:
> 
> I agree with Derek.
> There are still a lot of people using Java 7. However, if you could make it 
> sort of Java 8 compatible so that when we do move to Java 8 we can do so with 
> relative ease.
>  -- Kyle 
> 
>On Monday, January 11, 2016 4:46 PM, Derek Dagit 
>  wrote:
> 
> 
> I am not sure it makes sense to move to Java 8 merely because of the 
> clojure->java translation, but it might be good timing so I would be OK with 
> it.
> 
> -- 
> Derek
> 
> 
> - Original Message -
> From: Reza Farivar 
> To: Dev 
> Sent: Monday, January 11, 2016 4:40 PM
> Subject: Java 8 for Storm 2.x?
> 
> I have started work on translating the util.clj to java (STORM-1226). I see 
> some instances when translating the functional behavior of clojure to Java 
> requires code that is already part of java 8.
> For instance, there are many cases where a predicate function is passed 
> around (e.g. in find-first). I can go ahead and implement a Predicate 
> interface and use that, but Java 8 has already exactly that functionality 
> implemented. 
> Would it make sense to move to Java 8 for the post-clojure branch 2.x?
> --Reza 
> 
> 

Re: Java 8 for Storm 2.x?

[Kyle Nusbaum]

I agree with Derek.
There are still a lot of people using Java 7. However, if you could make it 
sort of Java 8 compatible so that when we do move to Java 8 we can do so with 
relative ease.
 -- Kyle 

On Monday, January 11, 2016 4:46 PM, Derek Dagit 
 wrote:
 

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

 -- 
Derek


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

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


  

Re: Java 8 for Storm 2.x?

[Derek Dagit]

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

 -- 
Derek


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

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

Java 8 for Storm 2.x?

[Reza Farivar]

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

1.x storm and jstorm merger

[Bobby Evans]

I think we are finally at the point were this is going to start happening.
I have merged in as many JIRA/PULL requests that looked like they were ready.  
The most disruptive of these is probably STORM-1202, which translated 
backtype.storm to org.apache.storm and storm.trident to 
org.apache.storm.trident  There is some hack code that we will remove in the 
future that when submitting a topology using the new client it will translate 
your jar for you to the new namespaces.  You can enable it by setting 
`client.jartransformer.class` to `org.apache.storm.hack.StormShadeTransformer`

With that I changed the 0.11.0 tag to 1.0.0.  And I created a branch-1.x branch 
in the main repo.  I have not started creating a release candidate just yet as 
there still are a few outstanding bugs that I would like to see resolved before 
hand.
https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20type%20%3D%20Bug%20and%20resolution%20%3D%20Unresolved%20and%20priority%20%3E%3D%20Blocker

Of them only STORM-1452 really feels like a blocker, but I am open to others 
opinions as we work towards a release.  I would encourage everyone to kick the 
tires on it and file JIRA if you do find any issues.



I also changed the version on master to 2.0.0-SNAPSHOT in preparation for the 
migration to java and the JStorm merger.  This means that we are now open to 
start pulling in java migration pull requests as outlined 
on the wiki
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=61328109
I know that my team is going to start working on this process now to try and 
shorten the time of the transition as much as possible.  From this point on 
until the transition to java is complete there will be a moratorium on new 
features going into storm.  This is not a hard moratorium.  If your changes 
only touch java code, like in the external projects, etc.  I don't think anyone 
will complain if new features go in, but this is mostly to reduce churn in the 
code so the transition is a smooth as possible.  To help with this, and because 
there was some discussion about style guidelines, etc I through together a wiki 
for some conventions/guidelines.

https://cwiki.apache.org/confluence/display/STORM/Java+Migration+Guidelines
I put it together mostly to have a place for it.  I am not religious about the 
guidelines, I just want us to have some as we go forward, and I don't really 
want to wait for someone to reformat all of the files and put checks in place 
for them.  If others disagree we can modify them as we see fit.
As far as coordination in doing the translation I will try to update the JIRAs 
that I filed to match what is currently out on master.  When you do pick up a 
JIRA to work on please assign it to yourself and move the state to "In 
Progress" so everyone knows that you are working on it.  If you want to pick up 
something but it depends on something someone else is doing and it is not being 
completed in a timely manor, please comment on the JIRA before doing anything 
to ask for a status update.  If they are unable to respond within a few days 
feel free to take over the JIRA.  I personally thing moving quickly is more 
important than hurt feelings.  So please pay attention to comments on the JIRA 
you are working on. - Bobby

[GitHub] storm pull request: Storm SQL - Storm.py 'storm sql' startup scrip...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1202) Migrate APIs to org.apache.storm, but try to provide backwards compatability as a bridge

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1202.

   Resolution: Fixed
Fix Version/s: 1.0.0

> Migrate APIs to org.apache.storm, but try to provide backwards compatability 
> as a bridge
> 
>
> Key: STORM-1202
> URL: https://issues.apache.org/jira/browse/STORM-1202
> Project: Apache Storm
>  Issue Type: New Feature
>Reporter: Robert Joseph Evans
>Assignee: Robert Joseph Evans
> Fix For: 1.0.0
>
>
> We want to move the storm classpaths to org.apache.storm wherever possible, 
> but we also want to provide backwards compatibility for user facing APIs 
> whenever possible.



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

[jira] [Commented] (STORM-1202) Migrate APIs to org.apache.storm, but try to provide backwards compatability as a bridge

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1202:
---

Github user asfgit closed the pull request at:

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


> Migrate APIs to org.apache.storm, but try to provide backwards compatability 
> as a bridge
> 
>
> Key: STORM-1202
> URL: https://issues.apache.org/jira/browse/STORM-1202
> Project: Apache Storm
>  Issue Type: New Feature
>Reporter: Robert Joseph Evans
>Assignee: Robert Joseph Evans
>
> We want to move the storm classpaths to org.apache.storm wherever possible, 
> but we also want to provide backwards compatibility for user facing APIs 
> whenever possible.



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

[GitHub] storm pull request: STORM-1202: Migrate APIs to org.apache.storm, ...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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 SQL - Storm.py 'storm sql' startup scrip...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/1001#issuecomment-170685043
  
@hmcl ah I missed the one letter diff between them.  Thanks.  +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.
---

Re: Potential license issue for storm-cassandra

[Bobby Evans]

OK Sounds good.
I'll pull the tests+dependency out myself shortly.
 - Bobby 

On Monday, January 11, 2016 1:26 PM, P. Taylor Goetz  
wrote:
 

 I’m going to punt on this. For now, let’s just remove the unit tests. We’ll 
have the history in git and can resurrect the code if the licensing situation 
changes.
Although I was able to get the tests to pass with an in-memory Cassandra 
instance, I was not able to get them to pass reliably and consistently. The 
tests were sensitive to timing and the performance of the build machine. We’ve 
made some great progress addressing some of the causes of spurious test 
failures, and I’d hate to take a step backward.
I contacted the author of cassandra-unit regarding changing the license, and he 
seems open to discussing a change in licensing [1], so there’s a chance the 
situation may change.
[1] https://github.com/jsevellec/cassandra-unit/issues/163
-Taylor


On Jan 8, 2016, at 12:23 PM, Bobby Evans  wrote:
Great to hear it.  I will wait for this to go in before I create a 1.0 branch.  
Not reason to not wait.  So now I expect to create the branch sometime Monday.
 - Bobby 

    On Thursday, January 7, 2016 2:47 PM, P. Taylor Goetz  
wrote:


 Okay, I just got all the storm-cassandra tests to pass without cassandra-unit 
by writing a quick-and-dirty embedded C* instance.

I’ve got some cleanup and refactoring to do, but it looks like a viable 
alternative. I should have a pull request up soon.

-Taylor


On Jan 7, 2016, at 2:55 PM, Bobby Evans  wrote:

That seems reasonable to me.  Thanks for looking into this Taylor.
  - Bobby

    On Wednesday, January 6, 2016 4:28 PM, P. Taylor Goetz  
wrote:


More information:

The fact that the code is in our repo is not a problem, it just means that we 
we can’t release until that is rectified by removing the LGPL dependency. When 
Storm first entered incubation we had a dependency on 0mq (LGPL), which didn’t 
stop the code from being imported into the Apache repo, but it had to be 
removed before we could officially release.

Looking at the unit tests in question, it doesn’t seem like it would be hard to 
migrate away from cassandra-unit. I’ve used cassandra-unit in the past (a while 
ago), and eventually migrated away from it by spinning up an in-memory C* 
instance and populating it with the necessary data from within the unit tests, 
which is what cassandra-unit seems to be used for here.

Florian — would you be able to help migrate off of cassandra-unit, possibly 
considering the approach I mentioned? If not I may be able to find some time to 
do it.

If for some reason we can’t migrate by the time we’re ready to release, we can 
just delete the tests/dependency. But I’d at least try to preserve/migrate them 
since I believe they have value.

-Taylor



On Jan 6, 2016, at 4:13 PM, P. Taylor Goetz  wrote:

Let me do some quick research before you rip anything out.

-Taylor


On Jan 6, 2016, at 4:10 PM, Bobby Evans  wrote:

Yes lets just remove them for now, and then file a follow up JIRA to add back 
in tests.
- Bobby

  On Wednesday, January 6, 2016 3:01 PM, Jungtaek Lim  wrote:


Sorry missed link, https://issues.apache.org/jira/browse/STORM-1445

2016년 1월 7일 (목) 오전 5:59, Jungtaek Lim 님이 작성:


Filed STORM-1445.

Seems like unit tests are completely relying on cassandra-unit.
I don't have experience with Cassandra, so I couldn't convert current
tests to not use cassandra-unit.

If we think we're fine to remove whole unit tests for storm-cassandra,
I'll remove it and submit pull request right now.
If we still need unit tests for storm-cassandra, I'd love to let sponsors
of storm-cassandra module takes care of it.
(Maybe we can file a new issue which handles new unit tests.)

Best,
Jungtaek Lim (HeartSaVioR)



2016년 1월 7일 (목) 오전 5:31, Bobby Evans 님이 작성:


Yes pull it out for now, and we may have to talk to someone in legal at
apache if there is something else we need to do.  We have not done a
release with storm-cassandra yet, so we are probably safe.  Because of that
please file a JIRA and put up a pull request like normal.
  - Bobby

    On Wednesday, January 6, 2016 7:35 AM, Jungtaek Lim <
kabh...@gmail.com> wrote:


  Hi devs,

Digging into the test failures on storm-cassandra, I saw license of
cassandra-unit is LGPL v3 by chance.

https://github.com/jsevellec/cassandra-unit

>From http://www.apache.org/legal/resolved.html, the page describes that

LGPL-licensed works must not be included in Apache Products


but I don't know much details on license so clarification would be much
appreciated.

Should we get rid of cassandra-unit? I sought the alternatives, but
nothing
found.

Best,
Jungtaek Lim (HeartSaVioR)

--
Name : Jungtaek Lim
Blog : http://medium.com/@heartsavior
Twitter : http://twitter.com/heartsavior
LinkedIn : http://www.linkedin.com/in/heartsavior




















  

[jira] [Resolved] (STORM-468) java.io.NotSerializableException should be explained

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-468.
---
   Resolution: Fixed
 Assignee: Jang-Soo Lee
Fix Version/s: 0.11.0

Thanks [~jangie],

I merged this into master.  Keep up the good work.

> java.io.NotSerializableException should be explained
> 
>
> Key: STORM-468
> URL: https://issues.apache.org/jira/browse/STORM-468
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.9.2-incubating
> Environment: Any
>Reporter: Jason Kania
>Assignee: Jang-Soo Lee
>Priority: Minor
>  Labels: newbie
> Fix For: 0.11.0
>
>
> The occurrence of the NotSerializableException and how to avoid it should be 
> better documented and the error from the code should be expanded to include 
> some human readable message because it took a lot of searching to find out 
> that the spouts and bolts need to create their variables in the prepare 
> method in order to avoid this problem.
> The error text output could state that this is how to solve the problem.



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

[jira] [Commented] (STORM-468) java.io.NotSerializableException should be explained

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-468:
--

Github user asfgit closed the pull request at:

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


> java.io.NotSerializableException should be explained
> 
>
> Key: STORM-468
> URL: https://issues.apache.org/jira/browse/STORM-468
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.9.2-incubating
> Environment: Any
>Reporter: Jason Kania
>Priority: Minor
>  Labels: newbie
>
> The occurrence of the NotSerializableException and how to avoid it should be 
> better documented and the error from the code should be expanded to include 
> some human readable message because it took a lot of searching to find out 
> that the spouts and bolts need to create their variables in the prepare 
> method in order to avoid this problem.
> The error text output could state that this is how to solve the problem.



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

[GitHub] storm pull request: [STORM-468] java.io.NotSerializableException s...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1348) Refactor API to remove Insert/Update builder in Cassandra connector

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1348.

   Resolution: Fixed
 Assignee: Satish Duggana
Fix Version/s: 0.11.0

Thanks [~satish.duggana],

I merged this into master.

> Refactor API to remove Insert/Update builder in Cassandra connector
> ---
>
> Key: STORM-1348
> URL: https://issues.apache.org/jira/browse/STORM-1348
> Project: Apache Storm
>  Issue Type: Bug
> Environment: @fhussonnois I think we should accept only cql strings 
> for now instead of giving a fluent API for building queries. This requires 
> implementing all kinds of queries supported by cql just to map column names 
> which is kind of unnecessary. Cassandra connector API should be agnostic 
> about the cql by simply using datastax driver. This avoids implementing any 
> new features being added in cql by cassandra connector APIs. We should 
> support only simple/prepared/batched statement builder by giving respective 
> API to map columns with tuples.
> https://github.com/apache/storm/pull/827#issuecomment-158807186
> @satishd, @harshach ok perfect. So I will refactor API to remove 
> Insert/Update builder. 
> https://github.com/apache/storm/pull/827#issuecomment-159316692
>Reporter: Satish Duggana
>Assignee: Satish Duggana
> Fix For: 0.11.0
>
>




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

[jira] [Commented] (STORM-1348) Refactor API to remove Insert/Update builder in Cassandra connector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1348:
---

Github user asfgit closed the pull request at:

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


> Refactor API to remove Insert/Update builder in Cassandra connector
> ---
>
> Key: STORM-1348
> URL: https://issues.apache.org/jira/browse/STORM-1348
> Project: Apache Storm
>  Issue Type: Bug
> Environment: @fhussonnois I think we should accept only cql strings 
> for now instead of giving a fluent API for building queries. This requires 
> implementing all kinds of queries supported by cql just to map column names 
> which is kind of unnecessary. Cassandra connector API should be agnostic 
> about the cql by simply using datastax driver. This avoids implementing any 
> new features being added in cql by cassandra connector APIs. We should 
> support only simple/prepared/batched statement builder by giving respective 
> API to map columns with tuples.
> https://github.com/apache/storm/pull/827#issuecomment-158807186
> @satishd, @harshach ok perfect. So I will refactor API to remove 
> Insert/Update builder. 
> https://github.com/apache/storm/pull/827#issuecomment-159316692
>Reporter: Satish Duggana
>




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

[GitHub] storm pull request: STORM-1348 - refactor API to remove Insert/Upd...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1348) Refactor API to remove Insert/Update builder in Cassandra connector

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1348:
---

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/929#issuecomment-170677546
  
+1


> Refactor API to remove Insert/Update builder in Cassandra connector
> ---
>
> Key: STORM-1348
> URL: https://issues.apache.org/jira/browse/STORM-1348
> Project: Apache Storm
>  Issue Type: Bug
> Environment: @fhussonnois I think we should accept only cql strings 
> for now instead of giving a fluent API for building queries. This requires 
> implementing all kinds of queries supported by cql just to map column names 
> which is kind of unnecessary. Cassandra connector API should be agnostic 
> about the cql by simply using datastax driver. This avoids implementing any 
> new features being added in cql by cassandra connector APIs. We should 
> support only simple/prepared/batched statement builder by giving respective 
> API to map columns with tuples.
> https://github.com/apache/storm/pull/827#issuecomment-158807186
> @satishd, @harshach ok perfect. So I will refactor API to remove 
> Insert/Update builder. 
> https://github.com/apache/storm/pull/827#issuecomment-159316692
>Reporter: Satish Duggana
>




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

[GitHub] storm pull request: STORM-1348 - refactor API to remove Insert/Upd...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/929#issuecomment-170677546
  
+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] [Resolved] (STORM-1206) Reduce logviewer memory usage

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1206.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~zhuoliu],

I merged this into master.

> Reduce logviewer memory usage
> -
>
> Key: STORM-1206
> URL: https://issues.apache.org/jira/browse/STORM-1206
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Reporter: Zhuo Liu
>Assignee: Zhuo Liu
>Priority: Minor
> Fix For: 0.11.0
>
>
> In production, we ran into an issue with logviewers bouncing with out of 
> memory errors. Note that this happens very rarely, we met this in some 
> extreme case when super frequently restarting of workers generates a huge 
> number of gc files (~1M files).
> What was happening is that if there are lots of log files (~1 M files) for a 
> particular headless user, we would have so many strings resident in memory 
> that logviewer would run out of heap space.
> We were able to work around this by increasing the heap space, but we should 
> consider putting some sort of an upper bound on the number of files so that 
> we don't run in to this issue, even with the bigger heap.
> Using the java DirectoryStream can avoid holding all file names in memory 
> during file listing. Also, a multi-round directory cleaner can be introduced 
> to delete files while disk quota is exceeded.



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

[GitHub] storm pull request: [STORM-1206] Reduce logviewer memory usage thr...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1206) Reduce logviewer memory usage

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1206:
---

Github user asfgit closed the pull request at:

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


> Reduce logviewer memory usage
> -
>
> Key: STORM-1206
> URL: https://issues.apache.org/jira/browse/STORM-1206
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Reporter: Zhuo Liu
>Assignee: Zhuo Liu
>Priority: Minor
>
> In production, we ran into an issue with logviewers bouncing with out of 
> memory errors. Note that this happens very rarely, we met this in some 
> extreme case when super frequently restarting of workers generates a huge 
> number of gc files (~1M files).
> What was happening is that if there are lots of log files (~1 M files) for a 
> particular headless user, we would have so many strings resident in memory 
> that logviewer would run out of heap space.
> We were able to work around this by increasing the heap space, but we should 
> consider putting some sort of an upper bound on the number of files so that 
> we don't run in to this issue, even with the bigger heap.
> Using the java DirectoryStream can avoid holding all file names in memory 
> during file listing. Also, a multi-round directory cleaner can be introduced 
> to delete files while disk quota is exceeded.



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

[jira] [Assigned] (STORM-1227) port backtype.storm.config to java

[Zhuo Liu (JIRA)]

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

Zhuo Liu reassigned STORM-1227:
---

Assignee: Zhuo Liu

> port backtype.storm.config to java
> --
>
> Key: STORM-1227
> URL: https://issues.apache.org/jira/browse/STORM-1227
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>Assignee: Zhuo Liu
>  Labels: java-migration, jstorm-merger
>
> port backtype.storm.config to java.  There are some parts of this that for 
> convince sake may need to stay in clojure, or have clojure equivalents.
> The code that turns Config.* into clojure constants needs to stay, and 
> reading the config may need to stay in clojure until we can cleanup all of 
> the places it is used to not need the migration.



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

[jira] [Assigned] (STORM-1226) Port backtype.storm.util to java

[Reza Farivar (JIRA)]

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

Reza Farivar reassigned STORM-1226:
---

Assignee: Reza Farivar

> Port backtype.storm.util to java
> 
>
> Key: STORM-1226
> URL: https://issues.apache.org/jira/browse/STORM-1226
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>Assignee: Reza Farivar
>  Labels: java-migration, jstorm-merger
>
> Port backtype.storm.util from clojure to java.  In as many instances as 
> possible the same interface should be maintained, and calls to clojure 
> functions in the rest of the code should be replaces with calls to the 
> corresponding java code.
> Some similar functions can be found at  
> https://github.com/apache/storm/blob/jstorm-import/jstorm-core/src/main/java/com/alibaba/jstorm/utils/JStormUtils.java
> Although they are not identical.
> For function callbacks we may need to evaluate adding in appropriate callback 
> interfaces instead.  Please try to avoid using clojure internal java classes 
> unless necessary.



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

[jira] [Commented] (STORM-1226) Port backtype.storm.util to java

[Reza Farivar (JIRA)]

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

Reza Farivar commented on STORM-1226:
-

In the first pass, we'll leave the defmacros alone. We'll get back to them 
later on as need be. 

> Port backtype.storm.util to java
> 
>
> Key: STORM-1226
> URL: https://issues.apache.org/jira/browse/STORM-1226
> Project: Apache Storm
>  Issue Type: New Feature
>  Components: storm-core
>Reporter: Robert Joseph Evans
>Assignee: Reza Farivar
>  Labels: java-migration, jstorm-merger
>
> Port backtype.storm.util from clojure to java.  In as many instances as 
> possible the same interface should be maintained, and calls to clojure 
> functions in the rest of the code should be replaces with calls to the 
> corresponding java code.
> Some similar functions can be found at  
> https://github.com/apache/storm/blob/jstorm-import/jstorm-core/src/main/java/com/alibaba/jstorm/utils/JStormUtils.java
> Although they are not identical.
> For function callbacks we may need to evaluate adding in appropriate callback 
> interfaces instead.  Please try to avoid using clojure internal java classes 
> unless necessary.



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

Re: Potential license issue for storm-cassandra

[P. Taylor Goetz]

I’m going to punt on this. For now, let’s just remove the unit tests. We’ll 
have the history in git and can resurrect the code if the licensing situation 
changes.

Although I was able to get the tests to pass with an in-memory Cassandra 
instance, I was not able to get them to pass reliably and consistently. The 
tests were sensitive to timing and the performance of the build machine. We’ve 
made some great progress addressing some of the causes of spurious test 
failures, and I’d hate to take a step backward.

I contacted the author of cassandra-unit regarding changing the license, and he 
seems open to discussing a change in licensing [1], so there’s a chance the 
situation may change.

[1] https://github.com/jsevellec/cassandra-unit/issues/163 


-Taylor


> On Jan 8, 2016, at 12:23 PM, Bobby Evans  wrote:
> 
> Great to hear it.  I will wait for this to go in before I create a 1.0 
> branch.  Not reason to not wait.  So now I expect to create the branch 
> sometime Monday.
>  - Bobby
> 
>On Thursday, January 7, 2016 2:47 PM, P. Taylor Goetz  
> wrote:
> 
> 
> Okay, I just got all the storm-cassandra tests to pass without cassandra-unit 
> by writing a quick-and-dirty embedded C* instance.
> 
> I’ve got some cleanup and refactoring to do, but it looks like a viable 
> alternative. I should have a pull request up soon.
> 
> -Taylor
> 
>> On Jan 7, 2016, at 2:55 PM, Bobby Evans  wrote:
>> 
>> That seems reasonable to me.  Thanks for looking into this Taylor.
>>   - Bobby
>> 
>> On Wednesday, January 6, 2016 4:28 PM, P. Taylor Goetz 
>>  wrote:
>> 
>> 
>> More information:
>> 
>> The fact that the code is in our repo is not a problem, it just means that 
>> we we can’t release until that is rectified by removing the LGPL dependency. 
>> When Storm first entered incubation we had a dependency on 0mq (LGPL), which 
>> didn’t stop the code from being imported into the Apache repo, but it had to 
>> be removed before we could officially release.
>> 
>> Looking at the unit tests in question, it doesn’t seem like it would be hard 
>> to migrate away from cassandra-unit. I’ve used cassandra-unit in the past (a 
>> while ago), and eventually migrated away from it by spinning up an in-memory 
>> C* instance and populating it with the necessary data from within the unit 
>> tests, which is what cassandra-unit seems to be used for here.
>> 
>> Florian — would you be able to help migrate off of cassandra-unit, possibly 
>> considering the approach I mentioned? If not I may be able to find some time 
>> to do it.
>> 
>> If for some reason we can’t migrate by the time we’re ready to release, we 
>> can just delete the tests/dependency. But I’d at least try to 
>> preserve/migrate them since I believe they have value.
>> 
>> -Taylor
>> 
>> 
>>> On Jan 6, 2016, at 4:13 PM, P. Taylor Goetz  wrote:
>>> 
>>> Let me do some quick research before you rip anything out.
>>> 
>>> -Taylor
>>> 
 On Jan 6, 2016, at 4:10 PM, Bobby Evans  
 wrote:
 
 Yes lets just remove them for now, and then file a follow up JIRA to add 
 back in tests.
 - Bobby
 
   On Wednesday, January 6, 2016 3:01 PM, Jungtaek Lim  
 wrote:
 
 
 Sorry missed link, https://issues.apache.org/jira/browse/STORM-1445
 
 2016년 1월 7일 (목) 오전 5:59, Jungtaek Lim 님이 작성:
 
> Filed STORM-1445.
> 
> Seems like unit tests are completely relying on cassandra-unit.
> I don't have experience with Cassandra, so I couldn't convert current
> tests to not use cassandra-unit.
> 
> If we think we're fine to remove whole unit tests for storm-cassandra,
> I'll remove it and submit pull request right now.
> If we still need unit tests for storm-cassandra, I'd love to let sponsors
> of storm-cassandra module takes care of it.
> (Maybe we can file a new issue which handles new unit tests.)
> 
> Best,
> Jungtaek Lim (HeartSaVioR)
> 
> 
> 
> 2016년 1월 7일 (목) 오전 5:31, Bobby Evans 님이 작성:
> 
>> Yes pull it out for now, and we may have to talk to someone in legal at
>> apache if there is something else we need to do.  We have not done a
>> release with storm-cassandra yet, so we are probably safe.  Because of 
>> that
>> please file a JIRA and put up a pull request like normal.
>>   - Bobby
>> 
>> On Wednesday, January 6, 2016 7:35 AM, Jungtaek Lim <
>> kabh...@gmail.com> wrote:
>> 
>> 
>>   Hi devs,
>> 
>> Digging into the test failures on storm-cassandra, I saw license of
>> cassandra-unit is LGPL v3 by chance.
>> 
>> https://github.com/jsevellec/cassandra-unit
>> 
>> From http://www.apache.org/legal/resolved.html, the page describes that
>> 
>> LGPL-licensed works must not be included in Apache Products
>> 
>> 
>> but I don't know much details on license so clarification would be much
>> appreci

[GitHub] storm pull request: Storm SQL - Storm.py 'storm sql' startup scrip...

[hmcl]

Github user hmcl commented on the pull request:

https://github.com/apache/storm/pull/1001#issuecomment-170661183
  
@revans2 without this fix the command line option 'storm sql' is broken. 
The reason it is broken is because prior to this change the method parameter 
'topo_nam' is referred as 'topo_name' in the method body, hence the script does 
not run and this change is required. Initially I changed the parameter method 
parameter to 'topo_name', but following @satishd suggestion, we agreed on 
renaming 'topology_name'


---
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 SQL - Storm.py 'storm sql' startup scrip...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/1001#issuecomment-170656306
  
@hmcl the change itself looks OK, but I am not really sure what/how this 
fixes anything.  You rearranged the order of imports and renamed a variable.  
Can you explain what was failing before and what is fixed now?


---
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] [Resolved] (STORM-1219) Fix HDFS and Hive bolt flush/acking

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1219.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~arunmahadevan],

I merged this into master.

> Fix HDFS and Hive bolt flush/acking
> ---
>
> Key: STORM-1219
> URL: https://issues.apache.org/jira/browse/STORM-1219
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Fix For: 0.11.0
>
>
> HDFS and Hive bolts is setting the default tick tuple interval in the 
> prepare() method, which is not taking effect. This needs to be fixed so that 
> the tuples are acked on time.



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

[jira] [Commented] (STORM-1219) Fix HDFS and Hive bolt flush/acking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1219:
---

Github user asfgit closed the pull request at:

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


> Fix HDFS and Hive bolt flush/acking
> ---
>
> Key: STORM-1219
> URL: https://issues.apache.org/jira/browse/STORM-1219
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Fix For: 0.11.0
>
>
> HDFS and Hive bolts is setting the default tick tuple interval in the 
> prepare() method, which is not taking effect. This needs to be fixed so that 
> the tuples are acked on time.



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

[GitHub] storm pull request: STORM-1219: Fix HDFS and Hive bolt flush/ackin...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1150) The authorization mode of Logviewer is not working well when I add other groups for log

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1150.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~rujia1019],

I merged this into master.

> The authorization  mode of Logviewer is not working well when I add other 
> groups for log
> 
>
> Key: STORM-1150
> URL: https://issues.apache.org/jira/browse/STORM-1150
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.0
>Reporter: rujia
>Assignee: rujia
> Fix For: 0.11.0
>
>
> I add a super group for logviewer with codes :
> (defn authorized-log-user? [user fname conf]
>   (if (or (blank? user) (blank? fname))
> nil
> (let [groups (user-groups user)
>   [user-wl group-wl] (get-log-user-group-whitelist conf fname)
>   logs-users (concat (conf LOGS-USERS)
>  (conf NIMBUS-ADMINS)
>  user-wl)
>   logs-groups (concat (conf LOGS-GROUPS)
>   (conf NIMBUS-ADMIN-GROUPS)   //my super group
>   group-wl)]
>(or (some #(= % user) logs-users)
>(< 0 (.size (intersection (set groups) (set group-wl
> maybe the "(set group-wl)" should be "(set  logs-groups)"?



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

[GitHub] storm pull request: [storm-1150]Fix the authorization of Logviewer...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1418) improve debug logs for some external modules

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1418.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~vesense],

I merged this to master.  There was a very minor merge conflict, but I it was 
just a new line added next to one you changed so I just resolved it.

> improve debug logs for some external modules
> 
>
> Key: STORM-1418
> URL: https://issues.apache.org/jira/browse/STORM-1418
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-hbase, storm-hive, storm-kafka
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 0.11.0
>
>




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

[jira] [Commented] (STORM-1418) improve debug logs for some external modules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1418:
---

Github user asfgit closed the pull request at:

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


> improve debug logs for some external modules
> 
>
> Key: STORM-1418
> URL: https://issues.apache.org/jira/browse/STORM-1418
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-hbase, storm-hive, storm-kafka
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
>




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

[GitHub] storm pull request: [STORM-1418] improve debug logs for some exter...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1415) Some improvements for trident map StateUpdater

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1415:
---

Github user asfgit closed the pull request at:

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


> Some improvements for trident map StateUpdater
> --
>
> Key: STORM-1415
> URL: https://issues.apache.org/jira/browse/STORM-1415
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 0.11.0
>
>
> Changes are the following:
> 1.Add a generated serialVersionUID
> 2.Remove unused variables 'groups' & 'values'
> 3.Add <> in order to pass compiler type check
> 4.Fix newline and whitespaces



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

[jira] [Resolved] (STORM-1415) Some improvements for trident map StateUpdater

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1415.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~vesense],

I merged this into master.

> Some improvements for trident map StateUpdater
> --
>
> Key: STORM-1415
> URL: https://issues.apache.org/jira/browse/STORM-1415
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 0.11.0
>
>
> Changes are the following:
> 1.Add a generated serialVersionUID
> 2.Remove unused variables 'groups' & 'values'
> 3.Add <> in order to pass compiler type check
> 4.Fix newline and whitespaces



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

[GitHub] storm pull request: [STORM-1415] Some improvements for trident map...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1414) Some improvements for multilang JsonSerializer

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1414.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~vesense],

I merged this into master.

> Some improvements for multilang JsonSerializer
> --
>
> Key: STORM-1414
> URL: https://issues.apache.org/jira/browse/STORM-1414
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-multilang
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 0.11.0
>
>
> Changes are the following:
> 1.Add a generated serialVersionUID & default charset 'UTF-8'
> 2.Use BufferedWriter for writing data
> 3.Remove unused variable 'anchors'



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

[GitHub] storm pull request: [STORM-1414] Some improvements for multilang J...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1414) Some improvements for multilang JsonSerializer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1414:
---

Github user asfgit closed the pull request at:

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


> Some improvements for multilang JsonSerializer
> --
>
> Key: STORM-1414
> URL: https://issues.apache.org/jira/browse/STORM-1414
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-multilang
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
>
> Changes are the following:
> 1.Add a generated serialVersionUID & default charset 'UTF-8'
> 2.Use BufferedWriter for writing data
> 3.Remove unused variable 'anchors'



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

[GitHub] storm pull request: [STORM-1425] Tick tuples must be acked like no...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1408) storm-hdfs tests are not cleaned up maven clean:clean does not delete build directory

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1408.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~dagit],

I merged this to master

> storm-hdfs tests are not cleaned up maven clean:clean does not delete build 
> directory
> -
>
> Key: STORM-1408
> URL: https://issues.apache.org/jira/browse/STORM-1408
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-hdfs
>Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
> Fix For: 0.11.0
>
>




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

[GitHub] storm pull request: [STORM-1408] clean up the build directory crea...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1408) storm-hdfs tests are not cleaned up maven clean:clean does not delete build directory

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1408:
---

Github user asfgit closed the pull request at:

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


> storm-hdfs tests are not cleaned up maven clean:clean does not delete build 
> directory
> -
>
> Key: STORM-1408
> URL: https://issues.apache.org/jira/browse/STORM-1408
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-hdfs
>Reporter: Derek Dagit
>Assignee: Derek Dagit
>Priority: Minor
>




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

[jira] [Resolved] (STORM-1425) Tick tuples must be acked like "normal" tuples

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1425.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~vesense],

I merged this into master


> Tick tuples must be acked like "normal" tuples
> --
>
> Key: STORM-1425
> URL: https://issues.apache.org/jira/browse/STORM-1425
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Xin Wang
>Assignee: Xin Wang
> Fix For: 0.11.0
>
>
> Since HBaseBolt,HiveBolt,AbstractHdfsBolt are extending BaseRichBolt, I think 
> we should perform a collector.ack(input) before return. Tick tuples must be 
> acked like "normal" tuples.



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

[jira] [Commented] (STORM-1425) Tick tuples must be acked like "normal" tuples

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1425:
---

Github user asfgit closed the pull request at:

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


> Tick tuples must be acked like "normal" tuples
> --
>
> Key: STORM-1425
> URL: https://issues.apache.org/jira/browse/STORM-1425
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Xin Wang
>Assignee: Xin Wang
> Fix For: 0.11.0
>
>
> Since HBaseBolt,HiveBolt,AbstractHdfsBolt are extending BaseRichBolt, I think 
> we should perform a collector.ack(input) before return. Tick tuples must be 
> acked like "normal" tuples.



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

[jira] [Resolved] (STORM-1432) Spurious failure in storm-kafka test

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1432.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~knusbaum],

I merged this into master.


> Spurious failure in storm-kafka test
> 
>
> Key: STORM-1432
> URL: https://issues.apache.org/jira/browse/STORM-1432
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Kyle Nusbaum
>Assignee: Kyle Nusbaum
> Fix For: 0.11.0
>
>
> ExponentialBackoffMsgRetryManagerTest.testMaxBackoff() fails sometimes, I 
> think due to too small times. It can miss the mark on slow machines.



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

[jira] [Commented] (STORM-1432) Spurious failure in storm-kafka test

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1432:
---

Github user asfgit closed the pull request at:

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


> Spurious failure in storm-kafka test
> 
>
> Key: STORM-1432
> URL: https://issues.apache.org/jira/browse/STORM-1432
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Kyle Nusbaum
>Assignee: Kyle Nusbaum
> Fix For: 0.11.0
>
>
> ExponentialBackoffMsgRetryManagerTest.testMaxBackoff() fails sometimes, I 
> think due to too small times. It can miss the mark on slow machines.



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

[GitHub] storm pull request: STORM-1432: Spurious failure in storm-kafka te...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1499] Fix Kafka spout to maintain backw...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/994#issuecomment-170614876
  
Looks like this is for https://issues.apache.org/jira/browse/STORM-1449 not 
1499.


---
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-1219) Fix HDFS and Hive bolt flush/acking

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1219:
---

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/893#issuecomment-170617085
  
+1


> Fix HDFS and Hive bolt flush/acking
> ---
>
> Key: STORM-1219
> URL: https://issues.apache.org/jira/browse/STORM-1219
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
>
> HDFS and Hive bolts is setting the default tick tuple interval in the 
> prepare() method, which is not taking effect. This needs to be fixed so that 
> the tuples are acked on time.



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

[GitHub] storm pull request: STORM-1219: Fix HDFS and Hive bolt flush/ackin...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/893#issuecomment-170617085
  
+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-1449) Fix Kafka spout to maintain backward compatibility to pass byte[] instead of ByteBuffer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1449:
---

Github user arunmahadevan commented on the pull request:

https://github.com/apache/storm/pull/994#issuecomment-170616167
  
Sorry for the typo, changed the subject.


> Fix Kafka spout to maintain backward compatibility to pass byte[] instead of 
> ByteBuffer
> ---
>
> Key: STORM-1449
> URL: https://issues.apache.org/jira/browse/STORM-1449
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Fix For: 0.11.0
>
>
> STORM-1220 introduced some changes where in one place it passes ByteBuffer as 
> is instead of byte[]. Existing bolts that expects a byte[] fails due to this 
> with "java.lang.RuntimeException: java.lang.ClassCastException: 
> java.nio.HeapByteBuffer cannot be cast to [B "



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

[GitHub] storm pull request: [STORM-1449] Fix Kafka spout to maintain backw...

[arunmahadevan]

Github user arunmahadevan commented on the pull request:

https://github.com/apache/storm/pull/994#issuecomment-170616167
  
Sorry for the typo, changed the subject.


---
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-1499] Fix Kafka spout to maintain backw...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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] [Resolved] (STORM-1449) Fix Kafka spout to maintain backward compatibility to pass byte[] instead of ByteBuffer

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1449.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~arunmahadevan],

I merged this into master.

> Fix Kafka spout to maintain backward compatibility to pass byte[] instead of 
> ByteBuffer
> ---
>
> Key: STORM-1449
> URL: https://issues.apache.org/jira/browse/STORM-1449
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Arun Mahadevan
>Assignee: Arun Mahadevan
> Fix For: 0.11.0
>
>
> STORM-1220 introduced some changes where in one place it passes ByteBuffer as 
> is instead of byte[]. Existing bolts that expects a byte[] fails due to this 
> with "java.lang.RuntimeException: java.lang.ClassCastException: 
> java.nio.HeapByteBuffer cannot be cast to [B "



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

[jira] [Resolved] (STORM-1458) Add check to see if nimbus is already running.

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1458.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~pshah],

I merged this into master.

> Add check to see if nimbus is already running.
> --
>
> Key: STORM-1458
> URL: https://issues.apache.org/jira/browse/STORM-1458
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Priyank Shah
>Assignee: Priyank Shah
> Fix For: 0.11.0
>
>
> Adding a validation to ensure if a nimbus is already running another nimbus 
> fails on startup before modifying any zookeeper state.



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

[GitHub] storm pull request: STORM-1458: Add check to see if nimbus is alre...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1458) Add check to see if nimbus is already running.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1458:
---

Github user asfgit closed the pull request at:

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


> Add check to see if nimbus is already running.
> --
>
> Key: STORM-1458
> URL: https://issues.apache.org/jira/browse/STORM-1458
> Project: Apache Storm
>  Issue Type: Bug
>Reporter: Priyank Shah
>Assignee: Priyank Shah
>
> Adding a validation to ensure if a nimbus is already running another nimbus 
> fails on startup before modifying any zookeeper state.



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

[jira] [Resolved] (STORM-1462) Upgrade HikariCP to 2.4.3

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1462.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~vesense],

I merged this into master.

> Upgrade HikariCP to 2.4.3
> -
>
> Key: STORM-1462
> URL: https://issues.apache.org/jira/browse/STORM-1462
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-jdbc
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 0.11.0
>
>
> HikariCP 2.4.3 released on 3 Dec 2015.
> It contains some bug fixes, applies some performance improvements .
> https://github.com/brettwooldridge/HikariCP/blob/dev/CHANGES



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

[jira] [Commented] (STORM-1462) Upgrade HikariCP to 2.4.3

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1462:
---

Github user asfgit closed the pull request at:

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


> Upgrade HikariCP to 2.4.3
> -
>
> Key: STORM-1462
> URL: https://issues.apache.org/jira/browse/STORM-1462
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-jdbc
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
> Fix For: 0.11.0
>
>
> HikariCP 2.4.3 released on 3 Dec 2015.
> It contains some bug fixes, applies some performance improvements .
> https://github.com/brettwooldridge/HikariCP/blob/dev/CHANGES



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

[GitHub] storm pull request: [STORM-1462] Upgrade HikariCP to 2.4.3

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-676) Storm Trident support sliding windows

[Arun Mahadevan (JIRA)]

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

Arun Mahadevan commented on STORM-676:
--

[~satish.duggana] do you have any results from prototype that could help in 
validating the feasibility of the approach you have mentioned? Like if saving 
all the TridentTuples in a storage would scale and/or affect the trident 
performance etc ?. This might help you to finalize the current approach, fine 
tune your design and/or explore alternatives.

> Storm Trident support sliding windows
> -
>
> Key: STORM-676
> URL: https://issues.apache.org/jira/browse/STORM-676
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Reporter: Sriharsha Chintalapani
>Assignee: Satish Duggana
> Attachments: StormTrident_windowing_support-676.pdf
>
>




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

[jira] [Resolved] (STORM-1457) Avoid Unnecessary caching of tuples by executor

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1457.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~kishorvpatil],

I merged this into master.

> Avoid Unnecessary caching of tuples by executor
> ---
>
> Key: STORM-1457
> URL: https://issues.apache.org/jira/browse/STORM-1457
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Reporter: Kishor Patil
>Assignee: Kishor Patil
> Fix For: 0.11.0
>
>
> It looks like the pending RotatingMap is caching list of tuples for printing 
> debug message, but it is not required if "topology.debug" is turned off.



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

[GitHub] storm pull request: [STORM-1457] Avoid collecting pending tuples i...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1457) Avoid Unnecessary caching of tuples by executor

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1457:
---

Github user asfgit closed the pull request at:

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


> Avoid Unnecessary caching of tuples by executor
> ---
>
> Key: STORM-1457
> URL: https://issues.apache.org/jira/browse/STORM-1457
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Reporter: Kishor Patil
>Assignee: Kishor Patil
>
> It looks like the pending RotatingMap is caching list of tuples for printing 
> debug message, but it is not required if "topology.debug" is turned off.



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

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

[Derek Dagit (JIRA)]

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

Derek Dagit reassigned STORM-1452:
--

Assignee: Derek Dagit

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



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

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

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1430.

   Resolution: Fixed
Fix Version/s: 0.11.0

Thanks [~dagit],

I merged this into master.

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



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

[GitHub] storm pull request: [STORM-1430] ui worker checkboxes

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1430) UI Worker Functions: Replace pick-list with buttons

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1430:
---

Github user asfgit closed the pull request at:

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


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



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

[GitHub] storm pull request: Storm 1379 Removed Redundant Structure

[kishorvpatil]

Github user kishorvpatil commented on the pull request:

https://github.com/apache/storm/pull/932#issuecomment-170591998
  
@darionyaphet Could you please take care of merge conflicts? 


---
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-1150]Fix the authorization of Logviewer...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/948#issuecomment-170591893
  
+1.  great catch @rujia1019 


---
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-1418) improve debug logs for some external modules

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1418:
---

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/976#issuecomment-170591402
  
+1


> improve debug logs for some external modules
> 
>
> Key: STORM-1418
> URL: https://issues.apache.org/jira/browse/STORM-1418
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-hbase, storm-hive, storm-kafka
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
>




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

[GitHub] storm pull request: [STORM-1415] Some improvements for trident map...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/973#issuecomment-170591310
  
+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.
---

[GitHub] storm pull request: [STORM-1418] improve debug logs for some exter...

[revans2]

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/976#issuecomment-170591402
  
+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-1415) Some improvements for trident map StateUpdater

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1415:
---

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/973#issuecomment-170591310
  
+1


> Some improvements for trident map StateUpdater
> --
>
> Key: STORM-1415
> URL: https://issues.apache.org/jira/browse/STORM-1415
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-core
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
>
> Changes are the following:
> 1.Add a generated serialVersionUID
> 2.Remove unused variables 'groups' & 'values'
> 3.Add <> in order to pass compiler type check
> 4.Fix newline and whitespaces



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

[jira] [Resolved] (STORM-1423) storm UI in a secure env shows error even when credentials are present

[Robert Joseph Evans (JIRA)]

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

Robert Joseph Evans resolved STORM-1423.

Resolution: Fixed

Thanks [~parth.brahmbhatt],

I merged this into master.

> storm UI in a secure env shows error even when credentials are present
> --
>
> Key: STORM-1423
> URL: https://issues.apache.org/jira/browse/STORM-1423
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.1
>Reporter: Parth Brahmbhatt
>Assignee: Parth Brahmbhatt
> Fix For: 0.11.0
>
>
> storm UI in a secure env shows error even when credentials are present



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

[GitHub] storm pull request: STORM-1423: storm UI in a secure env shows err...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-1414) Some improvements for multilang JsonSerializer

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1414:
---

Github user revans2 commented on the pull request:

https://github.com/apache/storm/pull/972#issuecomment-170590438
  
+1


> Some improvements for multilang JsonSerializer
> --
>
> Key: STORM-1414
> URL: https://issues.apache.org/jira/browse/STORM-1414
> Project: Apache Storm
>  Issue Type: Improvement
>  Components: storm-multilang
>Reporter: Xin Wang
>Assignee: Xin Wang
>Priority: Minor
>
> Changes are the following:
> 1.Add a generated serialVersionUID & default charset 'UTF-8'
> 2.Use BufferedWriter for writing data
> 3.Remove unused variable 'anchors'



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

[jira] [Commented] (STORM-1423) storm UI in a secure env shows error even when credentials are present

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on STORM-1423:
---

Github user asfgit closed the pull request at:

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


> storm UI in a secure env shows error even when credentials are present
> --
>
> Key: STORM-1423
> URL: https://issues.apache.org/jira/browse/STORM-1423
> Project: Apache Storm
>  Issue Type: Bug
>  Components: storm-core
>Affects Versions: 0.10.1
>Reporter: Parth Brahmbhatt
>Assignee: Parth Brahmbhatt
> Fix For: 0.11.0
>
>
> storm UI in a secure env shows error even when credentials are present



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