[jira] [Created] (NIFI-2684) Validation error messages should refer to propertyDescriptor using its displayName

[Andre (JIRA)]

Andre created NIFI-2684:
---

 Summary: Validation error messages should refer to 
propertyDescriptor using its displayName
 Key: NIFI-2684
 URL: https://issues.apache.org/jira/browse/NIFI-2684
 Project: Apache NiFi
  Issue Type: Improvement
Affects Versions: 1.0.0
Reporter: Andre
Assignee: Andre
 Fix For: 1.1.0


When message validation violation is triggered, 
{{AbstractConfigurableComponent}} refers to the descriptor using  
{{descriptor.getName()}} 

the result is that error messages end up referring to properties by sometimes 
cryptic names (instead of the "pretty names" defined in {{.displayName}} )

Users would be better of if we used {{displayName}} on error messages.




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

[GitHub] nifi pull request #959: Merge pull request #1 from apache/master

[rtempleton]

GitHub user rtempleton opened a pull request:

https://github.com/apache/nifi/pull/959

Merge pull request #1 from apache/master

sync

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

$ git pull https://github.com/rtempleton/nifi master

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

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


commit 56fd824c4809716f7114edf829b15edd3c6ddc0b
Author: Ryan Templeton 
Date:   2016-06-13T15:47:46Z

Merge pull request #1 from apache/master

sync




---
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] (NIFI-2681) Avoid caching Provenance Index Searchers

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15442158#comment-15442158
 ] 

ASF GitHub Bot commented on NIFI-2681:
--

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/958

NIFI-2681: Refactored IndexManager into an interface and renamed the …

…existing implementation to CachingIndexManager. Implemented a new 
SimpleIndexManager that performs no caching of IndexSearchers.

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

$ git pull https://github.com/markap14/nifi NIFI-2681

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

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


commit 58c715cefaeaa9ef2b7d89cd751456da73f42953
Author: Mark Payne 
Date:   2016-08-27T00:03:16Z

NIFI-2681: Refactored IndexManager into an interface and renamed the 
existing implementation to CachingIndexManager. Implemented a new 
SimpleIndexManager that performs no caching of IndexSearchers.




> Avoid caching Provenance Index Searchers
> 
>
> Key: NIFI-2681
> URL: https://issues.apache.org/jira/browse/NIFI-2681
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.1.0
>
>
> In NIFI-2600 and NIFI-2452, we addressed two bugs where the Provenance 
> Repository closes a cached IndexSearcher too soon. The IndexManager keeps the 
> searchers cached in an effort to offer better performance when performing a 
> Provenance Query. This was done because it was recommended in the Lucene 
> documentation. However, we occasionally still see nodes crashing with 
> segfaults due to the Lucene Searching. We should update the Persistent 
> Provenance Repository to stop caching Index Searchers in order to trade a 
> slight performance improvement for significantly better reliability.
> Playing around with the idea in order to test it out shows very favorable 
> results. On a system where I could cause a seg fault almost every time that I 
> ran a large provenance query, I updated the code to no longer cache the 
> readers and saw perfect stability with no noticeable performance degradation.
> I will cleanup the code and submit a PR for these changes.



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

[GitHub] nifi pull request #958: NIFI-2681: Refactored IndexManager into an interface...

[markap14]

GitHub user markap14 opened a pull request:

https://github.com/apache/nifi/pull/958

NIFI-2681: Refactored IndexManager into an interface and renamed the …

…existing implementation to CachingIndexManager. Implemented a new 
SimpleIndexManager that performs no caching of IndexSearchers.

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

$ git pull https://github.com/markap14/nifi NIFI-2681

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

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


commit 58c715cefaeaa9ef2b7d89cd751456da73f42953
Author: Mark Payne 
Date:   2016-08-27T00:03:16Z

NIFI-2681: Refactored IndexManager into an interface and renamed the 
existing implementation to CachingIndexManager. Implemented a new 
SimpleIndexManager that performs no caching of IndexSearchers.




---
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] (NIFI-2683) Tests rely on locale

[Pierre Villard (JIRA)]

Pierre Villard created NIFI-2683:


 Summary: Tests rely on locale
 Key: NIFI-2683
 URL: https://issues.apache.org/jira/browse/NIFI-2683
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.0
 Environment: Apache Maven 3.3.9 
(bb52d8502b132ec0a5a3f4c09453c07478323dc5; 2015-11-10T17:41:47+01:00)
Java version: 1.8.0_74, vendor: Oracle Corporation
Default locale: fr_FR, platform encoding: Cp1252
OS name: "windows 10", version: "10.0", arch: "amd64", family: "dos"
Reporter: Pierre Villard
Priority: Minor


The following test fails because of the locale language.

{noformat}
Failed tests:
  StandardHttpResponseMergerSpec.MergeResponses: #responseEntities.size() HTTP 
200 #httpMethod responses for #requestUriPart:123 Condition not satisfied:
returnedJson == expectedJson
||  |
||  
{"id":"1","permissions":{"canRead":false,"canWrite":false},"status":{"aggregateSnapshot":{"flowFilesIn":0,"bytesIn":1000,"input":"0
 (1,000 bytes)","flowFilesOut":0,"bytesOut":0,"output":"
0 (0 bytes)","flowFilesQueued":0,"bytesQueued":0,"queued":"0 (0 
bytes)","queuedSize":"0 bytes","queuedCount":"0"}}}
|false
|1 difference (99% similarity)
|
{"id":"1","permissions":{"canRead":false,"canWrite":false},"status":{"aggregateSnapshot":{"flowFilesIn":0,"bytesIn":1000,"input":"0
 (1( )000 bytes)","flowFilesOut":0,"bytesOut":0,"output":"0
 (0 bytes)","flowFilesQueued":0,"bytesQueued":0,"queued":"0 (0 
bytes)","queuedSize":"0 bytes","queuedCount":"0"}}}
|
{"id":"1","permissions":{"canRead":false,"canWrite":false},"status":{"aggregateSnapshot":{"flowFilesIn":0,"bytesIn":1000,"input":"0
 (1(,)000 bytes)","flowFilesOut":0,"bytesOut":0,"output":"0
 (0 bytes)","flowFilesQueued":0,"bytesQueued":0,"queued":"0 (0 
bytes)","queuedSize":"0 bytes","queuedCount":"0"}}}
{"id":"1","permissions":{"canRead":false,"canWrite":false},"status":{"aggregateSnapshot":{"flowFilesIn":0,"bytesIn":1000,"input":"0
 (1 000 bytes)","flowFilesOut":0,"bytesOut":0,"output":"0 (0 bytes)","fl
owFilesQueued":0,"bytesQueued":0,"q
{noformat}

An easy option is to have a little change in the main pom.xml:

{noformat}

org.apache.maven.plugins
maven-surefire-plugin
2.18


**/*Test.class
**/Test*.class
**/*Spec.class


true
-Xmx1G 
-Djava.net.preferIPv4Stack=true -Duser.language=en -Duser.region=US




org.apache.maven.surefire
surefire-junit4
2.18



{noformat}

otherwise the test needs to be changed.



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

[jira] [Commented] (NIFI-2341) Create a processor to parse logs formated using CEF

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441842#comment-15441842
 ] 

ASF GitHub Bot commented on NIFI-2341:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/785
  
Ready for review


> Create a processor to parse logs formated using CEF
> ---
>
> Key: NIFI-2341
> URL: https://issues.apache.org/jira/browse/NIFI-2341
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Andre
>Assignee: Andre
>
> As NiFi continue to increase its abilities to complement SIEM, Splunk and ELK 
> deployments, a number of users will be looking to parse CEF formatted 
> logs[1][2].
> CEF is a format specified by Arcsight (now part of HPE) and is described in 
> detail in here:
> https://www.protect724.hpe.com/docs/DOC-1072
> [1] 
> http://apache-nifi.1125220.n5.nabble.com/Suggestion-of-processors-td9795.html
> [2] 
> https://community.hortonworks.com/questions/43185/which-processor-is-used-to-parse-cef-format-logs.html



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

[GitHub] nifi issue #785: NIFI-2341 - Introduce ParseCEF processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/785
  
Ready for review


---
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] nifi issue #785: NIFI-2341 - Introduce ParseCEF processor

[trixpan]

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/785
  
figured out what it is. I needed to exclude slf4j-log4j12 from parCEFone 
dependency.

In the process found a few bugs. Fixing. :-)


---
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] (NIFI-2341) Create a processor to parse logs formated using CEF

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441615#comment-15441615
 ] 

ASF GitHub Bot commented on NIFI-2341:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/785
  
figured out what it is. I needed to exclude slf4j-log4j12 from parCEFone 
dependency.

In the process found a few bugs. Fixing. :-)


> Create a processor to parse logs formated using CEF
> ---
>
> Key: NIFI-2341
> URL: https://issues.apache.org/jira/browse/NIFI-2341
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Andre
>Assignee: Andre
>
> As NiFi continue to increase its abilities to complement SIEM, Splunk and ELK 
> deployments, a number of users will be looking to parse CEF formatted 
> logs[1][2].
> CEF is a format specified by Arcsight (now part of HPE) and is described in 
> detail in here:
> https://www.protect724.hpe.com/docs/DOC-1072
> [1] 
> http://apache-nifi.1125220.n5.nabble.com/Suggestion-of-processors-td9795.html
> [2] 
> https://community.hortonworks.com/questions/43185/which-processor-is-used-to-parse-cef-format-logs.html



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

[jira] [Commented] (NIFI-2341) Create a processor to parse logs formated using CEF

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/NIFI-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15441557#comment-15441557
 ] 

ASF GitHub Bot commented on NIFI-2341:
--

Github user trixpan commented on the issue:

https://github.com/apache/nifi/pull/785
  
@mattyb149 - For some reason I don't truly grasp TestGetJMSQueue start to 
fail once this processor is introduced to standard-processors

Other than that code looks to be working as expected




> Create a processor to parse logs formated using CEF
> ---
>
> Key: NIFI-2341
> URL: https://issues.apache.org/jira/browse/NIFI-2341
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Andre
>Assignee: Andre
>
> As NiFi continue to increase its abilities to complement SIEM, Splunk and ELK 
> deployments, a number of users will be looking to parse CEF formatted 
> logs[1][2].
> CEF is a format specified by Arcsight (now part of HPE) and is described in 
> detail in here:
> https://www.protect724.hpe.com/docs/DOC-1072
> [1] 
> http://apache-nifi.1125220.n5.nabble.com/Suggestion-of-processors-td9795.html
> [2] 
> https://community.hortonworks.com/questions/43185/which-processor-is-used-to-parse-cef-format-logs.html



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

[jira] [Updated] (NIFI-2592) Processor still runs @OnScheduled method when it's running on a non-primary node

[Joseph Witt (JIRA)]

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

Joseph Witt updated NIFI-2592:
--
Fix Version/s: 1.1.0

> Processor still runs @OnScheduled method when it's running on a non-primary 
> node
> 
>
> Key: NIFI-2592
> URL: https://issues.apache.org/jira/browse/NIFI-2592
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Jeff Storck
> Fix For: 1.1.0
>
>
> If a processor is scheduled to run on the primary node only, the instances of 
> the processor running on non-primary nodes still have their methods annotated 
> with @OnScheduled invoked. The framework should not invoke the @OnScheduled 
> methods if the processor isn't supposed to run on that node.
> To reproduce this, set up a cluster with the nodes running on the same 
> server. The ListenHTTP can be scheduled to be run on the primary node only, 
> but other instances of the processor on non-primary nodes will still try to 
> bind the port, resulting in exceptions.



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