date:20161004

[jira] [Commented] (NIFI-2867) The ColumnSize of datetime type is 19 length in MySQL JDBC.

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2867:
--

GitHub user combineads opened a pull request:

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

NIFI-2867 The ColumnSize of datetime type is 19 length in MySQL JDBC

When I use the ConvertJSONToSQL, it changes the field value for data 
capacity of source datastore.


/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430 line
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 
column size. So above code truncate field value to 2016-10-05 12:00:00 from 
2016-10-05 12:00:00.0.
PutSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_51]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.text.ParseException: Unparseable date: "2016-10-05 13:05:43"
at java.text.DateFormat.parse(DateFormat.java:366) ~[na:1.8.0_51]
at 
org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:798) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:626) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
... 13 common frames omitted

Thank you.

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

$ git pull https://github.com/combineads/nifi NIFI-2867

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

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


commit e984aa9dce272b97f0cdb8e1c5b5b35e8af3a0fc
Author: Byunghwa Yun 
Date:   2016-10-05T05:10:21Z

NIFI-2867 The ColumnSize of datetime type is 19 length in MySQL JDBC




> The ColumnSize of datetime type is 19 length in MySQL JDBC.
> ---
>
> Key: NIFI-2867
> URL: https://issues.apache.org/jira/browse/NIFI-2867
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.0
>Reporter: Byunghwa Yun
>Priority: Minor
>
> When I use the ConvertJSONToSQL, it changes the field value for data capacity 
> of source datastore.
>

[GitHub] nifi pull request #1102: NIFI-2867 The ColumnSize of datetime type is 19 len...

2016-10-04 Thread combineads

GitHub user combineads opened a pull request:

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

NIFI-2867 The ColumnSize of datetime type is 19 length in MySQL JDBC

When I use the ConvertJSONToSQL, it changes the field value for data 
capacity of source datastore.


/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430 line
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 
column size. So above code truncate field value to 2016-10-05 12:00:00 from 
2016-10-05 12:00:00.0.
PutSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_51]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.text.ParseException: Unparseable date: "2016-10-05 13:05:43"
at java.text.DateFormat.parse(DateFormat.java:366) ~[na:1.8.0_51]
at 
org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:798) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:626) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
... 13 common frames omitted

Thank you.

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

$ git pull https://github.com/combineads/nifi NIFI-2867

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

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


commit e984aa9dce272b97f0cdb8e1c5b5b35e8af3a0fc
Author: Byunghwa Yun 
Date:   2016-10-05T05:10:21Z

NIFI-2867 The ColumnSize of datetime type is 19 length in MySQL JDBC




---
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] (NIFI-2867) The ColumnSize of datetime type is 19 length in MySQL JDBC.

2016-10-04 Thread Byunghwa Yun (JIRA)


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

Byunghwa Yun updated NIFI-2867:
---
Description: 
When I use the ConvertJSONToSQL, it changes the field value for data capacity 
of source datastore.

/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430 line
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 column 
size. So above code truncate field value to 2016-10-05 12:00:00 from 2016-10-05 
12:00:00.0.
PutSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_51]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.text.ParseException: Unparseable date: "2016-10-05 13:05:43"
at java.text.DateFormat.parse(DateFormat.java:366) ~[na:1.8.0_51]
at 
org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:798) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:626) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
... 13 common frames omitted

Thank you.

  was:
When I use the ConvertJSONToSQL, it changes the field value for data capacity 
of source datastore.

/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 column 
size. So above code truncate field value to 2016-10-05 12:00:00 from 2016-10-05 
12:00:00.0.
PutSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)

[jira] [Updated] (NIFI-2867) The ColumnSize of datetime type is 19 length in MySQL JDBC.

2016-10-04 Thread Byunghwa Yun (JIRA)


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

Byunghwa Yun updated NIFI-2867:
---
Description: 
When I use the ConvertJSONToSQL, it changes the field value for data capacity 
of source datastore.

/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 column 
size. So above code truncate field value to 2016-10-05 12:00:00 from 2016-10-05 
12:00:00.0.
PutSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_51]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.text.ParseException: Unparseable date: "2016-10-05 13:05:43"
at java.text.DateFormat.parse(DateFormat.java:366) ~[na:1.8.0_51]
at 
org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:798) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:626) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
... 13 common frames omitted

Thank you.

  was:
When I use the ConvertJSONToSQL, it changes the field value for data capacity 
of source datastore.

/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 column 
size. So above code truncate field value to 2016-10-05 12:00:00 from 2016-10-05 
12:00:00.0.
PuSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)

[jira] [Created] (NIFI-2867) The ColumnSize of datetime type is 19 length in MySQL JDBC.

2016-10-04 Thread Byunghwa Yun (JIRA)

Byunghwa Yun created NIFI-2867:
--

 Summary: The ColumnSize of datetime type is 19 length in MySQL 
JDBC.
 Key: NIFI-2867
 URL: https://issues.apache.org/jira/browse/NIFI-2867
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.1.0
Reporter: Byunghwa Yun
Priority: Minor


When I use the ConvertJSONToSQL, it changes the field value for data capacity 
of source datastore.

/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/ConvertJSONToSQL.java:
 430
if (colSize != null && fieldValue.length() > colSize) {
fieldValue = fieldValue.substring(0, colSize);
}

But the type of field is datetime in MySQL DB, JDBC driver returns 19 column 
size. So above code truncate field value to 2016-10-05 12:00:00 from 2016-10-05 
12:00:00.0.
PuSQL only resolve the TIMESTAMP type using -MM-dd HH:mm:ss.SSS 
SimpleDateFormat. So it throws below exception.

2016-10-05 13:05:56,526 ERROR [Timer-Driven Process Thread-14] 
o.apache.nifi.processors.standard.PutSQL
org.apache.nifi.processor.exception.ProcessException: The value of the 
sql.args.7.value is '2016-10-05 13:05:43', which cannot be converted to a 
timestamp
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:630) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:241) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1064)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
 [nifi-framework-core-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_51]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_51]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_51]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_51]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_51]
Caused by: java.text.ParseException: Unparseable date: "2016-10-05 13:05:43"
at java.text.DateFormat.parse(DateFormat.java:366) ~[na:1.8.0_51]
at 
org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:798) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:626) 
~[nifi-standard-processors-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
... 13 common frames omitted

Thank you.



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

[jira] [Commented] (NIFI-2866) The Initial Max Value of QueryDatabaseTable won't be case sensitive.

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2866:
--

GitHub user combineads opened a pull request:

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

NIFI-2866 The Initial Max Value of QueryDatabaseTable won't be case

sensitive

Now, the Initial Max Value of QueryDatabaseTable is allowed the only 
lowercase so I think to change the below code, it added .toLowerCase() method.
for(final Map.Entry maxProp : maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase()))
{ statePropertyMap.put(maxProp.getKey().toLowerCase(), maxProp.getValue()); 
}
}
When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have WHERE clause with UPDATE_TIME.
Thanks.

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

$ git pull https://github.com/combineads/nifi NIFI-2866

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

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


commit 821c5c680ba00709198a6e208179672d997b6073
Author: Byunghwa Yun 
Date:   2016-10-05T03:52:53Z

NIFI-2866 The Initial Max Value of QueryDatabaseTable won't be case
sensitive




> The Initial Max Value of QueryDatabaseTable won't be case sensitive.
> 
>
> Key: NIFI-2866
> URL: https://issues.apache.org/jira/browse/NIFI-2866
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.0
>Reporter: Byunghwa Yun
>Priority: Minor
>
> Now, the Initial Max Value of QueryDatabaseTable is allowed the only 
> lowercase so I think to change the below code, it added .toLowerCase() method.
> for(final Map.Entry maxProp : 
> maxValueProperties.entrySet()){
> if 
> (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
> statePropertyMap.put(maxProp.getKey().toLowerCase(), 
> maxProp.getValue());
> }
> }
> When I set the property that is initial.maxvalue.UPDATE_TIME, 
> QueryDatabaseTable doesn't have WHERE clause with UPDATE_TIME.
> Thanks.



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

[GitHub] nifi pull request #1101: NIFI-2866 The Initial Max Value of QueryDatabaseTab...

2016-10-04 Thread combineads

GitHub user combineads opened a pull request:

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

NIFI-2866 The Initial Max Value of QueryDatabaseTable won't be case

sensitive

Now, the Initial Max Value of QueryDatabaseTable is allowed the only 
lowercase so I think to change the below code, it added .toLowerCase() method.
for(final Map.Entry maxProp : maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase()))
{ statePropertyMap.put(maxProp.getKey().toLowerCase(), maxProp.getValue()); 
}
}
When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have WHERE clause with UPDATE_TIME.
Thanks.

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

$ git pull https://github.com/combineads/nifi NIFI-2866

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

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


commit 821c5c680ba00709198a6e208179672d997b6073
Author: Byunghwa Yun 
Date:   2016-10-05T03:52:53Z

NIFI-2866 The Initial Max Value of QueryDatabaseTable won't be case
sensitive




---
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] (NIFI-2866) The Initial Max Value of QueryDatabaseTable won't be case sensitive.

2016-10-04 Thread Byunghwa Yun (JIRA)


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

Byunghwa Yun updated NIFI-2866:
---
Description: 
Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have WHERE clause with UPDATE_TIME.
Thanks.

  was:
Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have WHERE cause with UPDATE_TIME.
Thanks.


> The Initial Max Value of QueryDatabaseTable won't be case sensitive.
> 
>
> Key: NIFI-2866
> URL: https://issues.apache.org/jira/browse/NIFI-2866
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.0
>Reporter: Byunghwa Yun
>Priority: Minor
>
> Now, the Initial Max Value of QueryDatabaseTable is allowed the only 
> lowercase so I think to change the below code, it added .toLowerCase() method.
> for(final Map.Entry maxProp : 
> maxValueProperties.entrySet()){
> if 
> (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
> statePropertyMap.put(maxProp.getKey().toLowerCase(), 
> maxProp.getValue());
> }
> }
> When I set the property that is initial.maxvalue.UPDATE_TIME, 
> QueryDatabaseTable doesn't have WHERE clause with UPDATE_TIME.
> Thanks.



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

[jira] [Updated] (NIFI-2866) The Initial Max Value of QueryDatabaseTable won't be case sensitive.

2016-10-04 Thread Byunghwa Yun (JIRA)


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

Byunghwa Yun updated NIFI-2866:
---
Description: 
Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have where cause with UPDATE_TIME.
Thanks.

  was:
Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

Thanks.


> The Initial Max Value of QueryDatabaseTable won't be case sensitive.
> 
>
> Key: NIFI-2866
> URL: https://issues.apache.org/jira/browse/NIFI-2866
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.0
>Reporter: Byunghwa Yun
>Priority: Minor
>
> Now, the Initial Max Value of QueryDatabaseTable is allowed the only 
> lowercase so I think to change the below code, it added .toLowerCase() method.
> for(final Map.Entry maxProp : 
> maxValueProperties.entrySet()){
> if 
> (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
> statePropertyMap.put(maxProp.getKey().toLowerCase(), 
> maxProp.getValue());
> }
> }
> When I set the property that is initial.maxvalue.UPDATE_TIME, 
> QueryDatabaseTable doesn't have where cause with UPDATE_TIME.
> Thanks.



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

[jira] [Updated] (NIFI-2866) The Initial Max Value of QueryDatabaseTable won't be case sensitive.

2016-10-04 Thread Byunghwa Yun (JIRA)


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

Byunghwa Yun updated NIFI-2866:
---
Description: 
Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have WHERE cause with UPDATE_TIME.
Thanks.

  was:
Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

When I set the property that is initial.maxvalue.UPDATE_TIME, 
QueryDatabaseTable doesn't have where cause with UPDATE_TIME.
Thanks.


> The Initial Max Value of QueryDatabaseTable won't be case sensitive.
> 
>
> Key: NIFI-2866
> URL: https://issues.apache.org/jira/browse/NIFI-2866
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.0
>Reporter: Byunghwa Yun
>Priority: Minor
>
> Now, the Initial Max Value of QueryDatabaseTable is allowed the only 
> lowercase so I think to change the below code, it added .toLowerCase() method.
> for(final Map.Entry maxProp : 
> maxValueProperties.entrySet()){
> if 
> (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
> statePropertyMap.put(maxProp.getKey().toLowerCase(), 
> maxProp.getValue());
> }
> }
> When I set the property that is initial.maxvalue.UPDATE_TIME, 
> QueryDatabaseTable doesn't have WHERE cause with UPDATE_TIME.
> Thanks.



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

[jira] [Updated] (NIFI-2855) NiFi Site-To-Site with port forwarding

2016-10-04 Thread Koji Kawamura (JIRA)


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

Koji Kawamura updated NIFI-2855:

Affects Version/s: 1.0.0
   Status: Patch Available  (was: Open)

> NiFi Site-To-Site with port forwarding
> --
>
> Key: NIFI-2855
> URL: https://issues.apache.org/jira/browse/NIFI-2855
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0
>Reporter: Bryan Rosander
>Assignee: Koji Kawamura
>
> It would be useful to be able to use port forwarding with NiFi Site-To-Site.  
> This would allow NiFi to appear externally to be listening on a privileged 
> port without having been granted elevated permissions.
> For example, an administrator could configure iptables to forward traffic 
> from port 443 to port 9443.  Then users could use NiFi at port 443.  This 
> provides more flexibility as far as firewall configuration is concerned.
> The above scenario causes problems with Site-To-Site though because in a 
> clustered scenario, the nodes will still advertise themselves with port 9443. 
>  This would prevent a Site-To-Site client from being able to talk to them 
> from outside the firewall.
> We need a way (probably a nifi property) to tell NiFi to listen on one port 
> (9443) and advertise another (443) for Site-To-Site purposes to enable this 
> usecase.



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

[jira] [Commented] (NIFI-2855) NiFi Site-To-Site with port forwarding

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2855:
--

GitHub user ijokarumawak opened a pull request:

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

NIFI-2855: Site-to-Site with port forwarding.

This change allows user to run NiFi without root privilege but with low 
port (80 or 443) using port forwarding together.

- Added following properties:
  - nifi.web.http.port.forwarding
  - nifi.web.https.port.forwarding

Please refer the admin guide for detail.

Tested with:
- Local and Cloud Site-to-Site with only either one of 80 or 443 port is 
accessible
- Enabling port forwarding, or without it (direct access)
- Clustered/Standalone
- With proxy
- RAW transport protocol (works as it was)

Any comments are appreciated!

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

$ git pull https://github.com/ijokarumawak/nifi nifi-2855

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

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


commit 0fd5fdc44b12a0c484701080d0c6aca724f4b5ee
Author: Koji Kawamura 
Date:   2016-10-04T10:39:36Z

NIFI-2855: Site-to-Site with port forwarding.

- Added following properties:
  - nifi.web.http.port.forwarding
  - nifi.web.https.port.forwarding




> NiFi Site-To-Site with port forwarding
> --
>
> Key: NIFI-2855
> URL: https://issues.apache.org/jira/browse/NIFI-2855
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Bryan Rosander
>Assignee: Koji Kawamura
>
> It would be useful to be able to use port forwarding with NiFi Site-To-Site.  
> This would allow NiFi to appear externally to be listening on a privileged 
> port without having been granted elevated permissions.
> For example, an administrator could configure iptables to forward traffic 
> from port 443 to port 9443.  Then users could use NiFi at port 443.  This 
> provides more flexibility as far as firewall configuration is concerned.
> The above scenario causes problems with Site-To-Site though because in a 
> clustered scenario, the nodes will still advertise themselves with port 9443. 
>  This would prevent a Site-To-Site client from being able to talk to them 
> from outside the firewall.
> We need a way (probably a nifi property) to tell NiFi to listen on one port 
> (9443) and advertise another (443) for Site-To-Site purposes to enable this 
> usecase.



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

[GitHub] nifi pull request #1100: NIFI-2855: Site-to-Site with port forwarding.

2016-10-04 Thread ijokarumawak

GitHub user ijokarumawak opened a pull request:

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

NIFI-2855: Site-to-Site with port forwarding.

This change allows user to run NiFi without root privilege but with low 
port (80 or 443) using port forwarding together.

- Added following properties:
  - nifi.web.http.port.forwarding
  - nifi.web.https.port.forwarding

Please refer the admin guide for detail.

Tested with:
- Local and Cloud Site-to-Site with only either one of 80 or 443 port is 
accessible
- Enabling port forwarding, or without it (direct access)
- Clustered/Standalone
- With proxy
- RAW transport protocol (works as it was)

Any comments are appreciated!

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

$ git pull https://github.com/ijokarumawak/nifi nifi-2855

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

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


commit 0fd5fdc44b12a0c484701080d0c6aca724f4b5ee
Author: Koji Kawamura 
Date:   2016-10-04T10:39:36Z

NIFI-2855: Site-to-Site with port forwarding.

- Added following properties:
  - nifi.web.http.port.forwarding
  - nifi.web.https.port.forwarding




---
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-2866) The Initial Max Value of QueryDatabaseTable won't be case sensitive.

2016-10-04 Thread Byunghwa Yun (JIRA)

Byunghwa Yun created NIFI-2866:
--

 Summary: The Initial Max Value of QueryDatabaseTable won't be case 
sensitive.
 Key: NIFI-2866
 URL: https://issues.apache.org/jira/browse/NIFI-2866
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.1.0
Reporter: Byunghwa Yun
Priority: Minor


Now, the Initial Max Value of QueryDatabaseTable is allowed the only lowercase 
so I think to change the below code, it added .toLowerCase() method.

for(final Map.Entry maxProp : 
maxValueProperties.entrySet()){
if (!statePropertyMap.containsKey(maxProp.getKey().toLowerCase())) {
statePropertyMap.put(maxProp.getKey().toLowerCase(), 
maxProp.getValue());
}
}

Thanks.



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

[GitHub] nifi pull request #1098: minor typo in expression-language-guide.doc

2016-10-04 Thread asfgit

Github user asfgit closed the pull request at:

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


---
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 #1098: minor typo in expression-language-guide.doc

2016-10-04 Thread alopresto

Github user alopresto commented on the issue:

https://github.com/apache/nifi/pull/1098
  
Reviewing...


---
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 pull request #1098: minor typo in expression-language-guide.doc

2016-10-04 Thread leelaim1

GitHub user leelaim1 reopened a pull request:

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

minor typo in expression-language-guide.doc

delimiter in example was asciidoc syntax

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

$ git pull https://github.com/leelaim1/nifi patch-5

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

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


commit 2d5065d368c4a90d374b2a4a1f104b6c0e227f69
Author: Lee Laim 
Date:   2016-10-04T21:16:37Z

minor typo in expression-language-guide.doc

delimiter in example was asciidoc syntax




---
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 pull request #1098: minor typo in expression-language-guide.doc

2016-10-04 Thread leelaim1

Github user leelaim1 closed the pull request at:

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


---
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-1792) User can create conditions or actions even when no rule exists to attach them to

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1792:
--

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/1099
  
This PR also adjusts the position of the table cell nfel and long text 
editors.


> User can create conditions or actions even when no rule exists to attach them 
> to
> 
>
> Key: NIFI-1792
> URL: https://issues.apache.org/jira/browse/NIFI-1792
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1792_ruleBlank.png
>
>
> Steps to Reproduce:
> 1. Add a Processor to the canvas that has the Advanced button/functionality 
> on the Properties Tab  (UpdateAttribute processor for example)
> 2.  Select "Advanced"
> 3.  If the user attempts to add a condition or action, the UI will not allow 
> it and display the Configuration Error message of "No rule is selected"
> 4.  Select the "+" button to create a new Rule
> 5.  Add the Rule name and select "Add".  A rule is created.
> 6.  Now delete the rule by selecting the "x" next to it and then confirming 
> the deletion.
> 7.  The user can now add multiple conditions and actions at will.  However, 
> when attempting to Save them, the Error message displayed is "Rule name 
> cannot be blank."  But there is no way to add/edit the rule name.  (See 
> attached screenshot)  Any of the work done to add conditions/actions will be 
> lost.



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

[jira] [Assigned] (NIFI-1904) Resizing window while Summary/Counters/etc dropdown activated causes canvas to resize to original size after dropdown closed

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan reassigned NIFI-1904:
-

Assignee: Scott Aslan

> Resizing window while Summary/Counters/etc dropdown activated causes canvas 
> to resize to original size after dropdown closed
> 
>
> Key: NIFI-1904
> URL: https://issues.apache.org/jira/browse/NIFI-1904
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Aldrin Piri
>Assignee: Scott Aslan
>Priority: Minor
>
> When working with the dropwdown (this is the menu item in the top right 
> corner comprised of items such as the Summary/Counters/Bulletins), if the 
> window is resized while this is activated, it seems the original state of the 
> canvas, s0, (this is the entirety of the NiFi workspace) has its original 
> size stored.  
> During the resize, the workspace will expand/contract as anticipated as the 
> browser does, s1, but once the dropdown is closed/loses focus, the workspace 
> will then revert to the size, s0, before the dropdown was activated and 
> manipulated where it is anticipated this would stay in its adjusted state, s1.



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

[GitHub] nifi issue #1099: [NIFI-1792] Clear the selected rule id when deleting the l...

2016-10-04 Thread scottyaslan

Github user scottyaslan commented on the issue:

https://github.com/apache/nifi/pull/1099
  
This PR also adjusts the position of the table cell nfel and long text 
editors.


---
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] (NIFI-1792) User can create conditions or actions even when no rule exists to attach them to

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan updated NIFI-1792:
--
Status: Patch Available  (was: In Progress)

> User can create conditions or actions even when no rule exists to attach them 
> to
> 
>
> Key: NIFI-1792
> URL: https://issues.apache.org/jira/browse/NIFI-1792
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.0, 1.0.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1792_ruleBlank.png
>
>
> Steps to Reproduce:
> 1. Add a Processor to the canvas that has the Advanced button/functionality 
> on the Properties Tab  (UpdateAttribute processor for example)
> 2.  Select "Advanced"
> 3.  If the user attempts to add a condition or action, the UI will not allow 
> it and display the Configuration Error message of "No rule is selected"
> 4.  Select the "+" button to create a new Rule
> 5.  Add the Rule name and select "Add".  A rule is created.
> 6.  Now delete the rule by selecting the "x" next to it and then confirming 
> the deletion.
> 7.  The user can now add multiple conditions and actions at will.  However, 
> when attempting to Save them, the Error message displayed is "Rule name 
> cannot be blank."  But there is no way to add/edit the rule name.  (See 
> attached screenshot)  Any of the work done to add conditions/actions will be 
> lost.



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

[jira] [Commented] (NIFI-1792) User can create conditions or actions even when no rule exists to attach them to

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1792:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-1792] Clear the selected rule id when deleting the last rule in…

… the list. Add scrollable styles when appropriate. Close popups when 
appropriate. Remove draggable on popups

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

$ git pull https://github.com/scottyaslan/nifi NIFI-1792

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

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


commit 44b12fbdb979dbd7e64f1a87e93da4aec45f62ea
Author: Scott Aslan 
Date:   2016-10-04T21:46:37Z

[NIFI-1792] Clear the selected rule id when deleting the last rule in the 
list. Add scrollable styles when appropriate. Close popups when appropriate. 
Remove draggable on popups




> User can create conditions or actions even when no rule exists to attach them 
> to
> 
>
> Key: NIFI-1792
> URL: https://issues.apache.org/jira/browse/NIFI-1792
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1792_ruleBlank.png
>
>
> Steps to Reproduce:
> 1. Add a Processor to the canvas that has the Advanced button/functionality 
> on the Properties Tab  (UpdateAttribute processor for example)
> 2.  Select "Advanced"
> 3.  If the user attempts to add a condition or action, the UI will not allow 
> it and display the Configuration Error message of "No rule is selected"
> 4.  Select the "+" button to create a new Rule
> 5.  Add the Rule name and select "Add".  A rule is created.
> 6.  Now delete the rule by selecting the "x" next to it and then confirming 
> the deletion.
> 7.  The user can now add multiple conditions and actions at will.  However, 
> when attempting to Save them, the Error message displayed is "Rule name 
> cannot be blank."  But there is no way to add/edit the rule name.  (See 
> attached screenshot)  Any of the work done to add conditions/actions will be 
> lost.



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

[GitHub] nifi pull request #1099: [NIFI-1792] Clear the selected rule id when deletin...

2016-10-04 Thread scottyaslan

GitHub user scottyaslan opened a pull request:

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

[NIFI-1792] Clear the selected rule id when deleting the last rule inâ¦

â¦ the list. Add scrollable styles when appropriate. Close popups when 
appropriate. Remove draggable on popups

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

$ git pull https://github.com/scottyaslan/nifi NIFI-1792

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

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


commit 44b12fbdb979dbd7e64f1a87e93da4aec45f62ea
Author: Scott Aslan 
Date:   2016-10-04T21:46:37Z

[NIFI-1792] Clear the selected rule id when deleting the last rule in the 
list. Add scrollable styles when appropriate. Close popups when appropriate. 
Remove draggable on popups




---
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 pull request #1098: minor typo in expression-language-guide.doc

2016-10-04 Thread leelaim1

GitHub user leelaim1 opened a pull request:

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

minor typo in expression-language-guide.doc

delimiter in example was asciidoc syntax

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

$ git pull https://github.com/leelaim1/nifi patch-5

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

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


commit 2d5065d368c4a90d374b2a4a1f104b6c0e227f69
Author: Lee Laim 
Date:   2016-10-04T21:16:37Z

minor typo in expression-language-guide.doc

delimiter in example was asciidoc syntax




---
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-2774) ConsumeJMS processor losses messages on NiFi restart

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2774:
--

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

https://github.com/apache/nifi/pull/1036#discussion_r81854663
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -116,18 +154,26 @@ protected JMSConsumer 
finishBuildingTargetResource(JmsTemplate jmsTemplate) {
 }
 
 /**
+ *
+ */
+@Override
+protected List getSupportedPropertyDescriptors() {
+List pd = new 
ArrayList<>(super.getSupportedPropertyDescriptors());
+pd.add(ACKNOWLEDGEMENT_MODE);
+return pd;
--- End diff --

Fair point. will fix


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[jira] [Commented] (NIFI-2774) ConsumeJMS processor losses messages on NiFi restart

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2774:
--

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

https://github.com/apache/nifi/pull/1036#discussion_r81854487
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -54,8 +61,31 @@
 @SeeAlso(value = { PublishJMS.class, JMSConnectionFactoryProvider.class })
 public class ConsumeJMS extends AbstractJMSProcessor {
 
+static final AllowableValue AUTO_ACK = new 
AllowableValue(String.valueOf(Session.AUTO_ACKNOWLEDGE),
--- End diff --

I see what you're saying, but it's out of my control since the actual 
values is defined by JMS Session interface and 1 is auto-ack and 2 is 
client-ack which is what this JIRA is all about.


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[GitHub] nifi pull request #1036: NIFI-2774 added configurable QoS options

2016-10-04 Thread olegz

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

https://github.com/apache/nifi/pull/1036#discussion_r81854663
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -116,18 +154,26 @@ protected JMSConsumer 
finishBuildingTargetResource(JmsTemplate jmsTemplate) {
 }
 
 /**
+ *
+ */
+@Override
+protected List getSupportedPropertyDescriptors() {
+List pd = new 
ArrayList<>(super.getSupportedPropertyDescriptors());
+pd.add(ACKNOWLEDGEMENT_MODE);
+return pd;
--- End diff --

Fair point. will fix


---
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 pull request #1036: NIFI-2774 added configurable QoS options

2016-10-04 Thread olegz

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

https://github.com/apache/nifi/pull/1036#discussion_r81854487
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -54,8 +61,31 @@
 @SeeAlso(value = { PublishJMS.class, JMSConnectionFactoryProvider.class })
 public class ConsumeJMS extends AbstractJMSProcessor {
 
+static final AllowableValue AUTO_ACK = new 
AllowableValue(String.valueOf(Session.AUTO_ACKNOWLEDGE),
--- End diff --

I see what you're saying, but it's out of my control since the actual 
values is defined by JMS Session interface and 1 is auto-ack and 2 is 
client-ack which is what this JIRA is all about.


---
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-2774) ConsumeJMS processor losses messages on NiFi restart

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2774:
--

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

https://github.com/apache/nifi/pull/1036#discussion_r81854062
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -54,8 +61,31 @@
 @SeeAlso(value = { PublishJMS.class, JMSConnectionFactoryProvider.class })
 public class ConsumeJMS extends AbstractJMSProcessor {
 
+static final AllowableValue AUTO_ACK = new 
AllowableValue(String.valueOf(Session.AUTO_ACKNOWLEDGE),
--- End diff --

It's a bit confusing to see "Default value: 2" when I hover over the 
tooltip for the Acknowledgement Mode property.  It looks like the serialized 
values will be "1", "2", or "3".  Perhaps this is more of a problem in the UI 
rather than AllowableValue definition.


> ConsumeJMS processor losses messages on NiFi restart
> 
>
> Key: NIFI-2774
> URL: https://issues.apache.org/jira/browse/NIFI-2774
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Christopher McDermott
>Assignee: Oleg Zhurakousky
>Priority: Critical
> Fix For: 1.1.0, 0.8.0
>
> Attachments: 2774.patch
>
>
> ConsumeJMS processor uses auto-acknowledge mode.  Unlike the deprecated 
> GetJMSQueue processor it does not provide a way to specify a different ACK 
> mode (i.e. client-acknowledge.)  Using auto-acknowledge, acknowledges message 
> receipt from JMS *before* the messages are actually added to the flow.  This 
> leads to data-loss on NiFi stop (or crash.)
> I believe the fix for this is to allow the user to specify the ACK mode in 
> the processor configuration like is allowed by the GetJMSQueue processor.



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

[GitHub] nifi pull request #1036: NIFI-2774 added configurable QoS options

2016-10-04 Thread mosermw

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

https://github.com/apache/nifi/pull/1036#discussion_r81854062
  
--- Diff: 
nifi-nar-bundles/nifi-jms-bundle/nifi-jms-processors/src/main/java/org/apache/nifi/jms/processors/ConsumeJMS.java
 ---
@@ -54,8 +61,31 @@
 @SeeAlso(value = { PublishJMS.class, JMSConnectionFactoryProvider.class })
 public class ConsumeJMS extends AbstractJMSProcessor {
 
+static final AllowableValue AUTO_ACK = new 
AllowableValue(String.valueOf(Session.AUTO_ACKNOWLEDGE),
--- End diff --

It's a bit confusing to see "Default value: 2" when I hover over the 
tooltip for the Acknowledgement Mode property.  It looks like the serialized 
values will be "1", "2", or "3".  Perhaps this is more of a problem in the UI 
rather than AllowableValue definition.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Resolved] (NIFI-1889) Documentation update needed for GetKafka and PutKafka processors with addition of new Kafka processors

2016-10-04 Thread Andrew Lim (JIRA)


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

Andrew Lim resolved NIFI-1889.
--
Resolution: Duplicate

Dupe of https://issues.apache.org/jira/browse/NIFI-2801

> Documentation update needed for GetKafka and PutKafka processors with 
> addition of new Kafka processors 
> ---
>
> Key: NIFI-1889
> URL: https://issues.apache.org/jira/browse/NIFI-1889
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Reporter: Andrew Lim
>Priority: Minor
>  Labels: documentation
>
> New processors PublishKafka and ConsumeKafka have been created to support 
> Kafka API 0.9+ which is explicitly stated in the usage docs for them.
> We should similarly update the docs for the GetKafka & PutKafka processors so 
> users know what version of the API is supported for them.   This will help 
> distinguish these Kafka processors from one another and make the transition 
> to the new ones smoother, since eventually the Get & Put Kafka processors 
> will be deprecated.



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

[jira] [Commented] (NIFI-2865) Address issues of PublishKafka blocking when having trouble communicating with Kafka broker and improve performance

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2865:
--

GitHub user markap14 opened a pull request:

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

NIFI-2865: Refactored PublishKafka and PublishKafka_0_10 to allow bat…

…ching of FlowFiles within a single publish and to let messages timeout if 
not acknowledged

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

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

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

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


commit 5b10a50ff34150c2642b544e4ee7a855c080b285
Author: Mark Payne 
Date:   2016-09-08T23:37:35Z

NIFI-2865: Refactored PublishKafka and PublishKafka_0_10 to allow batching 
of FlowFiles within a single publish and to let messages timeout if not 
acknowledged




> Address issues of PublishKafka blocking when having trouble communicating 
> with Kafka broker and improve performance
> ---
>
> Key: NIFI-2865
> URL: https://issues.apache.org/jira/browse/NIFI-2865
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Mark Payne
>Assignee: Mark Payne
> Fix For: 1.1.0
>
>
> When NiFi is unable to communicate properly with the Kafka broker, we see the 
> NiFi threads occasionally block. This should be resolvable by calling the 
> wakeup() method of the client. Additionally, if Kafka takes too long to 
> respond, we should be able to route the FlowFile to failure and move on.
> PublishKafka has a nice feature that allows a demarcated stream to be sent as 
> separate messages, so that a large number of messages can be sent as a single 
> FlowFile. However, in the case of individual messages per FlowFile, the 
> performance could be improved by batching together multiple FlowFiles per 
> session



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

[GitHub] nifi pull request #1097: NIFI-2865: Refactored PublishKafka and PublishKafka...

2016-10-04 Thread markap14

GitHub user markap14 opened a pull request:

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

NIFI-2865: Refactored PublishKafka and PublishKafka_0_10 to allow batâ¦

â¦ching of FlowFiles within a single publish and to let messages timeout 
if not acknowledged

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

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

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

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


commit 5b10a50ff34150c2642b544e4ee7a855c080b285
Author: Mark Payne 
Date:   2016-09-08T23:37:35Z

NIFI-2865: Refactored PublishKafka and PublishKafka_0_10 to allow batching 
of FlowFiles within a single publish and to let messages timeout if not 
acknowledged




---
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] [Assigned] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Peter Wicks (JIRA)


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

Peter Wicks reassigned NIFI-2603:
-

Assignee: Peter Wicks

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Peter Wicks (JIRA)


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

Peter Wicks commented on NIFI-2603:
---

I'll work on the tweaks.

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Assignee: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2864) Shell iframes are being attached to the wrong DOM element

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2864:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-2864] Update when shell empties content



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

$ git pull https://github.com/scottyaslan/nifi NIFI-2864

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

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


commit 7e84d50fe51e8d8deffd20e6703bdf1ad34d9674
Author: Scott Aslan 
Date:   2016-10-04T20:07:44Z

[NIFI-2864] Update when shell empties content




> Shell iframes are being attached to the wrong DOM element
> -
>
> Key: NIFI-2864
> URL: https://issues.apache.org/jira/browse/NIFI-2864
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.1.0
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>
> 1) Open any shell that displays content (Like the Policies or Controller 
> Settings)
> 2) Close the shell
> 3) Open any shell that displays an iframe (Like Summary, History, Users, etc.)
> Notice that the iframe is correctly loaded in the DOM but it is attached to 
> the wrong DOM element and thus is no longer visible.



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

[GitHub] nifi pull request #1096: [NIFI-2864] Update when shell empties content

2016-10-04 Thread scottyaslan

GitHub user scottyaslan opened a pull request:

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

[NIFI-2864] Update when shell empties content



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

$ git pull https://github.com/scottyaslan/nifi NIFI-2864

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

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


commit 7e84d50fe51e8d8deffd20e6703bdf1ad34d9674
Author: Scott Aslan 
Date:   2016-10-04T20:07:44Z

[NIFI-2864] Update when shell empties content




---
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-2496) UI - Zoom Fit does not account for an open palette

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2496:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1082
  
The proposed changes seem to help introduce some space from the upper left 
hand corner of the canvas but don't seem to account for the entire width of the 
graph controls. Could it possible be an issue with the scale?


> UI - Zoom Fit does not account for an open palette
> --
>
> Key: NIFI-2496
> URL: https://issues.apache.org/jira/browse/NIFI-2496
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Scott Aslan
>Priority: Minor
> Fix For: 1.1.0
>
>
> When using zoom fit, the viewport calculation does not account for whether 
> the palette(s) are open. This is also true for entering a Process Group for 
> the first time (which simply calls the zoom fit method).



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

[GitHub] nifi issue #1082: [NIFI-2496] Zoom Fit now accounts for an open palette as w...

2016-10-04 Thread mcgilman

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1082
  
The proposed changes seem to help introduce some space from the upper left 
hand corner of the canvas but don't seem to account for the entire width of the 
graph controls. Could it possible be an issue with the scale?


---
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-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran commented on NIFI-2603:
-

Here are color codes and a few other styling details:

Running {code}color: #7bbda2;
text-shadow: 0 0 4px rgba(255,255,255,1);{code}

Stopped {code}color: #d18686;
text-shadow: 0 0 4px rgba(255,255,255,1);{code}

Invalid {code}color: #cea958;
text-shadow: 0 0 4px rgba(255,255,255,1);{code}

Disabled {code}color: #69afcf;
text-shadow: 0 0 4px rgba(255,255,255,1);{code}

For any icon in main/process group flow status bar when value is '0': 
{code}color: #aabec7;
text-shadow: none;{code}

In the process group status bar, the following class should be updated to: 
{code}text.process-group-contents-count {
font-weight: 500;
font-size: 13px;
fill: #775351;
}{code}



> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[GitHub] nifi issue #1082: [NIFI-2496] Zoom Fit now accounts for an open palette as w...

2016-10-04 Thread mcgilman

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1082
  
Reviewing..


---
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-2496) UI - Zoom Fit does not account for an open palette

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2496:
--

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1082
  
Reviewing..


> UI - Zoom Fit does not account for an open palette
> --
>
> Key: NIFI-2496
> URL: https://issues.apache.org/jira/browse/NIFI-2496
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Scott Aslan
>Priority: Minor
> Fix For: 1.1.0
>
>
> When using zoom fit, the viewport calculation does not account for whether 
> the palette(s) are open. This is also true for entering a Process Group for 
> the first time (which simply calls the zoom fit method).



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

[jira] [Commented] (NIFI-2849) UI - Policy Management Enhancements

2016-10-04 Thread Matt Gilman (JIRA)


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

Matt Gilman commented on NIFI-2849:
---

Thanks [~alopresto]. I just updated the PR to default to 'copy' instead of 
'empty' when overriding the inherited policy.

> UI - Policy Management Enhancements
> ---
>
> Key: NIFI-2849
> URL: https://issues.apache.org/jira/browse/NIFI-2849
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> 1 - Show component name whenever possible (specifically in the message 
> regarding the inherited policy).
> 2 - Do not allow editing of inherited policies. Require explicit navigation 
> to the component in question. Support linking to the component in the 
> inherited policy message to make this easier.
> 3 - When overriding a policy, allow the user to optionally copy the inherited 
> policy rules.



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

[jira] [Created] (NIFI-2865) Address issues of PublishKafka blocking when having trouble communicating with Kafka broker and improve performance

2016-10-04 Thread Mark Payne (JIRA)

Mark Payne created NIFI-2865:


 Summary: Address issues of PublishKafka blocking when having 
trouble communicating with Kafka broker and improve performance
 Key: NIFI-2865
 URL: https://issues.apache.org/jira/browse/NIFI-2865
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Reporter: Mark Payne
Assignee: Mark Payne
 Fix For: 1.1.0


When NiFi is unable to communicate properly with the Kafka broker, we see the 
NiFi threads occasionally block. This should be resolvable by calling the 
wakeup() method of the client. Additionally, if Kafka takes too long to 
respond, we should be able to route the FlowFile to failure and move on.

PublishKafka has a nice feature that allows a demarcated stream to be sent as 
separate messages, so that a large number of messages can be sent as a single 
FlowFile. However, in the case of individual messages per FlowFile, the 
performance could be improved by batching together multiple FlowFiles per 
session



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

[GitHub] nifi-minifi pull request #40: MINIFI-46 - Supporting multiple relationships ...

2016-10-04 Thread JPercivall

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

https://github.com/apache/nifi-minifi/pull/40#discussion_r81809792
  
--- Diff: 
minifi-commons/minifi-commons-schema/src/main/java/org/apache/nifi/minifi/commons/schema/ConnectionSchema.java
 ---
@@ -60,7 +63,16 @@ public ConnectionSchema(Map map) {
 if (StringUtil.isNullOrEmpty(sourceId)) {
 sourceName = getRequiredKeyAsType(map, SOURCE_NAME_KEY, 
String.class, CONNECTIONS_KEY);
 }
-sourceRelationshipName = getRequiredKeyAsType(map, 
SOURCE_RELATIONSHIP_NAME_KEY, String.class, CONNECTIONS_KEY);
+
+String sourceRelationshipName = getOptionalKeyAsType(map, 
SOURCE_RELATIONSHIP_NAME_KEY, String.class, CONNECTIONS_KEY, null);
+if (StringUtil.isNullOrEmpty(sourceRelationshipName)) {
+sourceRelationshipNames = getOptionalKeyAsType(map, 
SOURCE_RELATIONSHIP_NAMES_KEY, List.class, CONNECTIONS_KEY, new ArrayList());
+if (sourceRelationshipNames.isEmpty()) {
+
addValidationIssue(getIssueText(SOURCE_RELATIONSHIP_NAMES_KEY, CONNECTIONS_KEY, 
"expected at least one relationship to be specified"));
+}
+} else {
+sourceRelationshipNames = getOptionalKeyAsType(map, 
SOURCE_RELATIONSHIP_NAMES_KEY, List.class, CONNECTIONS_KEY, new 
ArrayList<>(Arrays.asList(sourceRelationshipName)));
--- End diff --

Why use optionalKeyAsType here with the default of 
"sourceRelationshipName"? Wouldn't it be more appropriate to check if "names" 
is set, if so add a validation issue ("name" and "names" shouldn't both be 
set?), else just create a singleton list of "sourceRelationshipName". 


---
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-minifi pull request #40: MINIFI-46 - Supporting multiple relationships ...

2016-10-04 Thread JPercivall

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

https://github.com/apache/nifi-minifi/pull/40#discussion_r81832478
  
--- Diff: 
minifi-commons/minifi-commons-schema/src/main/java/org/apache/nifi/minifi/commons/schema/ConfigSchema.java
 ---
@@ -53,7 +53,7 @@
 public static final String 
FOUND_THE_FOLLOWING_DUPLICATE_REMOTE_INPUT_PORT_IDS = "Found the following 
duplicate remote input port ids: ";
 public static final String FOUND_THE_FOLLOWING_DUPLICATE_IDS = "Found 
the following ids that occur both in Processors and Remote Input Ports: ";
 public static final String 
CANNOT_LOOK_UP_PROCESSOR_ID_FROM_PROCESSOR_NAME_DUE_TO_DUPLICATE_PROCESSOR_NAMES
 = "Cannot look up Processor id from Processor name due to duplicate Processor 
names: ";
-public static final int CONFIG_VERSION = 1;
+public static final int CONFIG_VERSION = 2;
--- End diff --

I was doing some testing around schemas and their version and I think we 
may overlooked validation using the toolkit. I did this test: I have a config 
with a config_version "1" but it has multiple relationships for a connection. 
When I run it through the toolkit validator it will pass because that will work 
in the current implementation but if we took that config file to a MiNiFi 0.0.1 
instance (that would be expected to be able to run a version "1" config) it 
will fail. 

As we go forward with Command and Control (with multiple versions of MiNiFi 
in the wild) I think we'll need to be strict with validation of the config 
version in the toolkit but when the MiNiFi instance is actually trying to run 
it, be as lenient as practical. So use the SchemaLoader to transition any 
keys/formats that were supported in a prior version but not in the future 
version (ie. deprecated things). 

I think this should allow us a go way forward in terms of maintaining 
backwards compatibility while keeping expected functionality. This would be 
outside the scope of this PR/ticket though.



---
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] (NIFI-2856) Queue Listing - Cluster node id is missing

2016-10-04 Thread Matt Gilman (JIRA)


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

Matt Gilman updated NIFI-2856:
--
Status: Patch Available  (was: In Progress)

Addressed in PR https://github.com/apache/nifi/pull/1095 for NIFI-2777. 
Reported as separate JIRAs but actually represent the same bug.

> Queue Listing - Cluster node id is missing
> --
>
> Key: NIFI-2856
> URL: https://issues.apache.org/jira/browse/NIFI-2856
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Core UI
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> The cluster node id appears to be missing when performing a queue listing in 
> clustered mode. As a result, subsequent attempts to directly access that 
> flowfile fail with a message indicating that
> {noformat}The id of the node in the cluster is required{noformat}



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

[jira] [Updated] (NIFI-2777) Provenance Events' Node Identifier not set when querying only 1 node in cluster

2016-10-04 Thread Matt Gilman (JIRA)


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

Matt Gilman updated NIFI-2777:
--
Status: Patch Available  (was: In Progress)

> Provenance Events' Node Identifier not set when querying only 1 node in 
> cluster
> ---
>
> Key: NIFI-2777
> URL: https://issues.apache.org/jira/browse/NIFI-2777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> If I open the Provenance page and search for a FlowFile UUID and restrict the 
> search to a specific node, the Node Identifier is not populated in the events 
> that are returned. As a result, I cannot view the lineage.



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

[jira] [Commented] (NIFI-2777) Provenance Events' Node Identifier not set when querying only 1 node in cluster

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2777:
--

GitHub user mcgilman opened a pull request:

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

Cluster - Merging response when the node is the Cluster Cooridinator

NIFI-2777:
NIFI-2856:
- Only performing response merging when the node is the cluster 
cooridinator even if there is a single response.
- Fixing PropertyDescriptor merging to ensure the 'choosen' descriptor is 
included in map of all responses.

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

$ git pull https://github.com/mcgilman/nifi NIFI-2777

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

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


commit 814a3d1e0c84509fa184533a884cdfb4fc750a9b
Author: Matt Gilman 
Date:   2016-10-04T18:52:18Z

NIFI-2777:
NIFI-2856:
- Only performing response merging when the node is the cluster 
cooridinator even if there is a single response.
- Fixing PropertyDescriptor merging to ensure the 'choosen' descriptor is 
included in map of all responses.




> Provenance Events' Node Identifier not set when querying only 1 node in 
> cluster
> ---
>
> Key: NIFI-2777
> URL: https://issues.apache.org/jira/browse/NIFI-2777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> If I open the Provenance page and search for a FlowFile UUID and restrict the 
> search to a specific node, the Node Identifier is not populated in the events 
> that are returned. As a result, I cannot view the lineage.



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

[jira] [Created] (NIFI-2864) Shell iframes are being attached to the wrong DOM element

2016-10-04 Thread Scott Aslan (JIRA)

Scott Aslan created NIFI-2864:
-

 Summary: Shell iframes are being attached to the wrong DOM element
 Key: NIFI-2864
 URL: https://issues.apache.org/jira/browse/NIFI-2864
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Affects Versions: 1.1.0
Reporter: Scott Aslan


1) Open any shell that displays content (Like the Policies or Controller 
Settings)
2) Close the shell
3) Open any shell that displays an iframe (Like Summary, History, Users, etc.)

Notice that the iframe is correctly loaded in the DOM but it is attached to the 
wrong DOM element and thus is no longer visible.



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

[GitHub] nifi pull request #1095: Cluster - Merging response when the node is the Clu...

2016-10-04 Thread mcgilman

GitHub user mcgilman opened a pull request:

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

Cluster - Merging response when the node is the Cluster Cooridinator

NIFI-2777:
NIFI-2856:
- Only performing response merging when the node is the cluster 
cooridinator even if there is a single response.
- Fixing PropertyDescriptor merging to ensure the 'choosen' descriptor is 
included in map of all responses.

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

$ git pull https://github.com/mcgilman/nifi NIFI-2777

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

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


commit 814a3d1e0c84509fa184533a884cdfb4fc750a9b
Author: Matt Gilman 
Date:   2016-10-04T18:52:18Z

NIFI-2777:
NIFI-2856:
- Only performing response merging when the node is the cluster 
cooridinator even if there is a single response.
- Fixing PropertyDescriptor merging to ensure the 'choosen' descriptor is 
included in map of all responses.




---
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] [Assigned] (NIFI-2864) Shell iframes are being attached to the wrong DOM element

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan reassigned NIFI-2864:
-

Assignee: Scott Aslan

> Shell iframes are being attached to the wrong DOM element
> -
>
> Key: NIFI-2864
> URL: https://issues.apache.org/jira/browse/NIFI-2864
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.1.0
>Reporter: Scott Aslan
>Assignee: Scott Aslan
>
> 1) Open any shell that displays content (Like the Policies or Controller 
> Settings)
> 2) Close the shell
> 3) Open any shell that displays an iframe (Like Summary, History, Users, etc.)
> Notice that the iframe is correctly loaded in the DOM but it is attached to 
> the wrong DOM element and thus is no longer visible.



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

[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan commented on NIFI-2603:
---

[~rmoran] I agree!

[~patricker] It seems like we have a clear consensus of what needs to be 
completed for this ticket. Would you like to grab this and issue a PR?

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2828) SelectHiveQL and PutHiveQL fail with NoClassDefFoundError when using HTTP transport

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2828:
--

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1075
  
Tried this out on against an HDP 2.4 sandbox and got an exception that 
boiled down to:

```
Caused by: java.io.IOException: No FileSystem for scheme: hdfs
at 
org.apache.hadoop.fs.FileSystem.getFileSystemClass(FileSystem.java:2584) 
~[hadoop-common-2.6.2.jar:na]
at 
org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2591) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:91) 
~[hadoop-common-2.6.2.jar:na]
at 
org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2630) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2612) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:296) 
~[hadoop-common-2.6.2.jar:na]
at 
org.apache.hadoop.hive.ql.io.orc.OrcRecordUpdater.(OrcRecordUpdater.java:221)
 ~[hive-exec-1.2.1.jar:1.2.1]
at 
org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat.getRecordUpdater(OrcOutputFormat.java:292)
 ~[hive-exec-1.2.1.jar:1.2.1]
at 
org.apache.hive.hcatalog.streaming.AbstractRecordWriter.createRecordUpdater(AbstractRecordWriter.java:141)
 ~[hive-hcatalog-streaming-1.2.1.jar:1.2.1]
at 
org.apache.hive.hcatalog.streaming.AbstractRecordWriter.newBatch(AbstractRecordWriter.java:121)
 ~[hive-hcatalog-streaming-1.2.1.jar:1.2.1]
... 10 common frames omitted
```
Comparing the JARs that get included with Hadoop Libraries NAR vs the Hive 
NAR there appear to be some differences.

Hadoop Libraries NAR:
hadoop-annotations-2.6.2.jar
hadoop-auth-2.6.2.jar
hadoop-client-2.6.2.jar
hadoop-common-2.6.2.jar
hadoop-hdfs-2.6.2.jar
hadoop-mapreduce-client-app-2.6.2.jar
hadoop-mapreduce-client-common-2.6.2.jar
hadoop-mapreduce-client-core-2.6.2.jar
hadoop-mapreduce-client-jobclient-2.6.2.jar
hadoop-mapreduce-client-shuffle-2.6.2.jar
hadoop-yarn-api-2.6.2.jar
hadoop-yarn-client-2.6.2.jar
hadoop-yarn-common-2.6.2.jar
hadoop-yarn-server-common-2.6.2.jar

Hive NAR:
hadoop-annotations-2.6.2.jar
hadoop-auth-2.6.2.jar
hadoop-common-2.6.2.jar
hadoop-mapreduce-client-core-2.6.2.jar
hadoop-yarn-api-2.6.2.jar
hadoop-yarn-common-2.6.2.jar
hadoop-yarn-server-applicationhistoryservice-2.6.0.jar
hadoop-yarn-server-common-2.6.0.jar
hadoop-yarn-server-resourcemanager-2.6.0.jar
hadoop-yarn-server-web-proxy-2.6.0.jar

I think the Hive NAR at least needs the hadoop-hdfs jar, but not sure what 
else.


> SelectHiveQL and PutHiveQL fail with NoClassDefFoundError when using HTTP 
> transport 
> 
>
> Key: NIFI-2828
> URL: https://issues.apache.org/jira/browse/NIFI-2828
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joey Frazee
>Assignee: Matt Burgess
> Fix For: 1.1.0
>
>
> SelectHiveQL and PutHiveQL don't currently work with HTTP transport. There 
> appears to be a class loader problem resulting in 
> java.lang.NoClassDefFoundError: Could not initialize class 
> org.apache.http.conn.ssl.SSLConnectionSocketFactory.
> This looks like a conflict with the Apache commons httpclient version in 
> hadoop-common. Removing the hadoop-libraries .nar dependency and provided 
> scope for hadoop-common appears to fix the issue, but I haven't done any 
> rigorous testing so I'm not sure if there are other consequences or not.



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

[GitHub] nifi issue #1075: NIFI-2828: Fix Hive NAR dependencies

2016-10-04 Thread bbende

Github user bbende commented on the issue:

https://github.com/apache/nifi/pull/1075
  
Tried this out on against an HDP 2.4 sandbox and got an exception that 
boiled down to:

```
Caused by: java.io.IOException: No FileSystem for scheme: hdfs
at 
org.apache.hadoop.fs.FileSystem.getFileSystemClass(FileSystem.java:2584) 
~[hadoop-common-2.6.2.jar:na]
at 
org.apache.hadoop.fs.FileSystem.createFileSystem(FileSystem.java:2591) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.FileSystem.access$200(FileSystem.java:91) 
~[hadoop-common-2.6.2.jar:na]
at 
org.apache.hadoop.fs.FileSystem$Cache.getInternal(FileSystem.java:2630) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.FileSystem$Cache.get(FileSystem.java:2612) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.FileSystem.get(FileSystem.java:370) 
~[hadoop-common-2.6.2.jar:na]
at org.apache.hadoop.fs.Path.getFileSystem(Path.java:296) 
~[hadoop-common-2.6.2.jar:na]
at 
org.apache.hadoop.hive.ql.io.orc.OrcRecordUpdater.(OrcRecordUpdater.java:221)
 ~[hive-exec-1.2.1.jar:1.2.1]
at 
org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat.getRecordUpdater(OrcOutputFormat.java:292)
 ~[hive-exec-1.2.1.jar:1.2.1]
at 
org.apache.hive.hcatalog.streaming.AbstractRecordWriter.createRecordUpdater(AbstractRecordWriter.java:141)
 ~[hive-hcatalog-streaming-1.2.1.jar:1.2.1]
at 
org.apache.hive.hcatalog.streaming.AbstractRecordWriter.newBatch(AbstractRecordWriter.java:121)
 ~[hive-hcatalog-streaming-1.2.1.jar:1.2.1]
... 10 common frames omitted
```
Comparing the JARs that get included with Hadoop Libraries NAR vs the Hive 
NAR there appear to be some differences.

Hadoop Libraries NAR:
hadoop-annotations-2.6.2.jar
hadoop-auth-2.6.2.jar
hadoop-client-2.6.2.jar
hadoop-common-2.6.2.jar
hadoop-hdfs-2.6.2.jar
hadoop-mapreduce-client-app-2.6.2.jar
hadoop-mapreduce-client-common-2.6.2.jar
hadoop-mapreduce-client-core-2.6.2.jar
hadoop-mapreduce-client-jobclient-2.6.2.jar
hadoop-mapreduce-client-shuffle-2.6.2.jar
hadoop-yarn-api-2.6.2.jar
hadoop-yarn-client-2.6.2.jar
hadoop-yarn-common-2.6.2.jar
hadoop-yarn-server-common-2.6.2.jar

Hive NAR:
hadoop-annotations-2.6.2.jar
hadoop-auth-2.6.2.jar
hadoop-common-2.6.2.jar
hadoop-mapreduce-client-core-2.6.2.jar
hadoop-yarn-api-2.6.2.jar
hadoop-yarn-common-2.6.2.jar
hadoop-yarn-server-applicationhistoryservice-2.6.0.jar
hadoop-yarn-server-common-2.6.0.jar
hadoop-yarn-server-resourcemanager-2.6.0.jar
hadoop-yarn-server-web-proxy-2.6.0.jar

I think the Hive NAR at least needs the hadoop-hdfs jar, but not sure what 
else.


---
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] [Assigned] (NIFI-1792) User can create conditions or actions even when no rule exists to attach them to

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan reassigned NIFI-1792:
-

Assignee: Scott Aslan

> User can create conditions or actions even when no rule exists to attach them 
> to
> 
>
> Key: NIFI-1792
> URL: https://issues.apache.org/jira/browse/NIFI-1792
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1792_ruleBlank.png
>
>
> Steps to Reproduce:
> 1. Add a Processor to the canvas that has the Advanced button/functionality 
> on the Properties Tab  (UpdateAttribute processor for example)
> 2.  Select "Advanced"
> 3.  If the user attempts to add a condition or action, the UI will not allow 
> it and display the Configuration Error message of "No rule is selected"
> 4.  Select the "+" button to create a new Rule
> 5.  Add the Rule name and select "Add".  A rule is created.
> 6.  Now delete the rule by selecting the "x" next to it and then confirming 
> the deletion.
> 7.  The user can now add multiple conditions and actions at will.  However, 
> when attempting to Save them, the Error message displayed is "Rule name 
> cannot be blank."  But there is no way to add/edit the rule name.  (See 
> attached screenshot)  Any of the work done to add conditions/actions will be 
> lost.



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

[jira] [Commented] (NIFI-1794) For rules that have very long names, the name extends beyond the size of the delete confirmation window

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1794:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-1794] Update .dialog-content to wrap text



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

$ git pull https://github.com/scottyaslan/nifi NIFI-1794

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

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


commit 333d98daa4a5d9df60aded36c88636d879624144
Author: Scott Aslan 
Date:   2016-10-04T18:13:17Z

[NIFI-1794] Update .dialog-content to wrap text




> For rules that have very long names, the name extends beyond the size of the 
> delete confirmation window
> ---
>
> Key: NIFI-1794
> URL: https://issues.apache.org/jira/browse/NIFI-1794
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1794_deleteLongRule.png
>
>
> 1.  Create a rule with a very long name.
> 2.  Select "x" next to the rule to delete it.
> 3.  In the Delete Confirmation pop-up window, the name of the rule extends 
> beyond the window (and likely beyond the rules window itself).
> Screenshot attached.



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

[jira] [Updated] (NIFI-2863) A remote process group pointed to a host without the trailing "/nifi" will fail with mis-leading bulletins

2016-10-04 Thread Joseph Percivall (JIRA)


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

Joseph Percivall updated NIFI-2863:
---
Affects Version/s: (was: 1.0.0)

> A remote process group pointed to a host without the trailing "/nifi" will 
> fail with mis-leading bulletins
> --
>
> Key: NIFI-2863
> URL: https://issues.apache.org/jira/browse/NIFI-2863
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Joseph Percivall
>
> To replicate:
> 1: Set up NiFi instance on port 8080 and remote port 8081 (unsecure S2S)
> 2: create input port
> 3: create RPG pointing to "http://localhost:8080;
> This RPG will correctly get the instance name, listing of ports and port 
> status but when transmission is enabled and a flowfile is queued to be sent 
> the  following error is generated:
> "RemoteGroupPort[name=test1,target=http://localhost:8080] failed to 
> communicate with http://localhost:8080 due to 
> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 
> 60)): expected a valid value (number, String, array, object, 'true', 'false' 
> or 'null')
>  at [Source: java.io.StringReader@44d519ce; line: 3, column: 2]"
> Looking at the logs there is this message:
> 2016-10-04 14:11:34,298 WARN [Timer-Driven Process Thread-2] 
> o.a.n.r.util.SiteToSiteRestApiClient Failed to parse Json, response=
> 
> 
> 
> 
> 
> NiFi
> 
>  />
>  type="text/css" />
>  href="/nifi/assets/font-awesome/css/font-awesome.min.css" type="text/css" />
>  type="text/css" />
>  type="text/css" />
> 
> 
> 
> 
> Did you mean: /nifi
> 
> You may have mistyped...
> 
> 
> 
> 2016-10-04 14:11:34,298 ERROR [Timer-Driven Process Thread-2] 
> o.a.nifi.remote.StandardRemoteGroupPort 
> RemoteGroupPort[name=test1,target=http://localhost:8080] failed to 
> communicate with http://localhost:8080 due to 
> org.codehaus.jackson.JsonParseException: Unexpected character ('<' (code 
> 60)): expected a valid value (number, String, array, object, 'true', 'false' 
> or 'null')
>  at [Source: java.io.StringReader@44d519ce; line: 3, column: 2]
> This should either be fixed (to allow without "/nifi") or explicitly 
> validated.



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

[jira] [Updated] (NIFI-1794) For rules that have very long names, the name extends beyond the size of the delete confirmation window

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan updated NIFI-1794:
--
Status: Patch Available  (was: In Progress)

> For rules that have very long names, the name extends beyond the size of the 
> delete confirmation window
> ---
>
> Key: NIFI-1794
> URL: https://issues.apache.org/jira/browse/NIFI-1794
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1794_deleteLongRule.png
>
>
> 1.  Create a rule with a very long name.
> 2.  Select "x" next to the rule to delete it.
> 3.  In the Delete Confirmation pop-up window, the name of the rule extends 
> beyond the window (and likely beyond the rules window itself).
> Screenshot attached.



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

[GitHub] nifi pull request #1094: [NIFI-1794] Update .dialog-content to wrap text

2016-10-04 Thread scottyaslan

GitHub user scottyaslan opened a pull request:

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

[NIFI-1794] Update .dialog-content to wrap text



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

$ git pull https://github.com/scottyaslan/nifi NIFI-1794

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

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


commit 333d98daa4a5d9df60aded36c88636d879624144
Author: Scott Aslan 
Date:   2016-10-04T18:13:17Z

[NIFI-1794] Update .dialog-content to wrap text




---
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-2863) A remote process group pointed to a host without the trailing "/nifi" will fail with mis-leading bulletins

2016-10-04 Thread Joseph Percivall (JIRA)

Joseph Percivall created NIFI-2863:
--

 Summary: A remote process group pointed to a host without the 
trailing "/nifi" will fail with mis-leading bulletins
 Key: NIFI-2863
 URL: https://issues.apache.org/jira/browse/NIFI-2863
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.0.0
Reporter: Joseph Percivall


To replicate:

1: Set up NiFi instance on port 8080 and remote port 8081 (unsecure S2S)
2: create input port
3: create RPG pointing to "http://localhost:8080;

This RPG will correctly get the instance name, listing of ports and port status 
but when transmission is enabled and a flowfile is queued to be sent the  
following error is generated:

"RemoteGroupPort[name=test1,target=http://localhost:8080] failed to communicate 
with http://localhost:8080 due to org.codehaus.jackson.JsonParseException: 
Unexpected character ('<' (code 60)): expected a valid value (number, String, 
array, object, 'true', 'false' or 'null')
 at [Source: java.io.StringReader@44d519ce; line: 3, column: 2]"

Looking at the logs there is this message:

2016-10-04 14:11:34,298 WARN [Timer-Driven Process Thread-2] 
o.a.n.r.util.SiteToSiteRestApiClient Failed to parse Json, response=







NiFi











Did you mean: /nifi

You may have mistyped...




2016-10-04 14:11:34,298 ERROR [Timer-Driven Process Thread-2] 
o.a.nifi.remote.StandardRemoteGroupPort 
RemoteGroupPort[name=test1,target=http://localhost:8080] failed to communicate 
with http://localhost:8080 due to org.codehaus.jackson.JsonParseException: 
Unexpected character ('<' (code 60)): expected a valid value (number, String, 
array, object, 'true', 'false' or 'null')
 at [Source: java.io.StringReader@44d519ce; line: 3, column: 2]


This should either be fixed (to allow without "/nifi") or explicitly validated.




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

[jira] [Assigned] (NIFI-2777) Provenance Events' Node Identifier not set when querying only 1 node in cluster

2016-10-04 Thread Matt Gilman (JIRA)


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

Matt Gilman reassigned NIFI-2777:
-

Assignee: Matt Gilman  (was: Mark Payne)

> Provenance Events' Node Identifier not set when querying only 1 node in 
> cluster
> ---
>
> Key: NIFI-2777
> URL: https://issues.apache.org/jira/browse/NIFI-2777
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Mark Payne
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> If I open the Provenance page and search for a FlowFile UUID and restrict the 
> search to a specific node, the Node Identifier is not populated in the events 
> that are returned. As a result, I cannot view the lineage.



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

[jira] [Updated] (NIFI-2862) Add Stateful annotation to scripting processors

2016-10-04 Thread Peter Mitchell (JIRA)


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

Peter Mitchell updated NIFI-2862:
-
Status: Patch Available  (was: Open)

> Add Stateful annotation to scripting processors
> ---
>
> Key: NIFI-2862
> URL: https://issues.apache.org/jira/browse/NIFI-2862
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Peter Mitchell
>Priority: Trivial
> Attachments: nifi-2862.patch
>
>
> Scripting processors are able to access the state management apis. It would 
> be useful to have the Stateful annotation added to these processors to enable 
> DFMs to clear any state that may be stored by a script.



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

[jira] [Updated] (NIFI-2862) Add Stateful annotation to scripting processors

2016-10-04 Thread Peter Mitchell (JIRA)


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

Peter Mitchell updated NIFI-2862:
-
Attachment: nifi-2862.patch

> Add Stateful annotation to scripting processors
> ---
>
> Key: NIFI-2862
> URL: https://issues.apache.org/jira/browse/NIFI-2862
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Peter Mitchell
>Priority: Trivial
> Attachments: nifi-2862.patch
>
>
> Scripting processors are able to access the state management apis. It would 
> be useful to have the Stateful annotation added to these processors to enable 
> DFMs to clear any state that may be stored by a script.



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

[jira] [Created] (NIFI-2862) Add Stateful annotation to scripting processors

2016-10-04 Thread Peter Mitchell (JIRA)

Peter Mitchell created NIFI-2862:


 Summary: Add Stateful annotation to scripting processors
 Key: NIFI-2862
 URL: https://issues.apache.org/jira/browse/NIFI-2862
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Peter Mitchell
Priority: Trivial


Scripting processors are able to access the state management apis. It would be 
useful to have the Stateful annotation added to these processors to enable DFMs 
to clear any state that may be stored by a script.



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

[jira] [Commented] (NIFI-1337) Add Riemann Reporting Task

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1337:
--

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/188
  
@rickysaltzer cool thanks for following up.  And hope you enjoyed your time 
away.


> Add Riemann Reporting Task
> --
>
> Key: NIFI-1337
> URL: https://issues.apache.org/jira/browse/NIFI-1337
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
> Attachments: example-graph.png, riemann-reporting-configuration.png
>
>
> It would be beneficial for NiFi to report health information to 
> [Riemann|http://riemann.io] for monitoring purposes. I plan on implementing 
> this, and will use this JIRA to track the progress. 



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

[GitHub] nifi issue #188: NIFI-1337: Add Riemann Reporting Task

2016-10-04 Thread joewitt

Github user joewitt commented on the issue:

https://github.com/apache/nifi/pull/188
  
@rickysaltzer cool thanks for following up.  And hope you enjoyed your time 
away.


---
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-1337) Add Riemann Reporting Task

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1337:
--

Github user rickysaltzer commented on the issue:

https://github.com/apache/nifi/pull/188
  
@trixpan I can close this for now 


> Add Riemann Reporting Task
> --
>
> Key: NIFI-1337
> URL: https://issues.apache.org/jira/browse/NIFI-1337
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
> Attachments: example-graph.png, riemann-reporting-configuration.png
>
>
> It would be beneficial for NiFi to report health information to 
> [Riemann|http://riemann.io] for monitoring purposes. I plan on implementing 
> this, and will use this JIRA to track the progress. 



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

[jira] [Commented] (NIFI-1636) Print entire stacktrace when unexpected exception occurs during onTrigger

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1636:
--

Github user rickysaltzer closed the pull request at:

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


> Print entire stacktrace when unexpected exception occurs during onTrigger
> -
>
> Key: NIFI-1636
> URL: https://issues.apache.org/jira/browse/NIFI-1636
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
>
> As of now the try/catch clause in the {{AbstractProcessor}} class doesn't 
> print the entire stacktrace when a processor throws an unexpected exception. 
> Printing the entire stacktrace comes especially in handy when users are 
> creating custom processors for internal use.
> The difference in information can be seen below:
> *Before*
> {code}
> java.lang.NumberFormatException: For input string: "five"
> {code}
> *After*
> {code}
> java.lang.NumberFormatException: For input string: "five"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:580)
>   at java.lang.Integer.parseInt(Integer.java:615)
>   at TestException.main(TestException.java:5)
> {code}



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

[jira] [Commented] (NIFI-1337) Add Riemann Reporting Task

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1337:
--

Github user rickysaltzer closed the pull request at:

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


> Add Riemann Reporting Task
> --
>
> Key: NIFI-1337
> URL: https://issues.apache.org/jira/browse/NIFI-1337
> Project: Apache NiFi
>  Issue Type: New Feature
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
> Attachments: example-graph.png, riemann-reporting-configuration.png
>
>
> It would be beneficial for NiFi to report health information to 
> [Riemann|http://riemann.io] for monitoring purposes. I plan on implementing 
> this, and will use this JIRA to track the progress. 



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

[jira] [Commented] (NIFI-1636) Print entire stacktrace when unexpected exception occurs during onTrigger

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1636:
--

Github user rickysaltzer commented on the issue:

https://github.com/apache/nifi/pull/285
  
@trixpan thanks for the reminder, closing...


> Print entire stacktrace when unexpected exception occurs during onTrigger
> -
>
> Key: NIFI-1636
> URL: https://issues.apache.org/jira/browse/NIFI-1636
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Ricky Saltzer
>Assignee: Ricky Saltzer
>
> As of now the try/catch clause in the {{AbstractProcessor}} class doesn't 
> print the entire stacktrace when a processor throws an unexpected exception. 
> Printing the entire stacktrace comes especially in handy when users are 
> creating custom processors for internal use.
> The difference in information can be seen below:
> *Before*
> {code}
> java.lang.NumberFormatException: For input string: "five"
> {code}
> *After*
> {code}
> java.lang.NumberFormatException: For input string: "five"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
>   at java.lang.Integer.parseInt(Integer.java:580)
>   at java.lang.Integer.parseInt(Integer.java:615)
>   at TestException.main(TestException.java:5)
> {code}



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

[GitHub] nifi pull request #188: NIFI-1337: Add Riemann Reporting Task

2016-10-04 Thread rickysaltzer

Github user rickysaltzer closed the pull request at:

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


---
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 pull request #285: NIFI-1636: Print Stacktrace When Unexpected OnTrigge...

2016-10-04 Thread rickysaltzer

Github user rickysaltzer closed the pull request at:

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


---
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 #285: NIFI-1636: Print Stacktrace When Unexpected OnTrigger Excep...

2016-10-04 Thread rickysaltzer

Github user rickysaltzer commented on the issue:

https://github.com/apache/nifi/pull/285
  
@trixpan thanks for the reminder, closing...


---
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-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran commented on NIFI-2603:
-

Thanks [~patricker]. I'm still of the mindset to work introductions of color 
into to UI with a little more subtlety, hence the softer and more desaturated 
color palette. As we introduce more awareness into the UI to reflect status 
changes, bulletins, warnings, etc. I feel we'll need to be more selective in 
how and when we use vivid color.

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Peter Wicks (JIRA)


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

Peter Wicks commented on NIFI-2603:
---

[~rmoran] I like all of your suggestions surrounding when to color icons, when 
to not color icons.  It should help draw attention to the right issues.

I know I'm a little biased, but I prefer the less muted colors I proposed 
earlier :)

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Created] (NIFI-2861) ControlRate should accept more than one flow file per execution

2016-10-04 Thread Joe Skora (JIRA)

Joe Skora created NIFI-2861:
---

 Summary: ControlRate should accept more than one flow file per 
execution
 Key: NIFI-2861
 URL: https://issues.apache.org/jira/browse/NIFI-2861
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 0.7.0, 1.0.0
Reporter: Joe Skora
Assignee: Joe Skora


The {{ControlRate}} processor implements a {{FlowFileFilter}} that returns the 
{{FlowFileFilter.ACCEPT_AND_TERMINATE}} result if the {{FlowFile}} fits with 
the rate limit, affectively limiting it to one {{FlowFile}} per 
{{ConrolRate.onTrigger()}} invocation.  This is a significant bottleneck when 
processing very large quantities of small files making it unlikely to hit the 
rate limits.

It should allow multiple files, perhaps with a configurable maximum, per 
{{ControlRate.onTrigger()}} invocation by issuing the 
{{FlowFileFilter.ACCEPT_AND_CONTINUE}} result until the limits are reached.  In 
a preliminary test this eliminated the bottleneck.



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

[jira] [Commented] (NIFI-1613) ConvertJSONToSQL Drops Type Information

2016-10-04 Thread Toivo Adams (JIRA)


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

Toivo Adams commented on NIFI-1613:
---

Hi @trixpan

If I remember correctly, Boolean and Numeric types handling is improved.

But DATE, TIME and TIMESTAMP handling is still problematic. (when used together 
with PutSQL processor)
PutSQL expects Long numeric types.
But JSON usually uses ISO 8601, for example: 2012-04-23T18:25:43.511Z for dates.
This means PutSql will fail.

Maybe PutSQL should be changed? But change may break current PutSQL behavior.
Workaround maybe change PutSQL in the way there:
1. We first try to convert numeric value.
2. If conversion fails we try to convert String value.
This way we can preserve current behaviour.

Thanks
Toivo


> ConvertJSONToSQL Drops Type Information
> ---
>
> Key: NIFI-1613
> URL: https://issues.apache.org/jira/browse/NIFI-1613
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.4.1, 0.5.1
> Environment: Ubuntu 14.04 LTS
>Reporter: Aaron Stephens
>Assignee: Toivo Adams
>  Labels: ConvertJSONToSQL, Phoenix, SQL
>
> It appears that the ConvertJSONToSQL processor is turning Boolean (and 
> possibly Integer and Float) values into Strings.  This is okay for some 
> drivers (like PostgreSQL) which can coerce a String back into a Boolean, but 
> it causes issues for others (specifically Phoenix in my case).
> {noformat}
> org.apache.phoenix.schema.ConstraintViolationException: 
> org.apache.phoenix.schema.TypeMismatchException: ERROR 203 (22005): Type 
> mismatch. VARCHAR cannot be coerced to BOOLEAN
> at 
> org.apache.phoenix.schema.types.PDataType.throwConstraintViolationException(PDataType.java:282)
>  ~[na:na]
> at 
> org.apache.phoenix.schema.types.PBoolean.toObject(PBoolean.java:136) ~[na:na]
> at 
> org.apache.phoenix.jdbc.PhoenixPreparedStatement.setObject(PhoenixPreparedStatement.java:442)
>  ~[na:na]
> at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
>  ~[na:na]
> at 
> org.apache.commons.dbcp.DelegatingPreparedStatement.setObject(DelegatingPreparedStatement.java:166)
>  ~[na:na]
> at 
> org.apache.nifi.processors.standard.PutSQL.setParameter(PutSQL.java:728) 
> ~[na:na]
> at 
> org.apache.nifi.processors.standard.PutSQL.setParameters(PutSQL.java:606) 
> ~[na:na]
> at 
> org.apache.nifi.processors.standard.PutSQL.onTrigger(PutSQL.java:223) ~[na:na]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-0.4.1.jar:0.4.1]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1146)
>  ~[nifi-framework-core-0.4.1.jar:0.4.1]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:139)
>  [nifi-framework-core-0.4.1.jar:0.4.1]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:49)
>  [nifi-framework-core-0.4.1.jar:0.4.1]
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:119)
>  [nifi-framework-core-0.4.1.jar:0.4.1]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) 
> [na:1.7.0_79]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304) 
> [na:1.7.0_79]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
>  [na:1.7.0_79]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [na:1.7.0_79]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>  [na:1.7.0_79]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>  [na:1.7.0_79]
> at java.lang.Thread.run(Thread.java:745) [na:1.7.0_79]
> Caused by: org.apache.phoenix.schema.TypeMismatchException: ERROR 203 
> (22005): Type mismatch. VARCHAR cannot be coerced to BOOLEAN
> at 
> org.apache.phoenix.exception.SQLExceptionCode$1.newException(SQLExceptionCode.java:71)
>  ~[na:na]
> at 
> org.apache.phoenix.exception.SQLExceptionInfo.buildException(SQLExceptionInfo.java:145)
>  ~[na:na]
> ... 20 common frames omitted
> {noformat}



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

[jira] [Updated] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran updated NIFI-2603:

Attachment: summary-shell.png
status-bars-and-components.png
settings-shell-reporting-tasks.png
settings-shell-controller-services.png

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: settings-shell-controller-services.png, 
> settings-shell-reporting-tasks.png, status-bars-and-components.png, 
> summary-shell.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Updated] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran updated NIFI-2603:

Attachment: (was: status-icon-color.png)

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2448) Hive Processors depend on too recent a Hive version

2016-10-04 Thread Tomasz Domanski (JIRA)


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

Tomasz Domanski commented on NIFI-2448:
---

Great reply [~mattyb149] thx you for that! I think I will go with producing 
different NAR's as I will need to be able to support different versions of HDP 
and CDH. 

Thx again.

> Hive Processors depend on too recent a Hive version
> ---
>
> Key: NIFI-2448
> URL: https://issues.apache.org/jira/browse/NIFI-2448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Simon Elliston Ball
>Priority: Critical
>
> The new Hive bundle depends on version 2.0.0 of Hive. This means that it can 
> only connect to very recent Hive distributions. 
> Sadly very few people in the field have upgraded their Hive to the latest and 
> greatest, and as per https://issues.apache.org/jira/browse/HIVE-6050 the 
> issue of backward compatibility in the client is still not resolved.
> We should look at lowering the dependency version to allow connections with 
> older Hive distros.



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

[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran commented on NIFI-2603:
-

Will do

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: status-icon-color.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2448) Hive Processors depend on too recent a Hive version

2016-10-04 Thread Matt Burgess (JIRA)


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

Matt Burgess commented on NIFI-2448:


[~tom_dom] All the Hive processors are in a single NiFi ARchive (aka NAR) so 
they can share Hadoop/Hive dependencies. In order to support more Hive 
deployments in the field, this Jira was raised to downgrade the Hive NAR (which 
includes PutHiveStreaming, the two HiveQL processors, and ConvertAvroToORC) to 
Apache Hive 1.2.1. However there are still versions of Hive/Hadoop that are not 
fully compatible with the NiFi 1.0.0 Hive processors, notably Hortonworks Data 
Platform 2.5 and your Cloudera instance (which is based on Hive 1.1 but I don't 
believe is the Apache Hive 1.1 release, rather it has a 1.1 baseline with other 
things added).

Getting the Hadoop and Hive processors in lockstep for greatest compatibility 
has been a challenge, and solutions have been offered/proposed (such as 
NIFI-710, NIFI-2026, and NIFI-2828). With the latter two, a workaround is to 
build your own Hive NAR against a chosen version of Hadoop/Hive. For example, 
to build the Hive NAR for HDP 2.5 compatibility:

mvn clean install -Phortonworks -Dhive.version=1.2.1000.2.5.0.0-1245 
-Dhadoop.version=2.7.3.2.5.0.0-1245

However for Cloudera 5.5.2, the baseline version of Hive 1.1 is even older than 
the NiFi baseline (Apache NiFi 1.2.1), and as a result does not have some of 
the classes/fixes needed by the Hive NAR code (such as the ConvertAvroToORC 
processor). In order to create a Hive NAR for to support that version, you 
would need to remove the ConvertAvroToORC processor (and its auxiliary classes) 
from the code, then build with something like:

mvn clean install -Pcloudera -Dhive.version=1.1.0-cdh5.5.2 
-Dhadoop.version=2.6.0-cdh5.5.2

A different solution might be to create a hive-libraries-nar and split up the 
processors into separate NARs, but that's a lot of overhead just to support 
various distros that have their own versions of Hadoop/Hive, especially when 
the above technique can be used to build the right NAR for the right vendor 
platform/version. Out of the box, Apache NiFi 1.0.0 works with Apache Hadoop 
2.6.2 and Apache Hive 1.2.1. When incompatibilities arise, they are almost 
always due to extra "features" being in vendor deployments that aren't in the 
corresponding Apache baseline.

Hopefully this is just an awkward transition phase for these project(s), and 
with any luck we can soon upgrade NiFi to use a newer Hadoop, Hive 2.x, and 
Apache ORC, the combination of which should give a better level of 
compatibility than we're seeing at present.


> Hive Processors depend on too recent a Hive version
> ---
>
> Key: NIFI-2448
> URL: https://issues.apache.org/jira/browse/NIFI-2448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Simon Elliston Ball
>Priority: Critical
>
> The new Hive bundle depends on version 2.0.0 of Hive. This means that it can 
> only connect to very recent Hive distributions. 
> Sadly very few people in the field have upgraded their Hive to the latest and 
> greatest, and as per https://issues.apache.org/jira/browse/HIVE-6050 the 
> issue of backward compatibility in the client is still not resolved.
> We should look at lowering the dependency version to allow connections with 
> older Hive distros.



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

[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Scott Aslan (JIRA)


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

Scott Aslan commented on NIFI-2603:
---

Exactly! Is there any way you could mock these additional views?

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: status-icon-color.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Commented] (NIFI-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran commented on NIFI-2603:
-

Just to clarify we'd use the color icons reporting run status on other 
component faces as well – like connections and ports, for example.

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: status-icon-color.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Created] (NIFI-2860) Use different properties for JVM Heap Max and Min values

2016-10-04 Thread Andrew Festa (JIRA)

Andrew Festa created NIFI-2860:
--

 Summary: Use different properties for JVM Heap Max and Min values
 Key: NIFI-2860
 URL: https://issues.apache.org/jira/browse/NIFI-2860
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Configuration
Affects Versions: 0.6.1
Reporter: Andrew Festa


In the bootstrap.conf, the JVM memory settings are using maven filtering to set 
the default values.  Currently the JVM memory settings (java.arg.2 and 
java.arg.3) are using the same property.  These should be using different 
values so we can override them to different values.

https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-resources/src/main/resources/conf/bootstrap.conf#L35-L36



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

[jira] [Commented] (NIFI-1069) Nifi Service Status return 0 when service not running

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-1069:
--

GitHub user michalklempa opened a pull request:

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

Fixes NIFI-1069 init script status exit code 3 when not running

Fixes NIFI-1069 init script status exit code 3 when not running , 0 when 
running

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

$ git pull https://github.com/michalklempa/nifi 
NIFI-1069_fix_init_status_exit_code

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

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


commit 460da679ed66e6d7ba1c93b06d5660f2d7a0a70b
Author: Michal Klempa 
Date:   2016-10-04T12:25:49Z

Fixes NIFI-1069 init script status exit code 3 when not running, 0 when 
running




> Nifi Service Status return 0 when service not running
> -
>
> Key: NIFI-1069
> URL: https://issues.apache.org/jira/browse/NIFI-1069
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.3.0
> Environment: CentOS 6.7
>Reporter: Andy Kruth
>Priority: Minor
>
> After successfully installing Nifi as a service with the following command:
> sudo /opt/nifi-0.3.0/bin/nifi.sh install
> running service nifi status has a return code of 0.
> According to 
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html
>  if the service is not running then status should return 3.
> This is not a major issue, you can still start and stop the service just 
> fine, but when using an idempotent tool like Ansible you cannot start the 
> service because the return code of status says the service is already started.



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

[GitHub] nifi pull request #1093: Fixes NIFI-1069 init script status exit code 3 when...

2016-10-04 Thread michalklempa

GitHub user michalklempa opened a pull request:

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

Fixes NIFI-1069 init script status exit code 3 when not running

Fixes NIFI-1069 init script status exit code 3 when not running , 0 when 
running

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

$ git pull https://github.com/michalklempa/nifi 
NIFI-1069_fix_init_status_exit_code

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

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


commit 460da679ed66e6d7ba1c93b06d5660f2d7a0a70b
Author: Michal Klempa 
Date:   2016-10-04T12:25:49Z

Fixes NIFI-1069 init script status exit code 3 when not running, 0 when 
running




---
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-2603) Bringing Some UI Color Back

2016-10-04 Thread Rob Moran (JIRA)


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

Rob Moran commented on NIFI-2603:
-

[~scottyaslan] yeah we should use the colored icons wherever we're reporting 
run status such as the column in the Summary shell, and controller 
service/reporting task states in the Settings shell. Is that what you are 
thinking as well?

Oh, we should also use the same design for process group status bars.

> Bringing Some UI Color Back
> ---
>
> Key: NIFI-2603
> URL: https://issues.apache.org/jira/browse/NIFI-2603
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Reporter: Peter Wicks
>Priority: Minor
> Attachments: status-icon-color.png
>
>
> In the new 1.0 UI all of the colors associated with status (except the orange 
> triangle) are gone; replaced with a dark gray color.
> I propose bringing back color.  The screenshots are in the format of before 
> on the top and after on the bottom, except were labeled in the picture itself:
>  - Top Status Menu: https://goo.gl/photos/se1JnvhRwU7N4Fap7
>  - Process Group: https://goo.gl/photos/dqjG4KvC6xqxQfgT7
>  - Processes (Running/Stopped/Invalid): 
> https://goo.gl/photos/dSS8vgE2RkrXtc77A
>  - Operate Play/Stop buttons (only on mouse hover): 
> https://goo.gl/photos/Am5SUEEn7G9RjmMe6
>  - Processor/Processor Group Context Menu: 
> https://goo.gl/photos/Jq3qFg4ezaN91qms5
> This is not a "100% done, I've covered everything" before/after list.  I know 
> I need to do the NiFi summary page also at the minimum.



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

[jira] [Updated] (NIFI-2199) NiFi cannot be restarted through SSH (nifi.sh hangs)

2016-10-04 Thread Michal Klempa (JIRA)


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

Michal Klempa updated NIFI-2199:

Affects Version/s: 0.7.0

> NiFi cannot be restarted through SSH (nifi.sh hangs)
> 
>
> Key: NIFI-2199
> URL: https://issues.apache.org/jira/browse/NIFI-2199
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.5.1, 0.7.0, 0.6.1
>Reporter: Michal Klempa
>Priority: Minor
>  Labels: initscript
>
> When NiFi is to restarted using SSH from remote host, nifi.sh causes SSH to 
> hang on open io streams.
> Steps to reproduce:
> 1. HostA - NiFi instalation
> 2. HostB - client machine
> 3. log to HostB
> 4. issue a command
> {code}
> ssh root@HostA /etc/init.d/nifi restart
> {code}
> Expected behavior: NiFi is restarted, SSH command exits with 0
> Actual behavior: NiFi is restarted, SSH command hang on
> This seems to be somehow related to SSH handling IO streams of process. Seems 
> like detached NiFi java process does not close stdin/out/err (i do not know 
> precisely) leading to sshd waiting for some input/output to come to client.
> I was able to do a quick fix in nifi.sh as follows:
> 1. on existing nifi installation, in file /etc/init.d/nifi find the line
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ &)
> {code}
> its line number 214 (true branch of if [ "$1"] = "start"] condition).
> 2. replace it by line:
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ > /dev/null 2>&1 < /dev/null &)
> {code}
> This simply redirects stdin from /dev/null to NiFi java process and redirects 
> stdout/err to /dev/null letting SSH to close the session.
> After applying this fix, I am able to restart NiFi remotely using SSH.
> Use case for this scenario: When Flow Manager develop flow.xml.gz on 
> localhost/testing environments, usually deployment to production environment 
> is handled by jenkins/bamboo CI tools. These tools need to log in, upload new 
> flow.xml.gz and restart NiFi. All remotely using SSH.
> If somebody can advice me where in the source code is this line of code 
> located, I can prepare a pull request for this quick fix.
> But. Maybe we may want to go further and investigate what to do with IO 
> streams inside Java...



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

[jira] [Updated] (NIFI-2199) NiFi cannot be restarted through SSH (nifi.sh hangs)

2016-10-04 Thread Michal Klempa (JIRA)


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

Michal Klempa updated NIFI-2199:

Component/s: Core Framework

> NiFi cannot be restarted through SSH (nifi.sh hangs)
> 
>
> Key: NIFI-2199
> URL: https://issues.apache.org/jira/browse/NIFI-2199
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.5.1, 0.7.0, 0.6.1
>Reporter: Michal Klempa
>Priority: Minor
>  Labels: initscript
>
> When NiFi is to restarted using SSH from remote host, nifi.sh causes SSH to 
> hang on open io streams.
> Steps to reproduce:
> 1. HostA - NiFi instalation
> 2. HostB - client machine
> 3. log to HostB
> 4. issue a command
> {code}
> ssh root@HostA /etc/init.d/nifi restart
> {code}
> Expected behavior: NiFi is restarted, SSH command exits with 0
> Actual behavior: NiFi is restarted, SSH command hang on
> This seems to be somehow related to SSH handling IO streams of process. Seems 
> like detached NiFi java process does not close stdin/out/err (i do not know 
> precisely) leading to sshd waiting for some input/output to come to client.
> I was able to do a quick fix in nifi.sh as follows:
> 1. on existing nifi installation, in file /etc/init.d/nifi find the line
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ &)
> {code}
> its line number 214 (true branch of if [ "$1"] = "start"] condition).
> 2. replace it by line:
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ > /dev/null 2>&1 < /dev/null &)
> {code}
> This simply redirects stdin from /dev/null to NiFi java process and redirects 
> stdout/err to /dev/null letting SSH to close the session.
> After applying this fix, I am able to restart NiFi remotely using SSH.
> Use case for this scenario: When Flow Manager develop flow.xml.gz on 
> localhost/testing environments, usually deployment to production environment 
> is handled by jenkins/bamboo CI tools. These tools need to log in, upload new 
> flow.xml.gz and restart NiFi. All remotely using SSH.
> If somebody can advice me where in the source code is this line of code 
> located, I can prepare a pull request for this quick fix.
> But. Maybe we may want to go further and investigate what to do with IO 
> streams inside Java...



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

[GitHub] nifi issue #1092: Fixes NIFI-2199 nifi.sh hangs on restart through ssh

2016-10-04 Thread michalklempa

Github user michalklempa commented on the issue:

https://github.com/apache/nifi/pull/1092
  
Would be nice if anybody can help in getting clue on whats wrong with build.


---
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-2199) NiFi cannot be restarted through SSH (nifi.sh hangs)

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2199:
--

Github user michalklempa commented on the issue:

https://github.com/apache/nifi/pull/1092
  
Would be nice if anybody can help in getting clue on whats wrong with build.


> NiFi cannot be restarted through SSH (nifi.sh hangs)
> 
>
> Key: NIFI-2199
> URL: https://issues.apache.org/jira/browse/NIFI-2199
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 0.5.1, 0.6.1
>Reporter: Michal Klempa
>Priority: Minor
>  Labels: initscript
>
> When NiFi is to restarted using SSH from remote host, nifi.sh causes SSH to 
> hang on open io streams.
> Steps to reproduce:
> 1. HostA - NiFi instalation
> 2. HostB - client machine
> 3. log to HostB
> 4. issue a command
> {code}
> ssh root@HostA /etc/init.d/nifi restart
> {code}
> Expected behavior: NiFi is restarted, SSH command exits with 0
> Actual behavior: NiFi is restarted, SSH command hang on
> This seems to be somehow related to SSH handling IO streams of process. Seems 
> like detached NiFi java process does not close stdin/out/err (i do not know 
> precisely) leading to sshd waiting for some input/output to come to client.
> I was able to do a quick fix in nifi.sh as follows:
> 1. on existing nifi installation, in file /etc/init.d/nifi find the line
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ &)
> {code}
> its line number 214 (true branch of if [ "$1"] = "start"] condition).
> 2. replace it by line:
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ > /dev/null 2>&1 < /dev/null &)
> {code}
> This simply redirects stdin from /dev/null to NiFi java process and redirects 
> stdout/err to /dev/null letting SSH to close the session.
> After applying this fix, I am able to restart NiFi remotely using SSH.
> Use case for this scenario: When Flow Manager develop flow.xml.gz on 
> localhost/testing environments, usually deployment to production environment 
> is handled by jenkins/bamboo CI tools. These tools need to log in, upload new 
> flow.xml.gz and restart NiFi. All remotely using SSH.
> If somebody can advice me where in the source code is this line of code 
> located, I can prepare a pull request for this quick fix.
> But. Maybe we may want to go further and investigate what to do with IO 
> streams inside Java...



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

[jira] [Comment Edited] (NIFI-2448) Hive Processors depend on too recent a Hive version

2016-10-04 Thread Tomasz Domanski (JIRA)


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

Tomasz Domanski edited comment on NIFI-2448 at 10/4/16 11:37 AM:
-

[~mattyb149] What do you think? Is it resolved for you? 
I have 1.0 version and I'm still seeing the error as [~simonellistonball].


was (Author: tom_dom):
[~mattyb149] What do you think? Is it resolved for you? 
I have 1.0 version and I'm still seeing the error as you.

> Hive Processors depend on too recent a Hive version
> ---
>
> Key: NIFI-2448
> URL: https://issues.apache.org/jira/browse/NIFI-2448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Simon Elliston Ball
>Priority: Critical
>
> The new Hive bundle depends on version 2.0.0 of Hive. This means that it can 
> only connect to very recent Hive distributions. 
> Sadly very few people in the field have upgraded their Hive to the latest and 
> greatest, and as per https://issues.apache.org/jira/browse/HIVE-6050 the 
> issue of backward compatibility in the client is still not resolved.
> We should look at lowering the dependency version to allow connections with 
> older Hive distros.



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

[GitHub] nifi pull request #1092: Fixes NIFI-2199 nifi.sh hangs on restart through ss...

2016-10-04 Thread michalklempa

GitHub user michalklempa opened a pull request:

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

Fixes NIFI-2199 nifi.sh hangs on restart through ssh

When nifi.sh is executed remotely through ssh:
```
ssh r...@example.com /etc/init.d/nifi restart
```
SSH session hang forever, due to unclosed STDIN/OUT/ERR streams in nifi 
process. Redirecting these streams from and to `/dev/null` fixes the problem.


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

$ git pull https://github.com/michalklempa/nifi NIFI-2199_nifi_sh_hangs

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

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


commit 6488bdec2a429b735a02949694ff8876ae91d22e
Author: Michal Klempa 
Date:   2016-10-04T10:18:46Z

Fixes NIFI-2199 nifi.sh hangs on restart through ssh




---
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-2199) NiFi cannot be restarted through SSH (nifi.sh hangs)

2016-10-04 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on NIFI-2199:
--

GitHub user michalklempa opened a pull request:

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

Fixes NIFI-2199 nifi.sh hangs on restart through ssh

When nifi.sh is executed remotely through ssh:
```
ssh r...@example.com /etc/init.d/nifi restart
```
SSH session hang forever, due to unclosed STDIN/OUT/ERR streams in nifi 
process. Redirecting these streams from and to `/dev/null` fixes the problem.


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

$ git pull https://github.com/michalklempa/nifi NIFI-2199_nifi_sh_hangs

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

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


commit 6488bdec2a429b735a02949694ff8876ae91d22e
Author: Michal Klempa 
Date:   2016-10-04T10:18:46Z

Fixes NIFI-2199 nifi.sh hangs on restart through ssh




> NiFi cannot be restarted through SSH (nifi.sh hangs)
> 
>
> Key: NIFI-2199
> URL: https://issues.apache.org/jira/browse/NIFI-2199
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 0.5.1, 0.6.1
>Reporter: Michal Klempa
>Priority: Minor
>  Labels: initscript
>
> When NiFi is to restarted using SSH from remote host, nifi.sh causes SSH to 
> hang on open io streams.
> Steps to reproduce:
> 1. HostA - NiFi instalation
> 2. HostB - client machine
> 3. log to HostB
> 4. issue a command
> {code}
> ssh root@HostA /etc/init.d/nifi restart
> {code}
> Expected behavior: NiFi is restarted, SSH command exits with 0
> Actual behavior: NiFi is restarted, SSH command hang on
> This seems to be somehow related to SSH handling IO streams of process. Seems 
> like detached NiFi java process does not close stdin/out/err (i do not know 
> precisely) leading to sshd waiting for some input/output to come to client.
> I was able to do a quick fix in nifi.sh as follows:
> 1. on existing nifi installation, in file /etc/init.d/nifi find the line
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ &)
> {code}
> its line number 214 (true branch of if [ "$1"] = "start"] condition).
> 2. replace it by line:
> {code}
> (cd "${NIFI_HOME}" && ${sudo_cmd_prefix} "${JAVA}" -cp 
> "${BOOTSTRAP_CLASSPATH}" -Xms12m -Xmx24m 
> -Dorg.apache.nifi.bootstrap.config.file="${BOOTSTRAP_CONF}" 
> org.apache.nifi.bootstrap.RunNiFi $@ > /dev/null 2>&1 < /dev/null &)
> {code}
> This simply redirects stdin from /dev/null to NiFi java process and redirects 
> stdout/err to /dev/null letting SSH to close the session.
> After applying this fix, I am able to restart NiFi remotely using SSH.
> Use case for this scenario: When Flow Manager develop flow.xml.gz on 
> localhost/testing environments, usually deployment to production environment 
> is handled by jenkins/bamboo CI tools. These tools need to log in, upload new 
> flow.xml.gz and restart NiFi. All remotely using SSH.
> If somebody can advice me where in the source code is this line of code 
> located, I can prepare a pull request for this quick fix.
> But. Maybe we may want to go further and investigate what to do with IO 
> streams inside Java...



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

[jira] [Created] (NIFI-2859) List + Fetch HDFS processors are reading part files from HDFS

2016-10-04 Thread Mahesh Nayak (JIRA)

Mahesh Nayak created NIFI-2859:
--

 Summary: List + Fetch HDFS processors are reading part files from 
HDFS
 Key: NIFI-2859
 URL: https://issues.apache.org/jira/browse/NIFI-2859
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.0.0
Reporter: Mahesh Nayak


Create the following ProcessGroups
GetFile --> PutHdfs --> PutFile
ListHDFS --> FetchHdfs --> putFile
2. Now start both the processGroups
3. Write lots of files into HDFS so that ListHDFS keeps listing and FetchHdfs 
fetches.
4. An exception is thrown because the processor reads the part file from the 
putHdfs folder

{code:none}
java.io.FileNotFoundException: File does not exist: 
/tmp/HDFSProcessorsTest_visjJMcHORUwigw/.ycnVSpBOzEaoTWk_7f37d5af-d4a4-4521-b60d-c3c11ae19669
at 
org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:71)
at 
org.apache.hadoop.hdfs.server.namenode.INodeFile.valueOf(INodeFile.java:61)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocationsInt(FSNamesystem.java:1860)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1831)
at 
org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getBlockLocations(FSNamesystem.java:1744)
{code}
Note that eventually the file is copied to the output successfully, but at the 
same time there are some files in the failure/comms failure relationship



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

[jira] [Commented] (NIFI-2448) Hive Processors depend on too recent a Hive version

2016-10-04 Thread Tomasz Domanski (JIRA)


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

Tomasz Domanski commented on NIFI-2448:
---

[~mattyb149] What do you think? Is it resolved for you? 
I have 1.0 version and I'm still seeing the error as you.

> Hive Processors depend on too recent a Hive version
> ---
>
> Key: NIFI-2448
> URL: https://issues.apache.org/jira/browse/NIFI-2448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Simon Elliston Ball
>Priority: Critical
>
> The new Hive bundle depends on version 2.0.0 of Hive. This means that it can 
> only connect to very recent Hive distributions. 
> Sadly very few people in the field have upgraded their Hive to the latest and 
> greatest, and as per https://issues.apache.org/jira/browse/HIVE-6050 the 
> issue of backward compatibility in the client is still not resolved.
> We should look at lowering the dependency version to allow connections with 
> older Hive distros.



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

[jira] [Updated] (NIFI-2858) getSystemLoadAverage of OperatingSystemMXBean sometimes returns zero or a negative value.

2016-10-04 Thread Byunghwa Yun (JIRA)


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

Byunghwa Yun updated NIFI-2858:
---
Description: 
When NiFi cluster is busy, Sometimes Cluster of Global Menu throws below an 
exception.
So, I was tracking that exception to find a problem that getSystemLoadAverage 
of OperatingSystemMXBean sometimes returns zero or a negative value.

2016-10-04 14:53:20,488 ERROR [NiFi Web Server-40942] 
o.a.nifi.web.api.config.ThrowableMapper An unexpected error has occurred: 
java.lang.NullPointerException. Returning Internal Server Error response.
java.lang.NullPointerException: null
at 
org.apache.nifi.cluster.manager.StatusMerger.merge(StatusMerger.java:576) 
~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.manager.StatusMerger.merge(StatusMerger.java:548) 
~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.endpoints.SystemDiagnosticsEndpointMerger.mergeResponses(SystemDiagnosticsEndpointMerger.java:69)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.endpoints.SystemDiagnosticsEndpointMerger.mergeResponses(SystemDiagnosticsEndpointMerger.java:31)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.endpoints.AbstractNodeStatusEndpoint.mergeResponses(AbstractNodeStatusEndpoint.java:41)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.endpoints.AbstractSingleDTOEndpoint.merge(AbstractSingleDTOEndpoint.java:48)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.StandardHttpResponseMerger.mergeResponses(StandardHttpResponseMerger.java:179)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.replication.StandardAsyncClusterResponse.getMergedResponse(StandardAsyncClusterResponse.java:145)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.cluster.coordination.http.replication.StandardAsyncClusterResponse.awaitMergedResponse(StandardAsyncClusterResponse.java:160)
 ~[nifi-framework-cluster-1.1.0-SNAPSHOT.jar:1.1.0-SNAPSHOT]
at 
org.apache.nifi.web.api.SystemDiagnosticsResource.getSystemDiagnostics(SystemDiagnosticsResource.java:141)
 ~[classes/:na]
at sun.reflect.GeneratedMethodAccessor988.invoke(Unknown Source) 
~[na:na]
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 ~[na:1.8.0_51]
at java.lang.reflect.Method.invoke(Method.java:497) ~[na:1.8.0_51]
at 
com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)
 ~[jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1542)
 [jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1473)
 [jersey-server-1.19.jar:1.19]
at 
com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1419)
 [jersey-server-1.19.jar:1.19]


When systemLoad of SystemDiagnosticsFactory is zero or a negative value, it 
skips setting setProcessorLoadAverage of SystemDiagnostics.

if (systemLoad > 0) {
systemDiagnostics.setProcessorLoadAverage(systemLoad);
}

I think when getSystemLoadAverage returns a negative value, systemLoad sets 
-1.0 and returns zero, systemLoad sets zero.

Thank you.

  was:
When NiFi cluster is busy, Sometimes Cluster of Global Menu throws below an 
exception.
So, I was tracking that exception to find a problem that getSystemLoadAverage 
of OperatingSystemMXBean sometimes returns a negative value.

2016-10-04 14:53:20,488 ERROR [NiFi Web

1 2 >

1 - 100 of 111 matches

Mail list logo