[jira] [Commented] (EAGLE-592) Add a hdfs audit log parser which consumes message in Json format

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15557298#comment-15557298
 ] 

ASF GitHub Bot commented on EAGLE-592:
--

GitHub user qingwen220 opened a pull request:

https://github.com/apache/incubator-eagle/pull/477

EAGLE-592: add MessageJsonScheme which extracts audit log from a json 
formatted …

https://issues.apache.org/jira/browse/EAGLE-592



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

$ git pull https://github.com/qingwen220/incubator-eagle EAGLE-592

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

https://github.com/apache/incubator-eagle/pull/477.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 #477


commit 107bedceba73305163b3487bd94ed36cccaa2efd
Author: Zhao, Qingwen 
Date:   2016-10-08T05:49:26Z

add MessageJsonScheme which extracts audit log from a json formatted message




> Add a hdfs audit log parser which consumes message in Json format
> -
>
> Key: EAGLE-592
> URL: https://issues.apache.org/jira/browse/EAGLE-592
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.5.0
>Reporter: Zhao, Qingwen
>Assignee: Zhao, Qingwen
> Fix For: v0.5.0
>
>
> For some log collector agents, like filebeat (5.0), the output is in json 
> format. 
> {"xx": "abc", "yy": "aabbcc", "message": "audit log"}
> This ticket will create a class MessageJsonScheme which will extract 
> 'message' field from the message from Kafka



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

[GitHub] incubator-eagle pull request #477: EAGLE-592: add MessageJsonScheme which ex...

[qingwen220]

GitHub user qingwen220 opened a pull request:

https://github.com/apache/incubator-eagle/pull/477

EAGLE-592: add MessageJsonScheme which extracts audit log from a json 
formatted …

https://issues.apache.org/jira/browse/EAGLE-592



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

$ git pull https://github.com/qingwen220/incubator-eagle EAGLE-592

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

https://github.com/apache/incubator-eagle/pull/477.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 #477


commit 107bedceba73305163b3487bd94ed36cccaa2efd
Author: Zhao, Qingwen 
Date:   2016-10-08T05:49:26Z

add MessageJsonScheme which extracts audit log from a json formatted 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.
---

[jira] [Created] (EAGLE-592) Add a hdfs audit log parser which consumes message in Json format

[Zhao, Qingwen (JIRA)]

Zhao, Qingwen created EAGLE-592:
---

 Summary: Add a hdfs audit log parser which consumes message in 
Json format
 Key: EAGLE-592
 URL: https://issues.apache.org/jira/browse/EAGLE-592
 Project: Eagle
  Issue Type: Improvement
Affects Versions: v0.5.0
Reporter: Zhao, Qingwen
Assignee: Zhao, Qingwen
 Fix For: v0.5.0


For some log collector agents, like filebeat (5.0), the output is in json 
format. 

{"xx": "abc", "yy": "aabbcc", "message": "audit log"}

This ticket will create a class MessageJsonScheme which will extract 'message' 
field from the message from Kafka





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

[jira] [Updated] (EAGLE-533) Fix storage configuration and remove AppJUnitRunner

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-533:
---
Description: Run 

> Fix storage configuration and remove AppJUnitRunner
> ---
>
> Key: EAGLE-533
> URL: https://issues.apache.org/jira/browse/EAGLE-533
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.4.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Run 



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

[jira] [Updated] (EAGLE-533) Fix storage configuration and remove AppJUnitRunner

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-533:
---
Description: Run AppJUnitRunner as junit may cause conflict exception.  
(was: Run )

> Fix storage configuration and remove AppJUnitRunner
> ---
>
> Key: EAGLE-533
> URL: https://issues.apache.org/jira/browse/EAGLE-533
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.4.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Run AppJUnitRunner as junit may cause conflict exception.



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

[jira] [Updated] (EAGLE-533) Fix storage configuration and remove AppJUnitRunner

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-533:
---
Description: Run AppJUnitRunner as junit may cause conflict exception and 
involve dependency issue in storm topology.  (was: Run AppJUnitRunner as junit 
may cause conflict exception.)

> Fix storage configuration and remove AppJUnitRunner
> ---
>
> Key: EAGLE-533
> URL: https://issues.apache.org/jira/browse/EAGLE-533
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.4.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Run AppJUnitRunner as junit may cause conflict exception and involve 
> dependency issue in storm topology.



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

[jira] [Updated] (EAGLE-534) Integrate typesafe-config with DropWizard

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-534:
---
Description: Eagle server mix YAML and typesafe-config, it's a little 
tricky, better solution is to use consistent configuration library.

> Integrate typesafe-config with DropWizard
> -
>
> Key: EAGLE-534
> URL: https://issues.apache.org/jira/browse/EAGLE-534
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.4.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Eagle server mix YAML and typesafe-config, it's a little tricky, better 
> solution is to use consistent configuration library.



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

[jira] [Updated] (EAGLE-535) Fix eagle-server.sh to support to run under windows bash like Cygwin

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-535:
---
Description: Java Classpath separator  in Cygwin and Linux is different, in 
order to make sure eagle scripts can be workable in both environment, we could 
be able to detect the OS type and handle the internal logic accordingly.

> Fix eagle-server.sh to support to run under windows bash like Cygwin
> 
>
> Key: EAGLE-535
> URL: https://issues.apache.org/jira/browse/EAGLE-535
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.4.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Java Classpath separator  in Cygwin and Linux is different, in order to make 
> sure eagle scripts can be workable in both environment, we could be able to 
> detect the OS type and handle the internal logic accordingly.



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

[jira] [Updated] (EAGLE-540) Use Annotation to describe application metadata in ApplicationProvider.xml

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-540:
---
Description: Current application framework only supports to define 
application metadata in XML descriptor file, it may be more convenient to 
define metadata directly with Annotation in code.

> Use Annotation to describe application metadata in ApplicationProvider.xml
> --
>
> Key: EAGLE-540
> URL: https://issues.apache.org/jira/browse/EAGLE-540
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.4.0
>Reporter: Hao Chen
>Assignee: Hao Chen
>Priority: Trivial
> Fix For: v0.5.0
>
>
> Current application framework only supports to define application metadata in 
> XML descriptor file, it may be more convenient to define metadata directly 
> with Annotation in code.



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

[jira] [Commented] (EAGLE-544) Enhance dedup to support extended deduplicator

[Hao Chen (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15557135#comment-15557135
 ] 

Hao Chen commented on EAGLE-544:


[~garrettlish] could you please add more description information about this PR?

> Enhance dedup to support extended deduplicator
> --
>
> Key: EAGLE-544
> URL: https://issues.apache.org/jira/browse/EAGLE-544
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.5.0
>Reporter: Garrett Li
>Assignee: Garrett Li
> Fix For: v0.5.0
>
>




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

[jira] [Reopened] (EAGLE-546) Fix duplicated view path

[Hao Chen (JIRA)]

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

Hao Chen reopened EAGLE-546:


Won't fix as duplicated with https://issues.apache.org/jira/browse/EAGLE-547

> Fix duplicated view path
> 
>
> Key: EAGLE-546
> URL: https://issues.apache.org/jira/browse/EAGLE-546
> Project: Eagle
>  Issue Type: Bug
>Reporter: Hao Chen
>Assignee: Hao Chen
>




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

[jira] [Updated] (EAGLE-547) Fix duplicated view path

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-547:
---
Description: It may cause conflict problems if different applications 
declare same view path,  for example: `MRHistoryJobApplicationProvider ` and 
`GCLogApplicationProvider `, so we should check view path duplication and throw 
exception if found.  (was: It may cause conflict problems if different 
applications declare same view path,  for example: 
`MRHistoryJobApplicationProvider ` and `GCLogApplicationProvider `)

> Fix duplicated view path
> 
>
> Key: EAGLE-547
> URL: https://issues.apache.org/jira/browse/EAGLE-547
> Project: Eagle
>  Issue Type: Bug
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> It may cause conflict problems if different applications declare same view 
> path,  for example: `MRHistoryJobApplicationProvider ` and 
> `GCLogApplicationProvider `, so we should check view path duplication and 
> throw exception if found.



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

[jira] [Closed] (EAGLE-546) Fix duplicated view path

[Hao Chen (JIRA)]

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

Hao Chen closed EAGLE-546.
--
Resolution: Won't Fix

> Fix duplicated view path
> 
>
> Key: EAGLE-546
> URL: https://issues.apache.org/jira/browse/EAGLE-546
> Project: Eagle
>  Issue Type: Bug
>Reporter: Hao Chen
>Assignee: Hao Chen
>




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

[jira] [Updated] (EAGLE-547) Fix duplicated view path

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-547:
---
Description: It may cause conflict problems if different applications 
declare same view path,  for example: `MRHistoryJobApplicationProvider ` and 
`GCLogApplicationProvider `

> Fix duplicated view path
> 
>
> Key: EAGLE-547
> URL: https://issues.apache.org/jira/browse/EAGLE-547
> Project: Eagle
>  Issue Type: Bug
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> It may cause conflict problems if different applications declare same view 
> path,  for example: `MRHistoryJobApplicationProvider ` and 
> `GCLogApplicationProvider `



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

[jira] [Updated] (EAGLE-548) Add eagle service host and port config in jpm web app

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-548:
---
Description: Support redefine eagle service's host and port through 
application metadata configuration, which is mainly used in case where UI and 
backend service are deployed on different hosts.

> Add eagle service host and port config in jpm web app
> -
>
> Key: EAGLE-548
> URL: https://issues.apache.org/jira/browse/EAGLE-548
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Support redefine eagle service's host and port through application metadata 
> configuration, which is mainly used in case where UI and backend service are 
> deployed on different hosts.



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

[jira] [Updated] (EAGLE-549) Add required field for application configuration

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-549:
---
Description: 
Support `required` field in application configuration descriptor, for example:

{code}


service.host
localhost
Eagle Service Host
Eagle Service Host, default: localhost

   true



service.port
8080
Eagle Service Port
Eagle Service Port, default: 8080

   false



{code}

  was:
{code}


service.host
localhost
Eagle Service Host
Eagle Service Host, default: localhost

   true



service.port
8080
Eagle Service Port
Eagle Service Port, default: 8080

   false



{code}


> Add required field for application configuration
> 
>
> Key: EAGLE-549
> URL: https://issues.apache.org/jira/browse/EAGLE-549
> Project: Eagle
>  Issue Type: New Feature
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Support `required` field in application configuration descriptor, for example:
> {code}
> 
> 
> service.host
> localhost
> Eagle Service Host
> Eagle Service Host, default: localhost
>true
> 
> 
> service.port
> 8080
> Eagle Service Port
> Eagle Service Port, default: 8080
>false
> 
> 
> {code}



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

[jira] [Updated] (EAGLE-555) Disruptor dependency conflict

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-555:
---
Description: 
Disruptor dependencies conflict on mvn, we should clean it up otherwise it's 
unable to start application correctly.

{code}
- Conflict between

ERROR [2016-09-20 12:26:08,345] backtype.storm.daemon.worker: Error on 
initialization of server mk-worker
! java.lang.NoSuchMethodError: 
com.lmax.disruptor.RingBuffer.(Lcom/lmax/disruptor/EventFactory;Lcom/lmax/disruptor/ClaimStrategy;Lcom/lmax/disruptor/WaitStrategy;)V
! at backtype.storm.utils.DisruptorQueue.(DisruptorQueue.java:66) 
~[storm-core-0.9.3.jar:0.9.3]
! at backtype.storm.disruptor$disruptor_queue.doInvoke(disruptor.clj:51) 
~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:464) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.worker$worker_data.invoke(worker.clj:185) 
~[storm-core-0.9.3.jar:0.9.3]
! at 
backtype.storm.daemon.worker$fn__3743$exec_fn__1108__auto3744.invoke(worker.clj:363)
 ~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:185) [clojure-1.5.1.jar:na]
! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
! at clojure.core$apply.invoke(core.clj:617) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.worker$fn__3743$mk_worker__3799.doInvoke(worker.clj:354) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$fn__4277.invoke(supervisor.clj:590) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.MultiFn.invoke(MultiFn.java:241) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.supervisor$sync_processes$iter__4116__4120$fn__4121.invoke(supervisor.clj:285)
 [storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.LazySeq.sval(LazySeq.java:42) [clojure-1.5.1.jar:na]
! at clojure.lang.LazySeq.seq(LazySeq.java:60) [clojure-1.5.1.jar:na]
! at clojure.lang.RT.seq(RT.java:484) [clojure-1.5.1.jar:na]
! at clojure.core$seq.invoke(core.clj:133) [clojure-1.5.1.jar:na]
! at clojure.core$dorun.invoke(core.clj:2780) [clojure-1.5.1.jar:na]
! at clojure.core$doall.invoke(core.clj:2796) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:273) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:161) [clojure-1.5.1.jar:na]
! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
! at clojure.core$apply.invoke(core.clj:619) [clojure-1.5.1.jar:na]
! at clojure.core$partial$fn__4190.doInvoke(core.clj:2396) 
[clojure-1.5.1.jar:na]
! at clojure.lang.RestFn.invoke(RestFn.java:397) [clojure-1.5.1.jar:na]
! at backtype.storm.event$event_manager$fn__2467.invoke(event.clj:40) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.run(AFn.java:24) [clojure-1.5.1.jar:na]
! at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]

Process finished with exit code 13
{code}

  was:

{code}
- Conflict between

ERROR [2016-09-20 12:26:08,345] backtype.storm.daemon.worker: Error on 
initialization of server mk-worker
! java.lang.NoSuchMethodError: 
com.lmax.disruptor.RingBuffer.(Lcom/lmax/disruptor/EventFactory;Lcom/lmax/disruptor/ClaimStrategy;Lcom/lmax/disruptor/WaitStrategy;)V
! at backtype.storm.utils.DisruptorQueue.(DisruptorQueue.java:66) 
~[storm-core-0.9.3.jar:0.9.3]
! at backtype.storm.disruptor$disruptor_queue.doInvoke(disruptor.clj:51) 
~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:464) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.worker$worker_data.invoke(worker.clj:185) 
~[storm-core-0.9.3.jar:0.9.3]
! at 
backtype.storm.daemon.worker$fn__3743$exec_fn__1108__auto3744.invoke(worker.clj:363)
 ~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:185) [clojure-1.5.1.jar:na]
! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
! at clojure.core$apply.invoke(core.clj:617) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.worker$fn__3743$mk_worker__3799.doInvoke(worker.clj:354) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$fn__4277.invoke(supervisor.clj:590) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.MultiFn.invoke(MultiFn.java:241) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.supervisor$sync_processes$iter__4116__4120$fn__4121.invoke(supervisor.clj:285)
 [storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.LazySeq.sval(LazySeq.java:42) [clojure-1.5.1.jar:na]
! at clojure.lang.LazySeq.seq(LazySeq.java:60) [clojure-1.5.1.jar:na]
! at clojure.lang.RT.seq(RT.java:484) [clojure-1.5.1.jar:na]
! at clojure.core$seq.invoke(core.clj:133) [clojure-1.5.1.jar:na]
! at clojure.core$dorun.invoke(core.clj:2780) [clojure-1.5.1.jar:na]
! at clojure.core$doall.invoke(core.clj:2796) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:273) 

[jira] [Resolved] (EAGLE-555) Disruptor dependency conflict

[Hao Chen (JIRA)]

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

Hao Chen resolved EAGLE-555.

Resolution: Fixed

> Disruptor dependency conflict
> -
>
> Key: EAGLE-555
> URL: https://issues.apache.org/jira/browse/EAGLE-555
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Disruptor dependencies conflict on mvn, we should clean it up otherwise it's 
> unable to start application correctly.
> {code}
> - Conflict between
> ERROR [2016-09-20 12:26:08,345] backtype.storm.daemon.worker: Error on 
> initialization of server mk-worker
> ! java.lang.NoSuchMethodError: 
> com.lmax.disruptor.RingBuffer.(Lcom/lmax/disruptor/EventFactory;Lcom/lmax/disruptor/ClaimStrategy;Lcom/lmax/disruptor/WaitStrategy;)V
> ! at backtype.storm.utils.DisruptorQueue.(DisruptorQueue.java:66) 
> ~[storm-core-0.9.3.jar:0.9.3]
> ! at backtype.storm.disruptor$disruptor_queue.doInvoke(disruptor.clj:51) 
> ~[storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.RestFn.invoke(RestFn.java:464) [clojure-1.5.1.jar:na]
> ! at backtype.storm.daemon.worker$worker_data.invoke(worker.clj:185) 
> ~[storm-core-0.9.3.jar:0.9.3]
> ! at 
> backtype.storm.daemon.worker$fn__3743$exec_fn__1108__auto3744.invoke(worker.clj:363)
>  ~[storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.AFn.applyToHelper(AFn.java:185) [clojure-1.5.1.jar:na]
> ! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
> ! at clojure.core$apply.invoke(core.clj:617) [clojure-1.5.1.jar:na]
> ! at 
> backtype.storm.daemon.worker$fn__3743$mk_worker__3799.doInvoke(worker.clj:354)
>  [storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.5.1.jar:na]
> ! at backtype.storm.daemon.supervisor$fn__4277.invoke(supervisor.clj:590) 
> [storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.MultiFn.invoke(MultiFn.java:241) [clojure-1.5.1.jar:na]
> ! at 
> backtype.storm.daemon.supervisor$sync_processes$iter__4116__4120$fn__4121.invoke(supervisor.clj:285)
>  [storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.LazySeq.sval(LazySeq.java:42) [clojure-1.5.1.jar:na]
> ! at clojure.lang.LazySeq.seq(LazySeq.java:60) [clojure-1.5.1.jar:na]
> ! at clojure.lang.RT.seq(RT.java:484) [clojure-1.5.1.jar:na]
> ! at clojure.core$seq.invoke(core.clj:133) [clojure-1.5.1.jar:na]
> ! at clojure.core$dorun.invoke(core.clj:2780) [clojure-1.5.1.jar:na]
> ! at clojure.core$doall.invoke(core.clj:2796) [clojure-1.5.1.jar:na]
> ! at 
> backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:273) 
> [storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.AFn.applyToHelper(AFn.java:161) [clojure-1.5.1.jar:na]
> ! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
> ! at clojure.core$apply.invoke(core.clj:619) [clojure-1.5.1.jar:na]
> ! at clojure.core$partial$fn__4190.doInvoke(core.clj:2396) 
> [clojure-1.5.1.jar:na]
> ! at clojure.lang.RestFn.invoke(RestFn.java:397) [clojure-1.5.1.jar:na]
> ! at backtype.storm.event$event_manager$fn__2467.invoke(event.clj:40) 
> [storm-core-0.9.3.jar:0.9.3]
> ! at clojure.lang.AFn.run(AFn.java:24) [clojure-1.5.1.jar:na]
> ! at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]
> Process finished with exit code 13
> {code}



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

[jira] [Updated] (EAGLE-555) Disruptor dependency conflict

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-555:
---
Description: 

{code}
- Conflict between

ERROR [2016-09-20 12:26:08,345] backtype.storm.daemon.worker: Error on 
initialization of server mk-worker
! java.lang.NoSuchMethodError: 
com.lmax.disruptor.RingBuffer.(Lcom/lmax/disruptor/EventFactory;Lcom/lmax/disruptor/ClaimStrategy;Lcom/lmax/disruptor/WaitStrategy;)V
! at backtype.storm.utils.DisruptorQueue.(DisruptorQueue.java:66) 
~[storm-core-0.9.3.jar:0.9.3]
! at backtype.storm.disruptor$disruptor_queue.doInvoke(disruptor.clj:51) 
~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:464) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.worker$worker_data.invoke(worker.clj:185) 
~[storm-core-0.9.3.jar:0.9.3]
! at 
backtype.storm.daemon.worker$fn__3743$exec_fn__1108__auto3744.invoke(worker.clj:363)
 ~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:185) [clojure-1.5.1.jar:na]
! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
! at clojure.core$apply.invoke(core.clj:617) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.worker$fn__3743$mk_worker__3799.doInvoke(worker.clj:354) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$fn__4277.invoke(supervisor.clj:590) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.MultiFn.invoke(MultiFn.java:241) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.supervisor$sync_processes$iter__4116__4120$fn__4121.invoke(supervisor.clj:285)
 [storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.LazySeq.sval(LazySeq.java:42) [clojure-1.5.1.jar:na]
! at clojure.lang.LazySeq.seq(LazySeq.java:60) [clojure-1.5.1.jar:na]
! at clojure.lang.RT.seq(RT.java:484) [clojure-1.5.1.jar:na]
! at clojure.core$seq.invoke(core.clj:133) [clojure-1.5.1.jar:na]
! at clojure.core$dorun.invoke(core.clj:2780) [clojure-1.5.1.jar:na]
! at clojure.core$doall.invoke(core.clj:2796) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:273) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:161) [clojure-1.5.1.jar:na]
! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
! at clojure.core$apply.invoke(core.clj:619) [clojure-1.5.1.jar:na]
! at clojure.core$partial$fn__4190.doInvoke(core.clj:2396) 
[clojure-1.5.1.jar:na]
! at clojure.lang.RestFn.invoke(RestFn.java:397) [clojure-1.5.1.jar:na]
! at backtype.storm.event$event_manager$fn__2467.invoke(event.clj:40) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.run(AFn.java:24) [clojure-1.5.1.jar:na]
! at java.lang.Thread.run(Thread.java:745) [na:1.8.0_91]

Process finished with exit code 13
{code}

  was:
{code}
- Conflict between

ERROR [2016-09-20 12:26:08,345] backtype.storm.daemon.worker: Error on 
initialization of server mk-worker
! java.lang.NoSuchMethodError: 
com.lmax.disruptor.RingBuffer.(Lcom/lmax/disruptor/EventFactory;Lcom/lmax/disruptor/ClaimStrategy;Lcom/lmax/disruptor/WaitStrategy;)V
! at backtype.storm.utils.DisruptorQueue.(DisruptorQueue.java:66) 
~[storm-core-0.9.3.jar:0.9.3]
! at backtype.storm.disruptor$disruptor_queue.doInvoke(disruptor.clj:51) 
~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:464) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.worker$worker_data.invoke(worker.clj:185) 
~[storm-core-0.9.3.jar:0.9.3]
! at 
backtype.storm.daemon.worker$fn__3743$exec_fn__1108__auto3744.invoke(worker.clj:363)
 ~[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:185) [clojure-1.5.1.jar:na]
! at clojure.lang.AFn.applyTo(AFn.java:151) [clojure-1.5.1.jar:na]
! at clojure.core$apply.invoke(core.clj:617) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.worker$fn__3743$mk_worker__3799.doInvoke(worker.clj:354) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.RestFn.invoke(RestFn.java:512) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$fn__4277.invoke(supervisor.clj:590) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.MultiFn.invoke(MultiFn.java:241) [clojure-1.5.1.jar:na]
! at 
backtype.storm.daemon.supervisor$sync_processes$iter__4116__4120$fn__4121.invoke(supervisor.clj:285)
 [storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.LazySeq.sval(LazySeq.java:42) [clojure-1.5.1.jar:na]
! at clojure.lang.LazySeq.seq(LazySeq.java:60) [clojure-1.5.1.jar:na]
! at clojure.lang.RT.seq(RT.java:484) [clojure-1.5.1.jar:na]
! at clojure.core$seq.invoke(core.clj:133) [clojure-1.5.1.jar:na]
! at clojure.core$dorun.invoke(core.clj:2780) [clojure-1.5.1.jar:na]
! at clojure.core$doall.invoke(core.clj:2796) [clojure-1.5.1.jar:na]
! at backtype.storm.daemon.supervisor$sync_processes.invoke(supervisor.clj:273) 
[storm-core-0.9.3.jar:0.9.3]
! at clojure.lang.AFn.applyToHelper(AFn.java:161) [clojure-1.5.1.jar:na]
! at 

[jira] [Updated] (EAGLE-556) Install/Update Alert Topology Metadata when start alert engine

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-556:
---
Description: Currently alert engine requires additional metadata like 
TopologyMeta, which in fact could be automatically generated during starting 
alert engine.

> Install/Update Alert Topology Metadata when start alert engine
> --
>
> Key: EAGLE-556
> URL: https://issues.apache.org/jira/browse/EAGLE-556
> Project: Eagle
>  Issue Type: Improvement
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Currently alert engine requires additional metadata like TopologyMeta, which 
> in fact could be automatically generated during starting alert engine.



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

[jira] [Updated] (EAGLE-557) Setup Eagle v0.5 Documentation Site Layout

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-557:
---
Description: 
* Setup initial doc structure with mkdocs, provide basic content proposal and  
some manual docs about how to add new docs.
* Setup a mkdocs service on demo node, listening on port 8000.


> Setup Eagle v0.5 Documentation Site Layout
> --
>
> Key: EAGLE-557
> URL: https://issues.apache.org/jira/browse/EAGLE-557
> Project: Eagle
>  Issue Type: New Feature
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Michael Wu
> Fix For: v0.5.0
>
>
> * Setup initial doc structure with mkdocs, provide basic content proposal and 
>  some manual docs about how to add new docs.
> * Setup a mkdocs service on demo node, listening on port 8000.



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

[jira] [Updated] (EAGLE-559) Fix TestServiceAppWithZk test cause failing due to port conflict

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-559:
---
Description: 

{code}
Regression

com.apache.eagle.service.app.TestServiceAppWithZk.testMain

Failing for the past 1 build (Since Failed#127 )
Took 5.7 sec.
Error Message

java.net.BindException: Address already in use
Stacktrace

java.lang.RuntimeException: java.net.BindException: Address already in use
at 
org.eclipse.jetty.setuid.SetUIDListener.lifeCycleStarting(SetUIDListener.java:213)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.setStarting(AbstractLifeCycle.java:187)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at io.dropwizard.cli.ServerCommand.run(ServerCommand.java:43)
at io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:43)
at io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:76)
at io.dropwizard.cli.Cli.run(Cli.java:70)
at io.dropwizard.Application.run(Application.java:72)
at 
com.apache.eagle.service.app.TestServiceAppWithZk.setUp(TestServiceAppWithZk.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:264)
at 
org.eclipse.jetty.setuid.SetUIDListener.lifeCycleStarting(SetUIDListener.java:200)
... 36 more
{code}

  was:
{code}
Regression

com.apache.eagle.service.app.TestServiceAppWithZk.testMain

Failing for the past 1 build (Since Failed#127 )
Took 5.7 sec.
Error Message

java.net.BindException: Address already in use
Stacktrace

java.lang.RuntimeException: java.net.BindException: Address already in use
at 
org.eclipse.jetty.setuid.SetUIDListener.lifeCycleStarting(SetUIDListener.java:213)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.setStarting(AbstractLifeCycle.java:187)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at io.dropwizard.cli.ServerCommand.run(ServerCommand.java:43)
at io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:43)
at 

[jira] [Updated] (EAGLE-559) Fix TestServiceAppWithZk test cause failing due to port conflict

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-559:
---
Description: 
`TestServiceAppWithZk` often failed with follow exception:

{code}
Regression

com.apache.eagle.service.app.TestServiceAppWithZk.testMain

Failing for the past 1 build (Since Failed#127 )
Took 5.7 sec.
Error Message

java.net.BindException: Address already in use
Stacktrace

java.lang.RuntimeException: java.net.BindException: Address already in use
at 
org.eclipse.jetty.setuid.SetUIDListener.lifeCycleStarting(SetUIDListener.java:213)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.setStarting(AbstractLifeCycle.java:187)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at io.dropwizard.cli.ServerCommand.run(ServerCommand.java:43)
at io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:43)
at io.dropwizard.cli.ConfiguredCommand.run(ConfiguredCommand.java:76)
at io.dropwizard.cli.Cli.run(Cli.java:70)
at io.dropwizard.Application.run(Application.java:72)
at 
com.apache.eagle.service.app.TestServiceAppWithZk.setUp(TestServiceAppWithZk.java:69)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at 
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at 
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at 
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
at 
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at 
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at 
org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:59)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:120)
at 
org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:103)
at org.apache.maven.surefire.Surefire.run(Surefire.java:169)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at 
org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:350)
at 
org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1021)
Caused by: java.net.BindException: Address already in use
at sun.nio.ch.Net.bind0(Native Method)
at sun.nio.ch.Net.bind(Net.java:433)
at sun.nio.ch.Net.bind(Net.java:425)
at 
sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
at 
org.eclipse.jetty.server.ServerConnector.open(ServerConnector.java:264)
at 
org.eclipse.jetty.setuid.SetUIDListener.lifeCycleStarting(SetUIDListener.java:200)
... 36 more
{code}

  was:

{code}
Regression

com.apache.eagle.service.app.TestServiceAppWithZk.testMain

Failing for the past 1 build (Since Failed#127 )
Took 5.7 sec.
Error Message

java.net.BindException: Address already in use
Stacktrace

java.lang.RuntimeException: java.net.BindException: Address already in use
at 
org.eclipse.jetty.setuid.SetUIDListener.lifeCycleStarting(SetUIDListener.java:213)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.setStarting(AbstractLifeCycle.java:187)
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
at io.dropwizard.cli.ServerCommand.run(ServerCommand.java:43)
at io.dropwizard.cli.EnvironmentCommand.run(EnvironmentCommand.java:43)
   

[jira] [Updated] (EAGLE-560) Retry embedded zookeeper port by port +1 when conflicts

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-560:
---
Description: Currently embedded zookeeper start with hard-coded port 2181 
but it may cause conflict when different unittest cases are running 
concurrently on same machine, so retry embedded zookeeper port by port +1 if 
starting fails, until finally find a usable port. The max retry times is 5, 
otherwise throw exception.  (was: Retry embedded zookeeper port by port +1 when 
conflicts)

> Retry embedded zookeeper port by port +1 when conflicts
> ---
>
> Key: EAGLE-560
> URL: https://issues.apache.org/jira/browse/EAGLE-560
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Currently embedded zookeeper start with hard-coded port 2181 but it may cause 
> conflict when different unittest cases are running concurrently on same 
> machine, so retry embedded zookeeper port by port +1 if starting fails, until 
> finally find a usable port. The max retry times is 5, otherwise throw 
> exception.



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

[jira] [Updated] (EAGLE-563) refactor Hadoop queue feeder using application framework

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-563:
---
Description: Currently hadoop queue feeder is developed as independent 
storm application. In order to make sure hadoop queue feeder could be well 
managed by application framework and service

> refactor Hadoop queue feeder using application framework
> 
>
> Key: EAGLE-563
> URL: https://issues.apache.org/jira/browse/EAGLE-563
> Project: Eagle
>  Issue Type: Improvement
>Reporter: Zhao, Qingwen
>Assignee: Michael Wu
>
> Currently hadoop queue feeder is developed as independent storm application. 
> In order to make sure hadoop queue feeder could be well managed by 
> application framework and service



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

[jira] [Updated] (EAGLE-575) Refactor StaticWebApplication to StaticApplication to support both web/static application

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-575:
---
Description: 
* Format appId as  EAGLE_$appType_$siteId in upper case for easily being 
managed in storm ui
* Refactor StaticWebApplication to StaticApplication to support both web/static 
application
* Fix test failure problem caused by calling application.run directly

  was:
* Format appId as  EAGLE_$siteId_$appType  in upper case for easily being 
managed in storm ui
* Refactor StaticWebApplication to StaticApplication to support both web/static 
application
* Fix test failure problem caused by calling application.run directly


> Refactor StaticWebApplication to StaticApplication to support both web/static 
> application
> -
>
> Key: EAGLE-575
> URL: https://issues.apache.org/jira/browse/EAGLE-575
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
>  Labels: eagle-app-framework
> Fix For: v0.5.0
>
>
> * Format appId as  EAGLE_$appType_$siteId in upper case for easily being 
> managed in storm ui
> * Refactor StaticWebApplication to StaticApplication to support both 
> web/static application
> * Fix test failure problem caused by calling application.run directly



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

[jira] [Commented] (EAGLE-591) Fix conflict streamId between different sites when installation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15557065#comment-15557065
 ] 

ASF GitHub Bot commented on EAGLE-591:
--

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-eagle/pull/476


> Fix conflict streamId between different sites when installation
> ---
>
> Key: EAGLE-591
> URL: https://issues.apache.org/jira/browse/EAGLE-591
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Eagle alert engine currently only support global-unique streamId (where a 
> "stream" in fact means a physicla data source with schema), but it's common 
> use case the different sites may have same-kind (same stream schema) of 
> streams especially when installing same app into different sites, so we 
> should refactor the alert engine metadata to support such kinds of use cases. 
> This ticket will only fix conflict streamId between different sites when 
> installation as a quick solution by simply using "{streamId}_{siteId}" as the 
> physical installed "streamId".



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

[GitHub] incubator-eagle pull request #476: [EAGLE-591][WIP] Fix conflict streamId be...

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/incubator-eagle/pull/476


---
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] (EAGLE-591) Fix conflict streamId between different sites when installation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-591?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15557027#comment-15557027
 ] 

ASF GitHub Bot commented on EAGLE-591:
--

GitHub user haoch opened a pull request:

https://github.com/apache/incubator-eagle/pull/476

[EAGLE-591][WIP] Fix conflict streamId between different sites while 
installing

Eagle alert engine currently only support global-unique streamId (where a 
"stream" in fact means a physicla data source with schema), but it's common use 
case the different sites may have same-kind (same stream schema) of streams 
especially when installing same app into different sites, so we should refactor 
the alert engine metadata to support such kinds of use cases. 

This ticket will only fix conflict streamId between different sites when 
installation as a quick solution by simply using `{streamId}_{siteId}` as the 
physical installed `streamId`.

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

$ git pull https://github.com/haoch/incubator-eagle FixConflictStreamId

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

https://github.com/apache/incubator-eagle/pull/476.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 #476


commit de42e6ab6a0140b5177c39439c224c1ae0d39854
Author: Hao Chen 
Date:   2016-10-08T03:04:55Z

Fix conflict streamId between different sites while installing




> Fix conflict streamId between different sites when installation
> ---
>
> Key: EAGLE-591
> URL: https://issues.apache.org/jira/browse/EAGLE-591
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Eagle alert engine currently only support global-unique streamId (where a 
> "stream" in fact means a physicla data source with schema), but it's common 
> use case the different sites may have same-kind (same stream schema) of 
> streams especially when installing same app into different sites, so we 
> should refactor the alert engine metadata to support such kinds of use cases. 
> This ticket will only fix conflict streamId between different sites when 
> installation as a quick solution by simply using "{streamId}_{siteId}" as the 
> physical installed "streamId".



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

[GitHub] incubator-eagle pull request #476: [EAGLE-591][WIP] Fix conflict streamId be...

[haoch]

GitHub user haoch opened a pull request:

https://github.com/apache/incubator-eagle/pull/476

[EAGLE-591][WIP] Fix conflict streamId between different sites while 
installing

Eagle alert engine currently only support global-unique streamId (where a 
"stream" in fact means a physicla data source with schema), but it's common use 
case the different sites may have same-kind (same stream schema) of streams 
especially when installing same app into different sites, so we should refactor 
the alert engine metadata to support such kinds of use cases. 

This ticket will only fix conflict streamId between different sites when 
installation as a quick solution by simply using `{streamId}_{siteId}` as the 
physical installed `streamId`.

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

$ git pull https://github.com/haoch/incubator-eagle FixConflictStreamId

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

https://github.com/apache/incubator-eagle/pull/476.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 #476


commit de42e6ab6a0140b5177c39439c224c1ae0d39854
Author: Hao Chen 
Date:   2016-10-08T03:04:55Z

Fix conflict streamId between different sites while installing




---
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] [Updated] (EAGLE-591) Fix conflict streamId between different sites when installation

[Hao Chen (JIRA)]

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

Hao Chen updated EAGLE-591:
---
Description: 
Eagle alert engine currently only support global-unique streamId (where a 
"stream" in fact means a physicla data source with schema), but it's common use 
case the different sites may have same-kind (same stream schema) of streams 
especially when installing same app into different sites, so we should refactor 
the alert engine metadata to support such kinds of use cases. 

This ticket will only fix conflict streamId between different sites when 
installation as a quick solution by simply using "{streamId}_{siteId}" as the 
physical installed "streamId".

  was:
Eagle alert engine currently only support global-unique streamId (where a 
"stream" in fact means a physicla data source with schema), but it's common use 
case the different sites may have same-kind (same stream schema) of streams 
especially when installing same app into different sites, so we should refactor 
the alert engine metadata to support such kinds of use cases. 

This ticket will only fix conflict streamId between different sites when 
installation as a quick solution.


> Fix conflict streamId between different sites when installation
> ---
>
> Key: EAGLE-591
> URL: https://issues.apache.org/jira/browse/EAGLE-591
> Project: Eagle
>  Issue Type: Bug
>Affects Versions: v0.5.0
>Reporter: Hao Chen
>Assignee: Hao Chen
> Fix For: v0.5.0
>
>
> Eagle alert engine currently only support global-unique streamId (where a 
> "stream" in fact means a physicla data source with schema), but it's common 
> use case the different sites may have same-kind (same stream schema) of 
> streams especially when installing same app into different sites, so we 
> should refactor the alert engine metadata to support such kinds of use cases. 
> This ticket will only fix conflict streamId between different sites when 
> installation as a quick solution by simply using "{streamId}_{siteId}" as the 
> physical installed "streamId".



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

[jira] [Created] (EAGLE-591) Fix conflict streamId between different sites when installation

[Hao Chen (JIRA)]

Hao Chen created EAGLE-591:
--

 Summary: Fix conflict streamId between different sites when 
installation
 Key: EAGLE-591
 URL: https://issues.apache.org/jira/browse/EAGLE-591
 Project: Eagle
  Issue Type: Bug
Affects Versions: v0.5.0
Reporter: Hao Chen
Assignee: Hao Chen
 Fix For: v0.5.0


Eagle alert engine currently only support global-unique streamId (where a 
"stream" in fact means a physicla data source with schema), but it's common use 
case the different sites may have same-kind (same stream schema) of streams 
especially when installing same app into different sites, so we should refactor 
the alert engine metadata to support such kinds of use cases. 

This ticket will only fix conflict streamId between different sites when 
installation as a quick solution.



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

[jira] [Updated] (EAGLE-526) aggregation framework for mr history jobs

[wujinhu (JIRA)]

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

wujinhu updated EAGLE-526:
--
Description: 
Please review https://github.com/apache/incubator-eagle/pull/419 first.

This is the second step of the aggregation framework. This step uses results of 
the job metrics by each minute that generated by the first step. 

The framework is a storm topology. The spout decides which time range of job 
metrics needs to be aggregated, divide the time range into several pieces(For 
example, each piece is one hour) and emits these pieces to aggregate bolts.
The aggregate bolts aggregate the time range piece of job metrics that the 
spout assigns to them.
In aggregate bolts, they fetch job metrics by eagle server api and write the 
aggregate results back to eagle server.

> aggregation framework for mr history jobs
> -
>
> Key: EAGLE-526
> URL: https://issues.apache.org/jira/browse/EAGLE-526
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>
> Please review https://github.com/apache/incubator-eagle/pull/419 first.
> This is the second step of the aggregation framework. This step uses results 
> of the job metrics by each minute that generated by the first step. 
> The framework is a storm topology. The spout decides which time range of job 
> metrics needs to be aggregated, divide the time range into several pieces(For 
> example, each piece is one hour) and emits these pieces to aggregate bolts.
> The aggregate bolts aggregate the time range piece of job metrics that the 
> spout assigns to them.
> In aggregate bolts, they fetch job metrics by eagle server api and write the 
> aggregate results back to eagle server.



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

[jira] [Closed] (EAGLE-526) aggregation framework for mr history jobs

[wujinhu (JIRA)]

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

wujinhu closed EAGLE-526.
-
Resolution: Resolved

> aggregation framework for mr history jobs
> -
>
> Key: EAGLE-526
> URL: https://issues.apache.org/jira/browse/EAGLE-526
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>
> Please review https://github.com/apache/incubator-eagle/pull/419 first.
> This is the second step of the aggregation framework. This step uses results 
> of the job metrics by each minute that generated by the first step. 
> The framework is a storm topology. The spout decides which time range of job 
> metrics needs to be aggregated, divide the time range into several pieces(For 
> example, each piece is one hour) and emits these pieces to aggregate bolts.
> The aggregate bolts aggregate the time range piece of job metrics that the 
> spout assigns to them.
> In aggregate bolts, they fetch job metrics by eagle server api and write the 
> aggregate results back to eagle server.



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

[jira] [Reopened] (EAGLE-526) aggregation framework for mr history jobs

[wujinhu (JIRA)]

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

wujinhu reopened EAGLE-526:
---

> aggregation framework for mr history jobs
> -
>
> Key: EAGLE-526
> URL: https://issues.apache.org/jira/browse/EAGLE-526
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>




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

[GitHub] incubator-eagle issue #430: [EAGLE-526] aggregation framework for history jo...

[wujinhu]

Github user wujinhu commented on the issue:

https://github.com/apache/incubator-eagle/pull/430
  
Please review https://github.com/apache/incubator-eagle/pull/419 first.

This is the second step of the aggregation framework. This step uses 
results of the job metrics by each minute that generated by the first step. 

The framework is a storm topology. The spout decides which time range of 
job metrics needs to be aggregated, divide the time range into several 
pieces(For example, each piece is one hour) and emits these pieces to aggregate 
bolts.
The aggregate bolts aggregate the time range piece of job metrics that the 
spout assigns to them.
In aggregate bolts, they fetch job metrics by eagle server api and write 
the aggregate results back to eagle server.



---
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] [Updated] (EAGLE-524) aggregation framework-job level metrics aggregation

[wujinhu (JIRA)]

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

wujinhu updated EAGLE-524:
--
Description: 
The users want to get the aggregation results of job counters group by some 
dimensions(by cluster/cluster/cluster and so on).For example, 
the Hadoop cluster administrators want to see the trend of HDFS_BYTES_READ in 
the last three days group by each cluster.

To meet this requirement, I implement this by two steps. This PR is the first 
step. The second step is contained in #430

In this PR, the history feeder generates counter metrics when it processed 
history jobs. When the feeder gets one task of each job, it gets the counters 
values and generate metric value in each minute by ( counter value / task 
duration * task run time in each minute). So, we get counter metrics by each 
job and in each minute.

> aggregation framework-job level metrics aggregation
> ---
>
> Key: EAGLE-524
> URL: https://issues.apache.org/jira/browse/EAGLE-524
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>
> The users want to get the aggregation results of job counters group by some 
> dimensions(by cluster/cluster/cluster and so on).For 
> example, the Hadoop cluster administrators want to see the trend of 
> HDFS_BYTES_READ in the last three days group by each cluster.
> To meet this requirement, I implement this by two steps. This PR is the first 
> step. The second step is contained in #430
> In this PR, the history feeder generates counter metrics when it processed 
> history jobs. When the feeder gets one task of each job, it gets the counters 
> values and generate metric value in each minute by ( counter value / task 
> duration * task run time in each minute). So, we get counter metrics by each 
> job and in each minute.



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

[jira] [Closed] (EAGLE-524) aggregation framework-job level metrics aggregation

[wujinhu (JIRA)]

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

wujinhu closed EAGLE-524.
-
Resolution: Resolved

> aggregation framework-job level metrics aggregation
> ---
>
> Key: EAGLE-524
> URL: https://issues.apache.org/jira/browse/EAGLE-524
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>
> The users want to get the aggregation results of job counters group by some 
> dimensions(by cluster/cluster/cluster and so on).For 
> example, the Hadoop cluster administrators want to see the trend of 
> HDFS_BYTES_READ in the last three days group by each cluster.
> To meet this requirement, I implement this by two steps. This PR is the first 
> step. The second step is contained in #430
> In this PR, the history feeder generates counter metrics when it processed 
> history jobs. When the feeder gets one task of each job, it gets the counters 
> values and generate metric value in each minute by ( counter value / task 
> duration * task run time in each minute). So, we get counter metrics by each 
> job and in each minute.



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

[jira] [Reopened] (EAGLE-524) aggregation framework-job level metrics aggregation

[wujinhu (JIRA)]

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

wujinhu reopened EAGLE-524:
---

> aggregation framework-job level metrics aggregation
> ---
>
> Key: EAGLE-524
> URL: https://issues.apache.org/jira/browse/EAGLE-524
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>




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

[jira] [Commented] (EAGLE-524) aggregation framework-job level metrics aggregation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/EAGLE-524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=1037#comment-1037
 ] 

ASF GitHub Bot commented on EAGLE-524:
--

Github user wujinhu commented on the issue:

https://github.com/apache/incubator-eagle/pull/419
  
The users want to get the aggregation results of job counters group by some 
dimensions(by cluster/cluster/cluster and so on).For example, 
the Hadoop cluster administrators want to see the trend of HDFS_BYTES_READ in 
the last three days group by each cluster.

To meet this requirement,  I implement this by two steps. This PR is the 
first step. The second step is contained in 
https://github.com/apache/incubator-eagle/pull/430

In this PR, the history feeder generates counter metrics when it processed 
history jobs. When the feeder gets one task of each job, it gets the counters 
values and generate metric value in each minute by ( counter value / task 
duration * task run time in each minute). So, we get counter metrics by each 
job and in each minute.


> aggregation framework-job level metrics aggregation
> ---
>
> Key: EAGLE-524
> URL: https://issues.apache.org/jira/browse/EAGLE-524
> Project: Eagle
>  Issue Type: New Feature
>Reporter: wujinhu
>Assignee: wujinhu
>




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

[GitHub] incubator-eagle issue #419: [EAGLE-524] aggregation framework-job level metr...

[wujinhu]

Github user wujinhu commented on the issue:

https://github.com/apache/incubator-eagle/pull/419
  
The users want to get the aggregation results of job counters group by some 
dimensions(by cluster/cluster/cluster and so on).For example, 
the Hadoop cluster administrators want to see the trend of HDFS_BYTES_READ in 
the last three days group by each cluster.

To meet this requirement,  I implement this by two steps. This PR is the 
first step. The second step is contained in 
https://github.com/apache/incubator-eagle/pull/430

In this PR, the history feeder generates counter metrics when it processed 
history jobs. When the feeder gets one task of each job, it gets the counters 
values and generate metric value in each minute by ( counter value / task 
duration * task run time in each minute). So, we get counter metrics by each 
job and in each minute.


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