[jira] [Commented] (NIFI-4839) Create a CLI in NiFi Toolkit to interact with NIFi Registry/deploy flows

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4839:
--

Github user fcntl commented on the issue:

https://github.com/apache/nifi/pull/2477
  
+1 this is a very useful module to automate things like Nifi integration 
with the Registry.


> Create a CLI in NiFi Toolkit to interact with NIFi Registry/deploy flows
> 
>
> Key: NIFI-4839
> URL: https://issues.apache.org/jira/browse/NIFI-4839
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Major
>
> Now that we have NiFi Registry and the ability to import/upgrade flows in 
> NiFi, we should offer a command-line tool to interact with these REST 
> end-points. This could part of NiFi Toolkit and would help people potentially 
> automate some of these operations.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi issue #2477: NIFI-4839 Adding CLI to nifi-toolkit

2018-02-19 Thread fcntl
Github user fcntl commented on the issue:

https://github.com/apache/nifi/pull/2477
  
+1 this is a very useful module to automate things like Nifi integration 
with the Registry.


---


[jira] [Commented] (NIFI-4508) AMQP Processor that uses basicConsume

2018-02-19 Thread Randy Bovay (JIRA)

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

Randy Bovay commented on NIFI-4508:
---

bump!  Would be good to get [~msclarke] to think about this maybe.

> AMQP Processor that uses basicConsume
> -
>
> Key: NIFI-4508
> URL: https://issues.apache.org/jira/browse/NIFI-4508
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.3.0
>Reporter: Randy Bovay
>Priority: Major
>
> Due to poor performance of the AMQP Processor, we need to be able to have a 
> basicConsume based interface to RabbitMQ.
> https://community.hortonworks.com/questions/66799/consumeamqp-performance-issue-less-than-50-msgs-se.html



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4833) NIFI-4833 Add ScanHBase processor

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4833:
--

Github user bdesert commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2478#discussion_r169176478
  
--- Diff: 
nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/ScanHBase.java
 ---
@@ -0,0 +1,562 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.hbase;
+
+import org.apache.commons.lang3.StringUtils;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.components.ValidationResult;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.flowfile.attributes.CoreAttributes;
+import org.apache.nifi.hbase.io.JsonFullRowSerializer;
+import org.apache.nifi.hbase.io.JsonQualifierAndValueRowSerializer;
+import org.apache.nifi.hbase.io.RowSerializer;
+import org.apache.nifi.hbase.scan.Column;
+import org.apache.nifi.hbase.scan.ResultCell;
+import org.apache.nifi.hbase.scan.ResultHandler;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.Tuple;
+
+import java.io.IOException;
+import java.nio.charset.Charset;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.regex.Pattern;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@Tags({"hbase", "scan", "fetch", "get"})
+@CapabilityDescription("Scans and fetches rows from an HBase table. This 
processor may be used to fetch rows from hbase table by specifying a range of 
rowkey values (start and/or end ),"
++ "by time range, by filter expression, or any combination of 
them. \n"
++ "Order of records can be controlled by a property 
Reversed"
++ "Number of rows retrieved by the processor can be limited.")
+@WritesAttributes({
+@WritesAttribute(attribute = "hbase.table", description = "The 
name of the HBase table that the row was fetched from"),
+@WritesAttribute(attribute = "hbase.resultset", description = "A 
JSON document/s representing the row/s. This property is only written when a 
Destination of flowfile-attributes is selected."),
+@WritesAttribute(attribute = "mime.type", description = "Set to 
application/json when using a Destination of flowfile-content, not set or 
modified otherwise"),
+@WritesAttribute(attribute = "hbase.rows.count", description = 
"Number of rows in the content of given flow file"),
+@WritesAttribute(attribute = "scanhbase.results.found", 
description = "Indicates whether at least one row has been found in given hbase 
table with provided conditions. "
++ "Could be null (not present) if transfered to FAILURE")
+})
+public class 

[GitHub] nifi pull request #2478: NIFI-4833 Add scanHBase Processor

2018-02-19 Thread bdesert
Github user bdesert commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2478#discussion_r169176478
  
--- Diff: 
nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/ScanHBase.java
 ---
@@ -0,0 +1,562 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.hbase;
+
+import org.apache.commons.lang3.StringUtils;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.components.ValidationResult;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.flowfile.attributes.CoreAttributes;
+import org.apache.nifi.hbase.io.JsonFullRowSerializer;
+import org.apache.nifi.hbase.io.JsonQualifierAndValueRowSerializer;
+import org.apache.nifi.hbase.io.RowSerializer;
+import org.apache.nifi.hbase.scan.Column;
+import org.apache.nifi.hbase.scan.ResultCell;
+import org.apache.nifi.hbase.scan.ResultHandler;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.Tuple;
+
+import java.io.IOException;
+import java.nio.charset.Charset;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.regex.Pattern;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@Tags({"hbase", "scan", "fetch", "get"})
+@CapabilityDescription("Scans and fetches rows from an HBase table. This 
processor may be used to fetch rows from hbase table by specifying a range of 
rowkey values (start and/or end ),"
++ "by time range, by filter expression, or any combination of 
them. \n"
++ "Order of records can be controlled by a property 
Reversed"
++ "Number of rows retrieved by the processor can be limited.")
+@WritesAttributes({
+@WritesAttribute(attribute = "hbase.table", description = "The 
name of the HBase table that the row was fetched from"),
+@WritesAttribute(attribute = "hbase.resultset", description = "A 
JSON document/s representing the row/s. This property is only written when a 
Destination of flowfile-attributes is selected."),
+@WritesAttribute(attribute = "mime.type", description = "Set to 
application/json when using a Destination of flowfile-content, not set or 
modified otherwise"),
+@WritesAttribute(attribute = "hbase.rows.count", description = 
"Number of rows in the content of given flow file"),
+@WritesAttribute(attribute = "scanhbase.results.found", 
description = "Indicates whether at least one row has been found in given hbase 
table with provided conditions. "
++ "Could be null (not present) if transfered to FAILURE")
+})
+public class ScanHBase extends AbstractProcessor {
+//enhanced regex for columns to allow "-" in column qualifier names
+static final Pattern COLUMNS_PATTERN = 
Pattern.compile("\\w+(:(\\w|-)+)?(?:,\\w+(:(\\w|-)+)?)*");
+static 

[jira] [Commented] (NIFI-4893) Cannot convert Avro schemas to Record schemas with default arrays

2018-02-19 Thread Gardella Juan Pablo (JIRA)

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

Gardella Juan Pablo commented on NIFI-4893:
---

Pull request with the fix at: https://github.com/apache/nifi/pull/2480

> Cannot convert Avro schemas to Record schemas with default arrays
> -
>
> Key: NIFI-4893
> URL: https://issues.apache.org/jira/browse/NIFI-4893
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0, 1.6.0
> Environment: ALL
>Reporter: Gardella Juan Pablo
>Priority: Major
> Attachments: issue1.zip
>
>
> Given an Avro Schema that has a default array defined, it is not possible to 
> be converted to a Nifi Record Schema.
> To reproduce the bug, try to convert the following Avro schema to Record 
> Schema:
> {code}
> {
>     "type": "record",
>     "name": "Foo1",
>     "namespace": "foo.namespace",
>     "fields": [
>         {
>             "name": "listOfInt",
>             "type": {
>                 "type": "array",
>                 "items": "int"
>             },
>             "doc": "array of ints",
>             "default": 0
>         }
>     ]
> }
> {code}
>  
> Using org.apache.nifi.avro.AvroTypeUtil class. Attached a maven project to 
> reproduce the issue and also the fix.
> * To reproduce the bug, run "mvn clean test"
> * To test the fix, run "mvn clean test -Ppatch".
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4893) Cannot convert Avro schemas to Record schemas with default arrays

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4893:
--

GitHub user gardellajuanpablo opened a pull request:

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

NIFI-4893 Cannot convert Avro schemas to Record schemas with default …

…arrays

To test it run:
mvn test "-pl" org.apache.nifi:nifi-avro-record-utils -am  
-Dtest=TestAvroTypeUtil -DfailIfNoTests=false

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

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

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

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


commit e7f0edbf948f1579150627ba03dc9b2ed7a9fca0
Author: gardellajuanpablo 
Date:   2018-02-19T19:07:14Z

NIFI-4893 Cannot convert Avro schemas to Record schemas with default arrays

To test it run:
mvn test "-pl" org.apache.nifi:nifi-avro-record-utils -am  
-Dtest=TestAvroTypeUtil -DfailIfNoTests=false




> Cannot convert Avro schemas to Record schemas with default arrays
> -
>
> Key: NIFI-4893
> URL: https://issues.apache.org/jira/browse/NIFI-4893
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.5.0, 1.6.0
> Environment: ALL
>Reporter: Gardella Juan Pablo
>Priority: Major
> Attachments: issue1.zip
>
>
> Given an Avro Schema that has a default array defined, it is not possible to 
> be converted to a Nifi Record Schema.
> To reproduce the bug, try to convert the following Avro schema to Record 
> Schema:
> {code}
> {
>     "type": "record",
>     "name": "Foo1",
>     "namespace": "foo.namespace",
>     "fields": [
>         {
>             "name": "listOfInt",
>             "type": {
>                 "type": "array",
>                 "items": "int"
>             },
>             "doc": "array of ints",
>             "default": 0
>         }
>     ]
> }
> {code}
>  
> Using org.apache.nifi.avro.AvroTypeUtil class. Attached a maven project to 
> reproduce the issue and also the fix.
> * To reproduce the bug, run "mvn clean test"
> * To test the fix, run "mvn clean test -Ppatch".
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi pull request #2480: NIFI-4893 Cannot convert Avro schemas to Record sch...

2018-02-19 Thread gardellajuanpablo
GitHub user gardellajuanpablo opened a pull request:

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

NIFI-4893 Cannot convert Avro schemas to Record schemas with default …

…arrays

To test it run:
mvn test "-pl" org.apache.nifi:nifi-avro-record-utils -am  
-Dtest=TestAvroTypeUtil -DfailIfNoTests=false

Thank you for submitting a contribution to Apache NiFi.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced 
 in the commit message?

- [ ] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
- [ ] Have you written or updated unit tests to verify your changes?
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
- [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
- [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
- [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

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

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

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


commit e7f0edbf948f1579150627ba03dc9b2ed7a9fca0
Author: gardellajuanpablo 
Date:   2018-02-19T19:07:14Z

NIFI-4893 Cannot convert Avro schemas to Record schemas with default arrays

To test it run:
mvn test "-pl" org.apache.nifi:nifi-avro-record-utils -am  
-Dtest=TestAvroTypeUtil -DfailIfNoTests=false




---


[jira] [Created] (NIFI-4893) Cannot convert Avro schemas to Record schemas with default arrays

2018-02-19 Thread Gardella Juan Pablo (JIRA)
Gardella Juan Pablo created NIFI-4893:
-

 Summary: Cannot convert Avro schemas to Record schemas with 
default arrays
 Key: NIFI-4893
 URL: https://issues.apache.org/jira/browse/NIFI-4893
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.5.0, 1.6.0
 Environment: ALL
Reporter: Gardella Juan Pablo
 Attachments: issue1.zip

Given an Avro Schema that has a default array defined, it is not possible to be 
converted to a Nifi Record Schema.

To reproduce the bug, try to convert the following Avro schema to Record Schema:

{code}
{
    "type": "record",
    "name": "Foo1",
    "namespace": "foo.namespace",
    "fields": [
        {
            "name": "listOfInt",
            "type": {
                "type": "array",
                "items": "int"
            },
            "doc": "array of ints",
            "default": 0
        }
    ]
}
{code}
 
Using org.apache.nifi.avro.AvroTypeUtil class. Attached a maven project to 
reproduce the issue and also the fix.
* To reproduce the bug, run "mvn clean test"
* To test the fix, run "mvn clean test -Ppatch".



 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (MINIFICPP-406) Change StreamFactory to use SSLContextService if one is available.

2018-02-19 Thread ASF GitHub Bot (JIRA)

[ 
https://issues.apache.org/jira/browse/MINIFICPP-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16369337#comment-16369337
 ] 

ASF GitHub Bot commented on MINIFICPP-406:
--

GitHub user phrocker opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/265

MINIFICPP-406: Ensure that Context Service OR minifi properties can b…

…e used

to configure secure comms ( HTTP & Socket)

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-406

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

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


commit 323cc41564608d73a66ff1edeeacca4ee310b2dd
Author: Marc Parisi 
Date:   2018-02-17T18:00:26Z

MINIFICPP-406: Ensure that Context Service OR minifi properties can be used
to configure secure comms ( HTTP & Socket)




> Change StreamFactory to use SSLContextService if one is available. 
> ---
>
> Key: MINIFICPP-406
> URL: https://issues.apache.org/jira/browse/MINIFICPP-406
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: marco polo
>Assignee: marco polo
>Priority: Major
>
> Currently socket coordination is done through minifi.properties and is 
> unaware of any context service. We should change this to make configuration 
> consistent. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi-minifi-cpp pull request #265: MINIFICPP-406: Ensure that Context Servic...

2018-02-19 Thread phrocker
GitHub user phrocker opened a pull request:

https://github.com/apache/nifi-minifi-cpp/pull/265

MINIFICPP-406: Ensure that Context Service OR minifi properties can b…

…e used

to configure secure comms ( HTTP & Socket)

Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.

In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:

### For all changes:
- [ ] Is there a JIRA ticket associated with this PR? Is it referenced
 in the commit message?

- [ ] Does your PR title start with MINIFI- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.

- [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?

- [ ] Is your initial contribution a single, squashed commit?

### For code changes:
- [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the LICENSE file?
- [ ] If applicable, have you updated the NOTICE file?

### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in 
which it is rendered?

### Note:
Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.


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

$ git pull https://github.com/phrocker/nifi-minifi-cpp MINIFICPP-406

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

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


commit 323cc41564608d73a66ff1edeeacca4ee310b2dd
Author: Marc Parisi 
Date:   2018-02-17T18:00:26Z

MINIFICPP-406: Ensure that Context Service OR minifi properties can be used
to configure secure comms ( HTTP & Socket)




---


[jira] [Commented] (NIFI-4794) Improve Garbage Collection required by Provenance Repository

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4794:
--

Github user asfgit closed the pull request at:

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


> Improve Garbage Collection required by Provenance Repository
> 
>
> Key: NIFI-4794
> URL: https://issues.apache.org/jira/browse/NIFI-4794
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.6.0
>
>
> The EventIdFirstSchemaRecordWriter that is used by the provenance repository 
> has a writeRecord(ProvenanceEventRecord) method. Within this method, it 
> serializes the given record into a byte array by serializing to a 
> ByteArrayOutputStream (after wrapping the BAOS in a DataOutputStream). Once 
> this is done, it calls toByteArray() on that BAOS so that it can write the 
> byte[] directly to another OutputStream.
> This can create a rather large amount of garbage to be collected. We can 
> improve this significantly:
>  # Instead of creating a new ByteArrayOutputStream each time, create a pool 
> of them. This avoids constantly having to garbage collect them.
>  # If said BAOS grows beyond a certain size, we should not return it to the 
> pool because we don't want to keep a huge impact on the heap.
>  # Instead of wrapping the BAOS in a new DataOutputStream, the 
> DataOutputStream should be pooled/recycled as well. Since it must create an 
> internal byte[] for the writeUTF method, this can save a significant amount 
> of garbage.
>  # Avoid calling ByteArrayOutputStream.toByteArray(). We can instead just use 
> ByteArrayOutputStream.writeTo(OutputStream). This avoids both allocating that 
> new array/copying the data, and the GC overhead.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (NIFI-4794) Improve Garbage Collection required by Provenance Repository

2018-02-19 Thread Matt Burgess (JIRA)

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

Matt Burgess updated NIFI-4794:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Improve Garbage Collection required by Provenance Repository
> 
>
> Key: NIFI-4794
> URL: https://issues.apache.org/jira/browse/NIFI-4794
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.6.0
>
>
> The EventIdFirstSchemaRecordWriter that is used by the provenance repository 
> has a writeRecord(ProvenanceEventRecord) method. Within this method, it 
> serializes the given record into a byte array by serializing to a 
> ByteArrayOutputStream (after wrapping the BAOS in a DataOutputStream). Once 
> this is done, it calls toByteArray() on that BAOS so that it can write the 
> byte[] directly to another OutputStream.
> This can create a rather large amount of garbage to be collected. We can 
> improve this significantly:
>  # Instead of creating a new ByteArrayOutputStream each time, create a pool 
> of them. This avoids constantly having to garbage collect them.
>  # If said BAOS grows beyond a certain size, we should not return it to the 
> pool because we don't want to keep a huge impact on the heap.
>  # Instead of wrapping the BAOS in a new DataOutputStream, the 
> DataOutputStream should be pooled/recycled as well. Since it must create an 
> internal byte[] for the writeUTF method, this can save a significant amount 
> of garbage.
>  # Avoid calling ByteArrayOutputStream.toByteArray(). We can instead just use 
> ByteArrayOutputStream.writeTo(OutputStream). This avoids both allocating that 
> new array/copying the data, and the GC overhead.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4794) Improve Garbage Collection required by Provenance Repository

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4794:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2437
  
+1 LGTM, ran unit tests and numerous flows on a running NiFi instance. I 
didn't do performance testing but did visually verify improvements in the code, 
and verified stability on the running instance. Thanks for the improvement! 
Merging to master


> Improve Garbage Collection required by Provenance Repository
> 
>
> Key: NIFI-4794
> URL: https://issues.apache.org/jira/browse/NIFI-4794
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.6.0
>
>
> The EventIdFirstSchemaRecordWriter that is used by the provenance repository 
> has a writeRecord(ProvenanceEventRecord) method. Within this method, it 
> serializes the given record into a byte array by serializing to a 
> ByteArrayOutputStream (after wrapping the BAOS in a DataOutputStream). Once 
> this is done, it calls toByteArray() on that BAOS so that it can write the 
> byte[] directly to another OutputStream.
> This can create a rather large amount of garbage to be collected. We can 
> improve this significantly:
>  # Instead of creating a new ByteArrayOutputStream each time, create a pool 
> of them. This avoids constantly having to garbage collect them.
>  # If said BAOS grows beyond a certain size, we should not return it to the 
> pool because we don't want to keep a huge impact on the heap.
>  # Instead of wrapping the BAOS in a new DataOutputStream, the 
> DataOutputStream should be pooled/recycled as well. Since it must create an 
> internal byte[] for the writeUTF method, this can save a significant amount 
> of garbage.
>  # Avoid calling ByteArrayOutputStream.toByteArray(). We can instead just use 
> ByteArrayOutputStream.writeTo(OutputStream). This avoids both allocating that 
> new array/copying the data, and the GC overhead.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi pull request #2437: NIFI-4794: Updated event writers to avoid creating ...

2018-02-19 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] nifi issue #2437: NIFI-4794: Updated event writers to avoid creating a lot o...

2018-02-19 Thread mattyb149
Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2437
  
+1 LGTM, ran unit tests and numerous flows on a running NiFi instance. I 
didn't do performance testing but did visually verify improvements in the code, 
and verified stability on the running instance. Thanks for the improvement! 
Merging to master


---


[jira] [Updated] (NIFI-4774) FlowFile Repository should write updates to the same FlowFile to the same partition

2018-02-19 Thread Matt Burgess (JIRA)

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

Matt Burgess updated NIFI-4774:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> FlowFile Repository should write updates to the same FlowFile to the same 
> partition
> ---
>
> Key: NIFI-4774
> URL: https://issues.apache.org/jira/browse/NIFI-4774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.6.0
>
>
> As-is, in the case of power loss or Operating System crash, we could have an 
> update that is lost, and then an update for the same FlowFile that is not 
> lost, because the updates for a given FlowFile can span partitions. If an 
> update were written to Partition 1 and then to Partition 2 and Partition 2 is 
> flushed to disk by the Operating System and then the Operating System crashes 
> or power is lost before Partition 1 is flushed to disk, we could lose the 
> update to Partition 1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi pull request #2416: NIFI 4774: Provide alternate implementation of Writ...

2018-02-19 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[jira] [Updated] (NIFI-4774) FlowFile Repository should write updates to the same FlowFile to the same partition

2018-02-19 Thread Matt Burgess (JIRA)

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

Matt Burgess updated NIFI-4774:
---
Fix Version/s: 1.6.0

> FlowFile Repository should write updates to the same FlowFile to the same 
> partition
> ---
>
> Key: NIFI-4774
> URL: https://issues.apache.org/jira/browse/NIFI-4774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Major
> Fix For: 1.6.0
>
>
> As-is, in the case of power loss or Operating System crash, we could have an 
> update that is lost, and then an update for the same FlowFile that is not 
> lost, because the updates for a given FlowFile can span partitions. If an 
> update were written to Partition 1 and then to Partition 2 and Partition 2 is 
> flushed to disk by the Operating System and then the Operating System crashes 
> or power is lost before Partition 1 is flushed to disk, we could lose the 
> update to Partition 1.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi issue #2416: NIFI 4774: Provide alternate implementation of Write-Ahead...

2018-02-19 Thread mattyb149
Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2416
  
+1 LGTM, ran full suite of tests and numerous flows in a running NiFi 
instance. I did not do performance testing (Joe W did quite a few) but did 
verify the stability.  Thanks for the improvement! Merging to master


---


[jira] [Updated] (NIFI-4772) If several processors do not return from their @OnScheduled method, NiFi will stop scheduling any Processors

2018-02-19 Thread Matt Burgess (JIRA)

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

Matt Burgess updated NIFI-4772:
---
Fix Version/s: 1.6.0

> If several processors do not return from their @OnScheduled method, NiFi will 
> stop scheduling any Processors
> 
>
> Key: NIFI-4772
> URL: https://issues.apache.org/jira/browse/NIFI-4772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.6.0
>
>
> If a Processor does not properly return from its @OnScheduled method and 
> several instances of the processor are started, we can get into a state where 
> no Processors can start. We start seeing log messages like the following:
> {code}
> 2018-01-10 10:16:31,433 WARN [StandardProcessScheduler Thread-1] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'UpdateAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'UpdateAttribute[id=95423ee6-e6a6-1220-83ad-af20577063bd]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:42,937 WARN [StandardProcessScheduler Thread-2] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'PutHDFS' processor to finish. An attempt is made to cancel 
> the task via Thread.interrupt(). However it does not guarantee that the task 
> will be canceled since the code inside current OnScheduled operation may have 
> been written to ignore interrupts which may result in a runaway thread. This 
> could lead to more issues, eventually requiring NiFi to be restarted. This is 
> usually a bug in the target Processor 
> 'PutHDFS[id=25e531ec-d873-1dec-acc9-ea745e7869ed]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:46,993 WARN [StandardProcessScheduler Thread-4] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'LogAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'LogAttribute[id=9a683a06-aa24-19b5--944a0216]' that needs to be 
> documented, reported and eventually fixed.
> {code}
> While we should avoid having misbehaving Processors to begin with, the 
> framework must also be tolerant of this and should not allow one misbehaving 
> Processor from affecting other Processors.
> We can "approximate" this issue by following these steps:
> 1. Create 1 DebugFlow Processor. Auto-terminate its success & failure 
> relationships. Set the "@OnScheduled Pause Time" property to "2 mins"
> 2. Copy & paste this DebugFlow Processor so that there are at least 8 of them.
> 3. Create a GenerateFlowFile Processor and an UpdateAttribute Processor. Send 
> success of GenerateFlowFile to UpdateAttribute.
> 4. Start all of the DebugFlow Processors.
> 5. Start the GenerateFlowFIle and UpdateAttribute Processors.
> In this scenario, we will not see the above log messages, because after 1 
> minute the DebugFlow Processor is interrupted and the @OnSchedule method 
> completes Exceptionally. However, we do see that GenerateFlowFile and 
> UpdateAttribute do not start running until after the 2 minute time window has 
> elapsed. If DebugFlow instead did not complete Exceptionally, then 
> GenerateFlowFile and UpdateAttribute would never start running and we would 
> see the above error messages in the log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4772) If several processors do not return from their @OnScheduled method, NiFi will stop scheduling any Processors

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4772:
--

Github user asfgit closed the pull request at:

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


> If several processors do not return from their @OnScheduled method, NiFi will 
> stop scheduling any Processors
> 
>
> Key: NIFI-4772
> URL: https://issues.apache.org/jira/browse/NIFI-4772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.6.0
>
>
> If a Processor does not properly return from its @OnScheduled method and 
> several instances of the processor are started, we can get into a state where 
> no Processors can start. We start seeing log messages like the following:
> {code}
> 2018-01-10 10:16:31,433 WARN [StandardProcessScheduler Thread-1] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'UpdateAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'UpdateAttribute[id=95423ee6-e6a6-1220-83ad-af20577063bd]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:42,937 WARN [StandardProcessScheduler Thread-2] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'PutHDFS' processor to finish. An attempt is made to cancel 
> the task via Thread.interrupt(). However it does not guarantee that the task 
> will be canceled since the code inside current OnScheduled operation may have 
> been written to ignore interrupts which may result in a runaway thread. This 
> could lead to more issues, eventually requiring NiFi to be restarted. This is 
> usually a bug in the target Processor 
> 'PutHDFS[id=25e531ec-d873-1dec-acc9-ea745e7869ed]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:46,993 WARN [StandardProcessScheduler Thread-4] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'LogAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'LogAttribute[id=9a683a06-aa24-19b5--944a0216]' that needs to be 
> documented, reported and eventually fixed.
> {code}
> While we should avoid having misbehaving Processors to begin with, the 
> framework must also be tolerant of this and should not allow one misbehaving 
> Processor from affecting other Processors.
> We can "approximate" this issue by following these steps:
> 1. Create 1 DebugFlow Processor. Auto-terminate its success & failure 
> relationships. Set the "@OnScheduled Pause Time" property to "2 mins"
> 2. Copy & paste this DebugFlow Processor so that there are at least 8 of them.
> 3. Create a GenerateFlowFile Processor and an UpdateAttribute Processor. Send 
> success of GenerateFlowFile to UpdateAttribute.
> 4. Start all of the DebugFlow Processors.
> 5. Start the GenerateFlowFIle and UpdateAttribute Processors.
> In this scenario, we will not see the above log messages, because after 1 
> minute the DebugFlow Processor is interrupted and the @OnSchedule method 
> completes Exceptionally. However, we do see that GenerateFlowFile and 
> UpdateAttribute do not start running until after the 2 minute time window has 
> elapsed. If DebugFlow instead did not complete Exceptionally, then 
> GenerateFlowFile and UpdateAttribute would never start running and we would 
> see the above error messages in the log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (NIFI-4772) If several processors do not return from their @OnScheduled method, NiFi will stop scheduling any Processors

2018-02-19 Thread Matt Burgess (JIRA)

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

Matt Burgess updated NIFI-4772:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> If several processors do not return from their @OnScheduled method, NiFi will 
> stop scheduling any Processors
> 
>
> Key: NIFI-4772
> URL: https://issues.apache.org/jira/browse/NIFI-4772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
> Fix For: 1.6.0
>
>
> If a Processor does not properly return from its @OnScheduled method and 
> several instances of the processor are started, we can get into a state where 
> no Processors can start. We start seeing log messages like the following:
> {code}
> 2018-01-10 10:16:31,433 WARN [StandardProcessScheduler Thread-1] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'UpdateAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'UpdateAttribute[id=95423ee6-e6a6-1220-83ad-af20577063bd]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:42,937 WARN [StandardProcessScheduler Thread-2] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'PutHDFS' processor to finish. An attempt is made to cancel 
> the task via Thread.interrupt(). However it does not guarantee that the task 
> will be canceled since the code inside current OnScheduled operation may have 
> been written to ignore interrupts which may result in a runaway thread. This 
> could lead to more issues, eventually requiring NiFi to be restarted. This is 
> usually a bug in the target Processor 
> 'PutHDFS[id=25e531ec-d873-1dec-acc9-ea745e7869ed]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:46,993 WARN [StandardProcessScheduler Thread-4] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'LogAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'LogAttribute[id=9a683a06-aa24-19b5--944a0216]' that needs to be 
> documented, reported and eventually fixed.
> {code}
> While we should avoid having misbehaving Processors to begin with, the 
> framework must also be tolerant of this and should not allow one misbehaving 
> Processor from affecting other Processors.
> We can "approximate" this issue by following these steps:
> 1. Create 1 DebugFlow Processor. Auto-terminate its success & failure 
> relationships. Set the "@OnScheduled Pause Time" property to "2 mins"
> 2. Copy & paste this DebugFlow Processor so that there are at least 8 of them.
> 3. Create a GenerateFlowFile Processor and an UpdateAttribute Processor. Send 
> success of GenerateFlowFile to UpdateAttribute.
> 4. Start all of the DebugFlow Processors.
> 5. Start the GenerateFlowFIle and UpdateAttribute Processors.
> In this scenario, we will not see the above log messages, because after 1 
> minute the DebugFlow Processor is interrupted and the @OnSchedule method 
> completes Exceptionally. However, we do see that GenerateFlowFile and 
> UpdateAttribute do not start running until after the 2 minute time window has 
> elapsed. If DebugFlow instead did not complete Exceptionally, then 
> GenerateFlowFile and UpdateAttribute would never start running and we would 
> see the above error messages in the log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4772) If several processors do not return from their @OnScheduled method, NiFi will stop scheduling any Processors

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4772:
--

Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2403
  
+1 LGTM, ran unit tests and tried many different scenarios in a running 
NiFi (before and after the QueryDatabaseTable issue was fixed) under various 
OnScheduled error conditions.  Thanks for the improvement! Merging to master


> If several processors do not return from their @OnScheduled method, NiFi will 
> stop scheduling any Processors
> 
>
> Key: NIFI-4772
> URL: https://issues.apache.org/jira/browse/NIFI-4772
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Mark Payne
>Priority: Critical
>
> If a Processor does not properly return from its @OnScheduled method and 
> several instances of the processor are started, we can get into a state where 
> no Processors can start. We start seeing log messages like the following:
> {code}
> 2018-01-10 10:16:31,433 WARN [StandardProcessScheduler Thread-1] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'UpdateAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'UpdateAttribute[id=95423ee6-e6a6-1220-83ad-af20577063bd]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:42,937 WARN [StandardProcessScheduler Thread-2] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'PutHDFS' processor to finish. An attempt is made to cancel 
> the task via Thread.interrupt(). However it does not guarantee that the task 
> will be canceled since the code inside current OnScheduled operation may have 
> been written to ignore interrupts which may result in a runaway thread. This 
> could lead to more issues, eventually requiring NiFi to be restarted. This is 
> usually a bug in the target Processor 
> 'PutHDFS[id=25e531ec-d873-1dec-acc9-ea745e7869ed]' that needs to be 
> documented, reported and eventually fixed.
> 2018-01-10 10:16:46,993 WARN [StandardProcessScheduler Thread-4] 
> o.a.n.controller.StandardProcessorNode Timed out while waiting for 
> OnScheduled of 'LogAttribute' processor to finish. An attempt is made to 
> cancel the task via Thread.interrupt(). However it does not guarantee that 
> the task will be canceled since the code inside current OnScheduled operation 
> may have been written to ignore interrupts which may result in a runaway 
> thread. This could lead to more issues, eventually requiring NiFi to be 
> restarted. This is usually a bug in the target Processor 
> 'LogAttribute[id=9a683a06-aa24-19b5--944a0216]' that needs to be 
> documented, reported and eventually fixed.
> {code}
> While we should avoid having misbehaving Processors to begin with, the 
> framework must also be tolerant of this and should not allow one misbehaving 
> Processor from affecting other Processors.
> We can "approximate" this issue by following these steps:
> 1. Create 1 DebugFlow Processor. Auto-terminate its success & failure 
> relationships. Set the "@OnScheduled Pause Time" property to "2 mins"
> 2. Copy & paste this DebugFlow Processor so that there are at least 8 of them.
> 3. Create a GenerateFlowFile Processor and an UpdateAttribute Processor. Send 
> success of GenerateFlowFile to UpdateAttribute.
> 4. Start all of the DebugFlow Processors.
> 5. Start the GenerateFlowFIle and UpdateAttribute Processors.
> In this scenario, we will not see the above log messages, because after 1 
> minute the DebugFlow Processor is interrupted and the @OnSchedule method 
> completes Exceptionally. However, we do see that GenerateFlowFile and 
> UpdateAttribute do not start running until after the 2 minute time window has 
> elapsed. If DebugFlow instead did not complete Exceptionally, then 
> GenerateFlowFile and UpdateAttribute would never start running and we would 
> see the above error messages in the log.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[GitHub] nifi pull request #2403: NIFI-4772: Refactored how the @OnScheduled methods ...

2018-02-19 Thread asfgit
Github user asfgit closed the pull request at:

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


---


[GitHub] nifi issue #2403: NIFI-4772: Refactored how the @OnScheduled methods of proc...

2018-02-19 Thread mattyb149
Github user mattyb149 commented on the issue:

https://github.com/apache/nifi/pull/2403
  
+1 LGTM, ran unit tests and tried many different scenarios in a running 
NiFi (before and after the QueryDatabaseTable issue was fixed) under various 
OnScheduled error conditions.  Thanks for the improvement! Merging to master


---


[jira] [Updated] (NIFI-4892) ValidateCSV Processor - no doublequote escaping in "invalid" output

2018-02-19 Thread Eugeny Kolpakov (JIRA)

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

Eugeny Kolpakov updated NIFI-4892:
--
Description: 
ValidateCSV processor fails to preserve field escaping for flow files routed to 
"invalid" relation when "Line by Line" validation strategy is used.

 

Minimal sample flow attached.

 

Observed in 1.4.0, but 1.5.0 might be affected as well - I'll update this 
ticket after upgrading to 1.5.0 (unless someone could do that earlier)

  was:
ValidateCSV processor fails to preserve field escaping for flow files routed to 
"invalid" relation when "Line by Line" validation strategy is used.

 

Observed in 1.4.0, but 1.5.0 might be affected as well - I'll update this 
ticket after upgrading to 1.5.0 (unless someone could do that earlier)


> ValidateCSV Processor - no doublequote escaping in "invalid" output
> ---
>
> Key: NIFI-4892
> URL: https://issues.apache.org/jira/browse/NIFI-4892
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Eugeny Kolpakov
>Priority: Major
> Attachments: ValidateCSV_LineByLine_EscapingBug.xml
>
>
> ValidateCSV processor fails to preserve field escaping for flow files routed 
> to "invalid" relation when "Line by Line" validation strategy is used.
>  
> Minimal sample flow attached.
>  
> Observed in 1.4.0, but 1.5.0 might be affected as well - I'll update this 
> ticket after upgrading to 1.5.0 (unless someone could do that earlier)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Updated] (NIFI-4892) ValidateCSV Processor - no doublequote escaping in "invalid" output

2018-02-19 Thread Eugeny Kolpakov (JIRA)

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

Eugeny Kolpakov updated NIFI-4892:
--
Attachment: ValidateCSV_LineByLine_EscapingBug.xml

> ValidateCSV Processor - no doublequote escaping in "invalid" output
> ---
>
> Key: NIFI-4892
> URL: https://issues.apache.org/jira/browse/NIFI-4892
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Eugeny Kolpakov
>Priority: Major
> Attachments: ValidateCSV_LineByLine_EscapingBug.xml
>
>
> ValidateCSV processor fails to preserve field escaping for flow files routed 
> to "invalid" relation when "Line by Line" validation strategy is used.
>  
> Observed in 1.4.0, but 1.5.0 might be affected as well - I'll update this 
> ticket after upgrading to 1.5.0 (unless someone could do that earlier)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (NIFI-4892) ValidateCSV Processor - no doublequote escaping in "invalid" output

2018-02-19 Thread Eugeny Kolpakov (JIRA)
Eugeny Kolpakov created NIFI-4892:
-

 Summary: ValidateCSV Processor - no doublequote escaping in 
"invalid" output
 Key: NIFI-4892
 URL: https://issues.apache.org/jira/browse/NIFI-4892
 Project: Apache NiFi
  Issue Type: Improvement
Affects Versions: 1.4.0
Reporter: Eugeny Kolpakov
 Attachments: ValidateCSV_LineByLine_EscapingBug.xml

ValidateCSV processor fails to preserve field escaping for flow files routed to 
"invalid" relation when "Line by Line" validation strategy is used.

 

Observed in 1.4.0, but 1.5.0 might be affected as well - I'll update this 
ticket after upgrading to 1.5.0 (unless someone could do that earlier)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Commented] (NIFI-4833) NIFI-4833 Add ScanHBase processor

2018-02-19 Thread ASF GitHub Bot (JIRA)

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

ASF GitHub Bot commented on NIFI-4833:
--

Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2478#discussion_r169072654
  
--- Diff: 
nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/ScanHBase.java
 ---
@@ -0,0 +1,562 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.hbase;
+
+import org.apache.commons.lang3.StringUtils;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.components.ValidationResult;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.flowfile.attributes.CoreAttributes;
+import org.apache.nifi.hbase.io.JsonFullRowSerializer;
+import org.apache.nifi.hbase.io.JsonQualifierAndValueRowSerializer;
+import org.apache.nifi.hbase.io.RowSerializer;
+import org.apache.nifi.hbase.scan.Column;
+import org.apache.nifi.hbase.scan.ResultCell;
+import org.apache.nifi.hbase.scan.ResultHandler;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.Tuple;
+
+import java.io.IOException;
+import java.nio.charset.Charset;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.regex.Pattern;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@Tags({"hbase", "scan", "fetch", "get"})
+@CapabilityDescription("Scans and fetches rows from an HBase table. This 
processor may be used to fetch rows from hbase table by specifying a range of 
rowkey values (start and/or end ),"
++ "by time range, by filter expression, or any combination of 
them. \n"
++ "Order of records can be controlled by a property 
Reversed"
++ "Number of rows retrieved by the processor can be limited.")
+@WritesAttributes({
+@WritesAttribute(attribute = "hbase.table", description = "The 
name of the HBase table that the row was fetched from"),
+@WritesAttribute(attribute = "hbase.resultset", description = "A 
JSON document/s representing the row/s. This property is only written when a 
Destination of flowfile-attributes is selected."),
+@WritesAttribute(attribute = "mime.type", description = "Set to 
application/json when using a Destination of flowfile-content, not set or 
modified otherwise"),
+@WritesAttribute(attribute = "hbase.rows.count", description = 
"Number of rows in the content of given flow file"),
+@WritesAttribute(attribute = "scanhbase.results.found", 
description = "Indicates whether at least one row has been found in given hbase 
table with provided conditions. "
++ "Could be null (not present) if transfered to FAILURE")
+})
+public class 

[GitHub] nifi pull request #2478: NIFI-4833 Add scanHBase Processor

2018-02-19 Thread MikeThomsen
Github user MikeThomsen commented on a diff in the pull request:

https://github.com/apache/nifi/pull/2478#discussion_r169072654
  
--- Diff: 
nifi-nar-bundles/nifi-hbase-bundle/nifi-hbase-processors/src/main/java/org/apache/nifi/hbase/ScanHBase.java
 ---
@@ -0,0 +1,562 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+package org.apache.nifi.hbase;
+
+import org.apache.commons.lang3.StringUtils;
+import org.apache.nifi.annotation.behavior.InputRequirement;
+import org.apache.nifi.annotation.behavior.WritesAttribute;
+import org.apache.nifi.annotation.behavior.WritesAttributes;
+import org.apache.nifi.annotation.documentation.CapabilityDescription;
+import org.apache.nifi.annotation.documentation.Tags;
+import org.apache.nifi.annotation.lifecycle.OnScheduled;
+import org.apache.nifi.components.AllowableValue;
+import org.apache.nifi.components.PropertyDescriptor;
+import org.apache.nifi.components.ValidationContext;
+import org.apache.nifi.components.ValidationResult;
+import org.apache.nifi.flowfile.FlowFile;
+import org.apache.nifi.flowfile.attributes.CoreAttributes;
+import org.apache.nifi.hbase.io.JsonFullRowSerializer;
+import org.apache.nifi.hbase.io.JsonQualifierAndValueRowSerializer;
+import org.apache.nifi.hbase.io.RowSerializer;
+import org.apache.nifi.hbase.scan.Column;
+import org.apache.nifi.hbase.scan.ResultCell;
+import org.apache.nifi.hbase.scan.ResultHandler;
+import org.apache.nifi.processor.AbstractProcessor;
+import org.apache.nifi.processor.ProcessContext;
+import org.apache.nifi.processor.ProcessSession;
+import org.apache.nifi.processor.Relationship;
+import org.apache.nifi.processor.exception.ProcessException;
+import org.apache.nifi.processor.util.StandardValidators;
+import org.apache.nifi.util.Tuple;
+
+import java.io.IOException;
+import java.nio.charset.Charset;
+import java.nio.charset.StandardCharsets;
+import java.util.ArrayList;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.HashMap;
+import java.util.HashSet;
+import java.util.Iterator;
+import java.util.LinkedList;
+import java.util.List;
+import java.util.Map;
+import java.util.Set;
+import java.util.concurrent.atomic.AtomicReference;
+import java.util.regex.Pattern;
+
+@InputRequirement(InputRequirement.Requirement.INPUT_REQUIRED)
+@Tags({"hbase", "scan", "fetch", "get"})
+@CapabilityDescription("Scans and fetches rows from an HBase table. This 
processor may be used to fetch rows from hbase table by specifying a range of 
rowkey values (start and/or end ),"
++ "by time range, by filter expression, or any combination of 
them. \n"
++ "Order of records can be controlled by a property 
Reversed"
++ "Number of rows retrieved by the processor can be limited.")
+@WritesAttributes({
+@WritesAttribute(attribute = "hbase.table", description = "The 
name of the HBase table that the row was fetched from"),
+@WritesAttribute(attribute = "hbase.resultset", description = "A 
JSON document/s representing the row/s. This property is only written when a 
Destination of flowfile-attributes is selected."),
+@WritesAttribute(attribute = "mime.type", description = "Set to 
application/json when using a Destination of flowfile-content, not set or 
modified otherwise"),
+@WritesAttribute(attribute = "hbase.rows.count", description = 
"Number of rows in the content of given flow file"),
+@WritesAttribute(attribute = "scanhbase.results.found", 
description = "Indicates whether at least one row has been found in given hbase 
table with provided conditions. "
++ "Could be null (not present) if transfered to FAILURE")
+})
+public class ScanHBase extends AbstractProcessor {
+//enhanced regex for columns to allow "-" in column qualifier names
+static final Pattern COLUMNS_PATTERN = 
Pattern.compile("\\w+(:(\\w|-)+)?(?:,\\w+(:(\\w|-)+)?)*");
+

[jira] [Created] (NIFIREG-147) Add Keycloak authentication method

2018-02-19 Thread Gregory Reshetniak (JIRA)
Gregory Reshetniak created NIFIREG-147:
--

 Summary: Add Keycloak authentication method
 Key: NIFIREG-147
 URL: https://issues.apache.org/jira/browse/NIFIREG-147
 Project: NiFi Registry
  Issue Type: Bug
Reporter: Gregory Reshetniak


Keycloak does implement a lot of related functionality, including groups, users 
and such. It would be great to have first-class integration available.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)