[GitHub] nifi-minifi-cpp issue #13: MINIFI-109: Add ExecuteProcess

[randerzander]

Github user randerzander commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/13
  
@benqiu2016 @apiri saw that this got committed to master.

Unfortunately, I'm getting build errors that strcpy and strtok are not 
members of 'std'. Including some build environment info and the errors produced.

[root@d0a671fc9da1 nifi-minifi-cpp]# gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@d0a671fc9da1 nifi-minifi-cpp]# g++ --version
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[root@d0a671fc9da1 nifi-minifi-cpp]# yum install -y boost-devel 
libxml2-devel
Loaded plugins: fastestmirror, ovl
Loading mirror speeds from cached hostfile
 * base: mirrors.umflint.edu
 * extras: mirror.trouble-free.net
 * updates: mirrors.centos.webair.com
Package boost-devel-1.53.0-25.el7.x86_64 already installed and latest 
version
Package libxml2-devel-2.9.1-6.el7_2.3.x86_64 already installed and latest 
version
Nothing to do
[root@d0a671fc9da1 nifi-minifi-cpp]# make
mkdir -p ./build
mkdir -p ./target
make -C thirdparty/uuid
make[1]: Entering directory `/nifi-minifi-cpp/thirdparty/uuid'
gcc -g -Wall -rdynamic  -O0 -ggdb -g3 -fexceptions -Wno-write-strings 
-fvisibility=hidden -fPIC -I.. ./tst_uuid.c  libuuid.a -o ./tst_uuid
make[1]: Leaving directory `/nifi-minifi-cpp/thirdparty/uuid'
g++ -Os -fexceptions -fpermissive -Wno-write-strings -std=c++11 -fPIC -Wall 
-g -Wno-unused-private-field -I./inc -I./src -I./test -I./thirdparty 
-I/usr/include/libxml2 -I./thirdparty/yaml-cpp-yaml-cpp-0.5.3/include -o 
build/ExecuteProcess.o -c src/ExecuteProcess.cpp
src/ExecuteProcess.cpp: In member function 'virtual void 
ExecuteProcess::onTrigger(ProcessContext*, ProcessSession*)':
src/ExecuteProcess.cpp:101:2: error: 'strcpy' is not a member of 'std'
  std::strcpy(cstr, _fullCommand.c_str());
  ^
src/ExecuteProcess.cpp:101:2: note: suggested alternative:
In file included from ./inc/TimeUtil.h:25:0,
 from src/ExecuteProcess.cpp:20:
/usr/include/string.h:125:14: note:   'strcpy'
 extern char *strcpy (char *__restrict __dest, const char *__restrict __src)
  ^
src/ExecuteProcess.cpp:102:12: error: 'strtok' is not a member of 'std'
  char *p = std::strtok (cstr, " ");
^
src/ExecuteProcess.cpp:102:12: note: suggested alternative:
In file included from ./inc/TimeUtil.h:25:0,
 from src/ExecuteProcess.cpp:20:
/usr/include/string.h:344:14: note:   'strtok'
 extern char *strtok (char *__restrict __s, const char *__restrict __delim)
  ^
src/ExecuteProcess.cpp:108:7: error: 'strtok' is not a member of 'std'
   p = std::strtok(NULL, " ");
   ^
src/ExecuteProcess.cpp:108:7: note: suggested alternative:
In file included from ./inc/TimeUtil.h:25:0,
 from src/ExecuteProcess.cpp:20:
/usr/include/string.h:344:14: note:   'strtok'
 extern char *strtok (char *__restrict __s, const char *__restrict __delim)
  ^
src/ExecuteProcess.cpp:198:49: warning: comparison between signed and 
unsigned integer expressions [-Wsign-compare]
   if (numRead == (sizeof(buffer) - totalRead))
 ^


---
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-2731) MergeContent default max number of flow files and max number of bins should be smaller

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2731:
--

Github user mosermw commented on the issue:

https://github.com/apache/nifi/pull/1071
  
Yes @joewitt you've alleviated my concerns about the default for Max Bins.  
I forgot that default values get serialized to the flow.xml when a new 
processor is dropped on the graph.  Thanks.

I was on board with setting a default for Max Entries and not leaving that 
unbounded.  It certainly can cause trouble otherwise, and new users won't know 
why.


> MergeContent default max number of flow files and max number of bins should 
> be smaller
> --
>
> Key: NIFI-2731
> URL: https://issues.apache.org/jira/browse/NIFI-2731
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Witt
>Assignee: Pierre Villard
> Fix For: 1.1.0
>
>
> Presently there is no default on max entries.  It should probably be set to 
> 1000 by default.  These are flow files and their objects are read into memory 
> and can add up quickly.  Further, if we have 100 default max bins we could 
> end up with 100s of thousands of flow file objects held in memory during 
> common dataflow scenarios.  Recommend moving to max 5 different bins by 
> default and max 1000 flow files by default.



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

[GitHub] nifi issue #1071: NIFI-2731 MergeContent default max number of flow files an...

[mosermw]

Github user mosermw commented on the issue:

https://github.com/apache/nifi/pull/1071
  
Yes @joewitt you've alleviated my concerns about the default for Max Bins.  
I forgot that default values get serialized to the flow.xml when a new 
processor is dropped on the graph.  Thanks.

I was on board with setting a default for Max Entries and not leaving that 
unbounded.  It certainly can cause trouble otherwise, and new users won't know 
why.


---
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-2841) SplitAvro Processor is Broken

[Bryan Bende (JIRA)]

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

Bryan Bende commented on NIFI-2841:
---

[~dhicks82] Thanks for reporting this, do you think you could provide an 
example schema and data file that produces the problem?

I'm not sure it is happening on any and all Avro files because there a bunch of 
unit tests for the processor that all work without encountering this: 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-avro-bundle/nifi-avro-processors/src/test/java/org/apache/nifi/processors/avro/TestSplitAvro.java

I do believe there may be a problem though and would like to track it down.

> SplitAvro Processor is Broken
> -
>
> Key: NIFI-2841
> URL: https://issues.apache.org/jira/browse/NIFI-2841
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: David Hicks
>Priority: Critical
>
> This is largely the fault of the Avro DataFileStream reader, but it's making 
> the processor unusable.  The problem appears to occur when you make the 
> following series of calls (which happens because of the splitSize comparison):
> reader.next() -> returns last element
> reader.hasNext() -> returns false
> reader.hasNext() -> returns true
> reader.next() -> EOFException
> This should be reproducible with any and all avro files.
> org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
> SplitAvro[id=22e03ca4-0151-4474-92fc-040e1fe12ab9]: java.io.EOFException
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2013)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1.process(SplitAvro.java:250)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1851)
>  ~[na:na]
>   at 
> org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1822)
>  ~[na:na]
>   at 
> org.apache.nifi.processors.avro.SplitAvro$RecordSplitter.split(SplitAvro.java:236)
>  ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processors.avro.SplitAvro.onTrigger(SplitAvro.java:202) 
> ~[nifi-avro-processors-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  [nifi-api-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
>  [nifi-framework-core-0.7.0.jar:0.7.0]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_101]
>   at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_101]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_101]
>   at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
> Caused by: java.io.EOFException: null
>   at 
> org.apache.avro.io.BinaryDecoder.ensureBounds(BinaryDecoder.java:473) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:128) 
> ~[avro-1.7.7.jar:1.7.7]
>   at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:363)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:355)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:157) 
> ~[avro-1.7.7.jar:1.7.7]
>   at 
> org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:193)
>  ~[avro-1.7.7.jar:1.7.7]
>   at 
> 

[jira] [Created] (NIFI-2842) Would like InferAvroSchema and ConvertCSVToAvro to handle numbers better

[David Hicks (JIRA)]

David Hicks created NIFI-2842:
-

 Summary: Would like InferAvroSchema and ConvertCSVToAvro to handle 
numbers better
 Key: NIFI-2842
 URL: https://issues.apache.org/jira/browse/NIFI-2842
 Project: Apache NiFi
  Issue Type: New Feature
Reporter: David Hicks


Assume the following CSV:
field1,field2
10,17
7,18.4

InferAvroSchema will parse both as an integer field, but ConvertCSVtoAvro will 
explode when trying to convert the second line, because it's a float.  One 
recommendation would be to allow the user to specify multiple lines and choose 
the least restrictive one.  If it parses a field as an integer and then a 
double, the double will override the integer.



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

[jira] [Updated] (NIFI-2826) GetEventHubProcessor Support Enqueue Time

[Joseph Niemiec (JIRA)]

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

Joseph Niemiec updated NIFI-2826:
-
Attachment: 0003-NIFI-2826-Adding-enqueue-time-to-GetAzureEventHub-pr.patch
0002-NIFI-2826-converted-from-epoch-to-iso8061-enqueue-in.patch

> GetEventHubProcessor Support Enqueue Time
> -
>
> Key: NIFI-2826
> URL: https://issues.apache.org/jira/browse/NIFI-2826
> Project: Apache NiFi
>  Issue Type: Improvement
> Environment: centos6, jdk1.8, nifi 1.0.0
>Reporter: Joseph Niemiec
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-NIFI-2826-Adding-enqueue-time-to-GetAzureEventHub-pr.patch, 
> 0002-NIFI-2826-converted-from-epoch-to-iso8061-enqueue-in.patch, 
> 0003-NIFI-2826-Adding-enqueue-time-to-GetAzureEventHub-pr.patch, patch.1
>
>
> The current GetEventHubProcessor should support allowing an enqueue time like 
> eventhubs to read messages from the past. This would also support reading 
> messages missed during downtime. Today the behaviour is for the processor to 
> start at the enqueue of when it was started by the user missing any past 
> messages. 



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

[jira] [Created] (NIFI-2841) SplitAvro Processor is Broken

[David Hicks (JIRA)]

David Hicks created NIFI-2841:
-

 Summary: SplitAvro Processor is Broken
 Key: NIFI-2841
 URL: https://issues.apache.org/jira/browse/NIFI-2841
 Project: Apache NiFi
  Issue Type: Bug
Reporter: David Hicks
Priority: Critical


This is largely the fault of the Avro DataFileStream reader, but it's making 
the processor unusable.  The problem appears to occur when you make the 
following series of calls (which happens because of the splitSize comparison):
reader.next() -> returns last element
reader.hasNext() -> returns false
reader.hasNext() -> returns true
reader.next() -> EOFException

This should be reproducible with any and all avro files.

org.apache.nifi.processor.exception.ProcessException: IOException thrown from 
SplitAvro[id=22e03ca4-0151-4474-92fc-040e1fe12ab9]: java.io.EOFException
at 
org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:2013)
 ~[na:na]
at 
org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1.process(SplitAvro.java:250)
 ~[nifi-avro-processors-0.7.0.jar:0.7.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1851)
 ~[na:na]
at 
org.apache.nifi.controller.repository.StandardProcessSession.read(StandardProcessSession.java:1822)
 ~[na:na]
at 
org.apache.nifi.processors.avro.SplitAvro$RecordSplitter.split(SplitAvro.java:236)
 ~[nifi-avro-processors-0.7.0.jar:0.7.0]
at 
org.apache.nifi.processors.avro.SplitAvro.onTrigger(SplitAvro.java:202) 
~[nifi-avro-processors-0.7.0.jar:0.7.0]
at 
org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
 [nifi-api-0.7.0.jar:0.7.0]
at 
org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1054)
 [nifi-framework-core-0.7.0.jar:0.7.0]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
 [nifi-framework-core-0.7.0.jar:0.7.0]
at 
org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
 [nifi-framework-core-0.7.0.jar:0.7.0]
at 
org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:127)
 [nifi-framework-core-0.7.0.jar:0.7.0]
at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
[na:1.8.0_101]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
[na:1.8.0_101]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
 [na:1.8.0_101]
at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
 [na:1.8.0_101]
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
[na:1.8.0_101]
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
[na:1.8.0_101]
at java.lang.Thread.run(Thread.java:745) [na:1.8.0_101]
Caused by: java.io.EOFException: null
at 
org.apache.avro.io.BinaryDecoder.ensureBounds(BinaryDecoder.java:473) 
~[avro-1.7.7.jar:1.7.7]
at org.apache.avro.io.BinaryDecoder.readInt(BinaryDecoder.java:128) 
~[avro-1.7.7.jar:1.7.7]
at org.apache.avro.io.BinaryDecoder.readString(BinaryDecoder.java:259) 
~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.io.ResolvingDecoder.readString(ResolvingDecoder.java:201) 
~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:363)
 ~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.readString(GenericDatumReader.java:355)
 ~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:157) 
~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.readField(GenericDatumReader.java:193)
 ~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.readRecord(GenericDatumReader.java:183)
 ~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:151) 
~[avro-1.7.7.jar:1.7.7]
at 
org.apache.avro.generic.GenericDatumReader.read(GenericDatumReader.java:142) 
~[avro-1.7.7.jar:1.7.7]
at org.apache.avro.file.DataFileStream.next(DataFileStream.java:233) 
~[avro-1.7.7.jar:1.7.7]
at 
org.apache.nifi.processors.avro.SplitAvro$RecordSplitter$1$1.process(SplitAvro.java:259)
 ~[nifi-avro-processors-0.7.0.jar:0.7.0]
at 
org.apache.nifi.controller.repository.StandardProcessSession.write(StandardProcessSession.java:1998)
 ~[na:na]
... 17 common frames omitted




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

[jira] [Updated] (NIFI-766) UI should indicate when backpressure is configured for a Connection

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-766:

Fix Version/s: 1.1.0
   Status: Patch Available  (was: Open)

> UI should indicate when backpressure is configured for a Connection
> ---
>
> Key: NIFI-766
> URL: https://issues.apache.org/jira/browse/NIFI-766
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework, Core UI
>Reporter: Mark Payne
>Assignee: Pierre Villard
> Fix For: 1.1.0
>
> Attachments: backpressure.png, backpressure_and_expiration.png, 
> normal.png
>
>
> It is sometimes unclear why a Processor is not running, if it is due to 
> backpressure. Recommend we add an icon to the Connection label to indicate 
> that backpressure is configured. If backpressure is "applied" (i.e., the 
> backpressure threshold has been reached), that icon should be highlighted 
> somehow.



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

[jira] [Updated] (NIFI-766) UI should indicate when backpressure is configured for a Connection

[Pierre Villard (JIRA)]

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

Pierre Villard updated NIFI-766:

Attachment: normal.png
backpressure_and_expiration.png
backpressure.png

Screenshots with submitted PR.

> UI should indicate when backpressure is configured for a Connection
> ---
>
> Key: NIFI-766
> URL: https://issues.apache.org/jira/browse/NIFI-766
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework, Core UI
>Reporter: Mark Payne
> Attachments: backpressure.png, backpressure_and_expiration.png, 
> normal.png
>
>
> It is sometimes unclear why a Processor is not running, if it is due to 
> backpressure. Recommend we add an icon to the Connection label to indicate 
> that backpressure is configured. If backpressure is "applied" (i.e., the 
> backpressure threshold has been reached), that icon should be highlighted 
> somehow.



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

[jira] [Commented] (NIFI-766) UI should indicate when backpressure is configured for a Connection

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-766:
-

GitHub user pvillard31 opened a pull request:

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

NIFI-766 Added icon on connection when backpressure is enabled

Here is a proposition to display an icon on a connection when back pressure 
is enabled.

At the moment, there is no icon displayed whether back pressure is 
configured or not. (I am not sure it is worth adding information that is not 
that important to users: back pressure is configured by default)

First time I take a shot at UI dev, please review with care ;)

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

$ git pull https://github.com/pvillard31/nifi backpressure

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

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


commit 529492fa84013e877adf300826a85d6be5e9f5d0
Author: Pierre Villard 
Date:   2016-09-28T21:39:09Z

Added icon on connection when backpressure is enabled




> UI should indicate when backpressure is configured for a Connection
> ---
>
> Key: NIFI-766
> URL: https://issues.apache.org/jira/browse/NIFI-766
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework, Core UI
>Reporter: Mark Payne
>
> It is sometimes unclear why a Processor is not running, if it is due to 
> backpressure. Recommend we add an icon to the Connection label to indicate 
> that backpressure is configured. If backpressure is "applied" (i.e., the 
> backpressure threshold has been reached), that icon should be highlighted 
> somehow.



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

[GitHub] nifi pull request #1080: NIFI-766 Added icon on connection when backpressure...

[pvillard31]

GitHub user pvillard31 opened a pull request:

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

NIFI-766 Added icon on connection when backpressure is enabled

Here is a proposition to display an icon on a connection when back pressure 
is enabled.

At the moment, there is no icon displayed whether back pressure is 
configured or not. (I am not sure it is worth adding information that is not 
that important to users: back pressure is configured by default)

First time I take a shot at UI dev, please review with care ;)

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

$ git pull https://github.com/pvillard31/nifi backpressure

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

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


commit 529492fa84013e877adf300826a85d6be5e9f5d0
Author: Pierre Villard 
Date:   2016-09-28T21:39:09Z

Added icon on connection when backpressure is enabled




---
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-1851) NiFi summary filter displays wrong number of total results for Process Groups after refresh

[Scott Aslan (JIRA)]

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

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

> NiFi summary filter displays wrong number of total results for Process Groups 
> after refresh
> ---
>
> Key: NIFI-1851
> URL: https://issues.apache.org/jira/browse/NIFI-1851
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1851_zeroResultsProcessGroup.png
>
>
> Pre-conditions:
> Flow that has multiple process groups
> Steps to Reproduce:
> 1. Go to NiFi Summary Page
> 2. Select Process Groups tab
> 3. Note the numbers displayed next to the Filter ie. Displaying 5 of 5
> 4. Select the "Refresh" icon next to the Process Groups tab
> 5.  The numbers displayed will now be "Displaying x of 0"   (see attached 
> screenshot)



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

[jira] [Commented] (NIFI-1851) NiFi summary filter displays wrong number of total results for Process Groups after refresh

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1851:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-1851] correctly display number of total process groups upon ref…

…resh

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

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

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

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


commit 0264646353d544f44d8f920317923c6dfaf53930
Author: Scott Aslan 
Date:   2016-09-28T20:47:35Z

[NIFI-1851] correctly display number of total process groups upon refresh




> NiFi summary filter displays wrong number of total results for Process Groups 
> after refresh
> ---
>
> Key: NIFI-1851
> URL: https://issues.apache.org/jira/browse/NIFI-1851
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1851_zeroResultsProcessGroup.png
>
>
> Pre-conditions:
> Flow that has multiple process groups
> Steps to Reproduce:
> 1. Go to NiFi Summary Page
> 2. Select Process Groups tab
> 3. Note the numbers displayed next to the Filter ie. Displaying 5 of 5
> 4. Select the "Refresh" icon next to the Process Groups tab
> 5.  The numbers displayed will now be "Displaying x of 0"   (see attached 
> screenshot)



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

[jira] [Created] (NIFI-2840) Not clear how templates are ordered when adding to canvas

[Andrew Lim (JIRA)]

Andrew Lim created NIFI-2840:


 Summary: Not clear how templates are ordered when adding to canvas
 Key: NIFI-2840
 URL: https://issues.apache.org/jira/browse/NIFI-2840
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Affects Versions: 1.0.0
Reporter: Andrew Lim
Priority: Minor


As shown in the attached screenshot, the ordering of the templates is not 
alphabetical.  It is also not ordered by time of import.

If there is an ordering being applied, it should be made more 
transparent/obvious to the user.

My personal preference is for the ordering to be done by last imported.  So the 
top-most available selection is the most recently imported template, which 
would seem logical.  I'm assuming if a user has imported a template, he/she 
would like to then immediately add it to the flow.



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

[jira] [Assigned] (NIFI-2793) Add documentation for primary node only scheduling strategy

[Sarah Olson (JIRA)]

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

Sarah Olson reassigned NIFI-2793:
-

Assignee: Sarah Olson

> Add documentation for primary node only scheduling strategy
> ---
>
> Key: NIFI-2793
> URL: https://issues.apache.org/jira/browse/NIFI-2793
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Documentation & Website
>Reporter: Arpit Gupta
>Assignee: Sarah Olson
>Priority: Minor
> Fix For: 1.1.0
>
>
> https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#scheduling-tab 
> does not cover the primary node only option. This option is only available 
> when user is running in clustered mode.



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

[jira] [Assigned] (NIFI-1851) NiFi summary filter displays wrong number of total results for Process Groups after refresh

[Scott Aslan (JIRA)]

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

Scott Aslan reassigned NIFI-1851:
-

Assignee: Scott Aslan

> NiFi summary filter displays wrong number of total results for Process Groups 
> after refresh
> ---
>
> Key: NIFI-1851
> URL: https://issues.apache.org/jira/browse/NIFI-1851
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.6.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1851_zeroResultsProcessGroup.png
>
>
> Pre-conditions:
> Flow that has multiple process groups
> Steps to Reproduce:
> 1. Go to NiFi Summary Page
> 2. Select Process Groups tab
> 3. Note the numbers displayed next to the Filter ie. Displaying 5 of 5
> 4. Select the "Refresh" icon next to the Process Groups tab
> 5.  The numbers displayed will now be "Displaying x of 0"   (see attached 
> screenshot)



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

[jira] [Resolved] (NIFI-1852) NiFi Summary: Process Group results are not being filtered when filtering “by name"

[Andrew Lim (JIRA)]

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

Andrew Lim resolved NIFI-1852.
--
Resolution: Cannot Reproduce

Closing.  Not reproducible in 1.0.0.

> NiFi Summary: Process Group results are not being filtered when filtering “by 
> name"
> ---
>
> Key: NIFI-1852
> URL: https://issues.apache.org/jira/browse/NIFI-1852
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1852_filterProcessGroups.png
>
>
> In the NiFi summary window, when the user tries to filter Process Group 
> results "by name", the displayed results are not filtered at all (see 
> attached screenshot).



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

[jira] [Commented] (NIFI-2833) Increase font-size and line-height for message text in small dialogs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2833:
--

Github user mcgilman commented on the issue:

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


> Increase font-size and line-height for message text in small dialogs
> 
>
> Key: NIFI-2833
> URL: https://issues.apache.org/jira/browse/NIFI-2833
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Rob Moran
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: current.png, proposed.png
>
>
> In small dialogs where error and various messages are communicated to the 
> user, the text is quite small. I'd recommend increasing the size and line 
> spacing to:
> font-size: 13px;
> line-height: 1.3;
> See attached screenshots for a current example and the proposed change.



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

[jira] [Commented] (NIFI-2831) "Auto-terminate" should be used consistently in Settings tab

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2831:
--

Github user mcgilman commented on the issue:

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


> "Auto-terminate" should be used consistently in Settings tab
> 
>
> Key: NIFI-2831
> URL: https://issues.apache.org/jira/browse/NIFI-2831
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Trivial
> Attachments: 0.7.0_auto-Terminate.png, 1.0.0_autoTerminate.png
>
>
> As shown in the attached screenshots of the Settings tab (0.7.0 and 1.0.0) 
> when configuring a processor:
> *The text "Auto terminate relationships" is displayed. This should be changed 
> to "Auto-terminate relationships"
> *In the Configuration error, should change "Cannot Auto-Terminate" to 
> "Cannot Auto-terminate"
> These changes would make references to auto-terminate functionality 
> consistent in the application and with the documentation 
> (https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#settings-tab).



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

[GitHub] nifi issue #1077: [NIFI-2831] update auto terminate messages

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1077
  
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 issue #1078: [NIFI-2833] Increase font size and line height for small d...

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1078
  
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] [Created] (NIFI-2839) Add a confirmation dialog when deleting a Controller Service

[Andrew Lim (JIRA)]

Andrew Lim created NIFI-2839:


 Summary: Add a confirmation dialog when deleting a Controller 
Service
 Key: NIFI-2839
 URL: https://issues.apache.org/jira/browse/NIFI-2839
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Affects Versions: 1.0.0
Reporter: Andrew Lim
Priority: Minor


As soon as the user selects a Controller Service for deletion it is immediately 
deleted.  There should be a warning/confirmation dialog to make sure this is 
the user's intended selection/action.

This is especially needed because it is possible in the UI to create Controller 
Services with the same name, so it can be ambiguous which one is being selected 
for deletion.



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

[jira] [Updated] (NIFI-1798) Rules window can be closed with unsaved work

[Andrew Lim (JIRA)]

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

Andrew Lim updated NIFI-1798:
-
Affects Version/s: 1.0.0

> Rules window can be closed with unsaved work
> 
>
> Key: NIFI-1798
> URL: https://issues.apache.org/jira/browse/NIFI-1798
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.6.0
>Reporter: Andrew Lim
>Priority: Minor
> Attachments: NIFI-1798_saveWarning.png
>
>
> When entering the Advanced UI on the Properties tab when configuring an 
> Update Attribute processor, the user can create a rule and add all the 
> necessary conditions and actions.  However, after selecting the "x" in the 
> top right, the window closes with no warning.   A pop-up window should open 
> with a warning "Rule '' has unsaved changes.  Do you want to save?"
> This pop-up window is displayed if you create a rule and then try to create 
> another rule as described in the "Additional details" docs for the 
> UpdateAttribute processor (see attached screenshot):
> "Upon adding a rule with its condition(s) and action(s), it is important to 
> save it by clicking the Save button in the lower right corner. If you do not 
> do so and attempt to add or navigate to another rule, an error message will 
> appear, asking you if you want to save your changes."



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

[jira] [Commented] (NIFI-1852) NiFi Summary: Process Group results are not being filtered when filtering “by name"

[Scott Aslan (JIRA)]

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

Scott Aslan commented on NIFI-1852:
---

[~andrewmlim] I believe we can close this as I was not able to reproduce this 
bug. Please check it out and let me know.

> NiFi Summary: Process Group results are not being filtered when filtering “by 
> name"
> ---
>
> Key: NIFI-1852
> URL: https://issues.apache.org/jira/browse/NIFI-1852
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: NIFI-1852_filterProcessGroups.png
>
>
> In the NiFi summary window, when the user tries to filter Process Group 
> results "by name", the displayed results are not filtered at all (see 
> attached screenshot).



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

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

[Andrew Lim (JIRA)]

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

Andrew Lim updated NIFI-1792:
-
Affects Version/s: 1.0.0

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

[Andrew Lim (JIRA)]

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

Andrew Lim commented on NIFI-1792:
--

Still occurs in 1.0.0.

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

[Andrew Lim (JIRA)]

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

Andrew Lim commented on NIFI-1794:
--

Will check this in 1.0.0, once NIFI-2838 is resolved.

> 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
>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] [Created] (NIFI-2838) In the Advanced UI, if the Rule name is very long, the "x" to delete the rule becomes unavailable

[Andrew Lim (JIRA)]

Andrew Lim created NIFI-2838:


 Summary: In the Advanced UI, if the Rule name is very long, the 
"x" to delete the rule becomes unavailable
 Key: NIFI-2838
 URL: https://issues.apache.org/jira/browse/NIFI-2838
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core UI
Affects Versions: 1.0.0
Reporter: Andrew Lim


As shown in the attached screenshot, when the rule name is very long it extends 
the whole width of the bar, so the "x" to delete the rule is not longer 
selectable.

Note: There is also a scroll bar that appears in this part of the UI, which I 
thought would possibly reveal the "x", but the scroll bar has no functionality. 
 The width of the rule name bar doesn't extend the width of the space.



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

[jira] [Updated] (NIFI-2838) In the Advanced UI, if the Rule name is very long, the "x" to delete the rule becomes unavailable

[Andrew Lim (JIRA)]

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

Andrew Lim updated NIFI-2838:
-
Description: 
As shown in the attached screenshot, when the rule name is very long it extends 
the whole width of the bar, so the "x" to delete the rule is no longer 
selectable.

Note: There is also a scroll bar that appears in this part of the UI, which I 
thought would possibly reveal the "x", but the scroll bar has no functionality. 
 The width of the rule name bar doesn't extend the width of the space.

  was:
As shown in the attached screenshot, when the rule name is very long it extends 
the whole width of the bar, so the "x" to delete the rule is not longer 
selectable.

Note: There is also a scroll bar that appears in this part of the UI, which I 
thought would possibly reveal the "x", but the scroll bar has no functionality. 
 The width of the rule name bar doesn't extend the width of the space.


> In the Advanced UI, if the Rule name is very long, the "x" to delete the rule 
> becomes unavailable
> -
>
> Key: NIFI-2838
> URL: https://issues.apache.org/jira/browse/NIFI-2838
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>  Labels: UI
>
> As shown in the attached screenshot, when the rule name is very long it 
> extends the whole width of the bar, so the "x" to delete the rule is no 
> longer selectable.
> Note: There is also a scroll bar that appears in this part of the UI, which I 
> thought would possibly reveal the "x", but the scroll bar has no 
> functionality.  The width of the rule name bar doesn't extend the width of 
> the space.



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

[jira] [Created] (NIFI-2837) UI - Template upload

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2837:
-

 Summary: UI - Template upload
 Key: NIFI-2837
 URL: https://issues.apache.org/jira/browse/NIFI-2837
 Project: Apache NiFi
  Issue Type: Sub-task
  Components: Core UI
Reporter: Matt Gilman
Assignee: Matt Gilman
 Fix For: 1.1.0


When uploading a template, the form submit button should be removed once 
clicked to prevent accidental re-submission.



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

[jira] [Updated] (NIFI-2830) Template UUIDs out of sync in cluster

[Matt Gilman (JIRA)]

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

Matt Gilman updated NIFI-2830:
--
Fix Version/s: 1.1.0

> Template UUIDs out of sync in cluster
> -
>
> Key: NIFI-2830
> URL: https://issues.apache.org/jira/browse/NIFI-2830
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Aldrin Piri
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> I uploaded a template to a clustered instance of NiFi which presented me with 
> a success dialog.  This, and subsequent actions, were performed through a 
> node, nifi1.  Upon trying to add this template to the canvas, I received a 
> message that
> {code}
> Node nifi2:8443 is unable to fulfill this request due to: Unable to locate 
> template with id '76c907b3-2664-30e4-987b-e9021ebcc844'.
> {code}
> Upon performing an inspection on several of the nodes in the cluster, I saw 
> that all but nifi2 had the above listed UUID, but nifi2 had a different UUID. 
>  Upon trying to delete the template, I was presented with the same error.  
> This behavior, inclusive of the error message was the same when performing 
> the same actions on nifi2.
> Re-uploading the template with a different name, everything worked as 
> anticipated.
> There was nothing of note in nifi-app or nifi-user logs beyond the 
> information provided in the error dialog.  Of possible note is that the node 
> in question was possibly having some intermittent network issues but was 
> listed as continuously connected on the node I was accessing.



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

[jira] [Created] (NIFI-2836) Cluster - Request Replication

[Matt Gilman (JIRA)]

Matt Gilman created NIFI-2836:
-

 Summary: Cluster - Request Replication
 Key: NIFI-2836
 URL: https://issues.apache.org/jira/browse/NIFI-2836
 Project: Apache NiFi
  Issue Type: Sub-task
  Components: Core Framework
Reporter: Matt Gilman
Priority: Critical
 Fix For: 1.1.0


When a request is replicated throughout the cluster, the cluster coordinator 
needs to ensure that request completes (including both parts of the two-phase 
commit if applicable) prior to replicating the next request.

Looks like a write lock is obtained while submitted a background task. The 
actually work completes outside the locks scope.



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

[jira] [Resolved] (NIFI-2329) User authorization: Able to create a user with the same name which causes that user to lose User & Policies privileges

[Andrew Lim (JIRA)]

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

Andrew Lim resolved NIFI-2329.
--
Resolution: Cannot Reproduce

Cannot reproduce any more in 1.0.0.  Get an error message now when you try to 
create a user with the same name/identity.

> User authorization:  Able to create a user with the same name which causes 
> that user to lose User & Policies privileges
> ---
>
> Key: NIFI-2329
> URL: https://issues.apache.org/jira/browse/NIFI-2329
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>Priority: Critical
>
> I had an initial admin user who had default privs to access and modify Users 
> & Policies.  The UI allowed me to create another user with the same name.   
> After that, the user could no longer access Users (get the error "Unable to 
> perform the desired action due to insufficient permissions. Contact the 
> system administrator.") and can get into the Policies window, but can no 
> longer make changes and see the message "Not authorized to access the policy 
> for the specified resource."



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

[jira] [Commented] (NIFI-2690) Label color is incorrect after template import

[Andrew Lim (JIRA)]

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

Andrew Lim commented on NIFI-2690:
--

Thanks [~scottyaslan].  Makes sense!

> Label color is incorrect after template import
> --
>
> Key: NIFI-2690
> URL: https://issues.apache.org/jira/browse/NIFI-2690
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: WebCrawler.xml
>
>
> Steps to reproduce:
> 1. Import the template WebCrawler.xml (attached)
> 2. Add this template to the canvas
> 3. The label "This is configured to use yahoo mail.  You will need to change 
> it for your email server and address." should have the color #ffde93, but is 
> #fff7d7 instead.
> This is a regression/change from 0.7.0.



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

[jira] [Updated] (NIFI-2758) Prevent moving Processor whose Controller Service reference to move out of scope

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFI-2758:
---
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> Prevent moving Processor whose Controller Service reference to move out of 
> scope
> 
>
> Key: NIFI-2758
> URL: https://issues.apache.org/jira/browse/NIFI-2758
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> In Apache NiFi 1.0.0, Controller Services became scoped by Process Group. We 
> need to add in a check to ensure that a Processor isn't moved out of a 
> Process Group resulting in a Controller Service that is out of scope.



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

[jira] [Updated] (NIFI-2758) Prevent moving Processor whose Controller Service reference to move out of scope

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFI-2758:
---
Affects Version/s: 1.0.0

> Prevent moving Processor whose Controller Service reference to move out of 
> scope
> 
>
> Key: NIFI-2758
> URL: https://issues.apache.org/jira/browse/NIFI-2758
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> In Apache NiFi 1.0.0, Controller Services became scoped by Process Group. We 
> need to add in a check to ensure that a Processor isn't moved out of a 
> Process Group resulting in a Controller Service that is out of scope.



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

[jira] [Commented] (NIFI-2758) Prevent moving Processor whose Controller Service reference to move out of scope

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2758:
--

Github user asfgit closed the pull request at:

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


> Prevent moving Processor whose Controller Service reference to move out of 
> scope
> 
>
> Key: NIFI-2758
> URL: https://issues.apache.org/jira/browse/NIFI-2758
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> In Apache NiFi 1.0.0, Controller Services became scoped by Process Group. We 
> need to add in a check to ensure that a Processor isn't moved out of a 
> Process Group resulting in a Controller Service that is out of scope.



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

[GitHub] nifi pull request #1064: Verifying Controller Service cannot move out of sco...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2758) Prevent moving Processor whose Controller Service reference to move out of scope

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-2758:
---

Commit 833ec4409c20c5f2323b61b87bab7c10557f7041 in nifi's branch 
refs/heads/master from [~mcgilman]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=833ec44 ]

NIFI-2758: - Updating move verification to account for Controller Service 
moving out of scope.

This closes #1064

Signed-off-by: jpercivall 


> Prevent moving Processor whose Controller Service reference to move out of 
> scope
> 
>
> Key: NIFI-2758
> URL: https://issues.apache.org/jira/browse/NIFI-2758
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
> Fix For: 1.1.0
>
>
> In Apache NiFi 1.0.0, Controller Services became scoped by Process Group. We 
> need to add in a check to ensure that a Processor isn't moved out of a 
> Process Group resulting in a Controller Service that is out of scope.



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

[GitHub] nifi issue #1064: Verifying Controller Service cannot move out of scope

[JPercivall]

Github user JPercivall commented on the issue:

https://github.com/apache/nifi/pull/1064
  
+1

Visually verified code and did a contrib check build. In a standalone 
instance configured tried all combinations of configured CS (configured, not, 
invalid ID and no CS) moving up and down multiple process groups. All worked as 
expected, Thanks @mcgilman. I will merge it in.


---
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-2833) Increase font-size and line-height for message text in small dialogs

[Scott Aslan (JIRA)]

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

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

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

> Increase font-size and line-height for message text in small dialogs
> 
>
> Key: NIFI-2833
> URL: https://issues.apache.org/jira/browse/NIFI-2833
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Rob Moran
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: current.png, proposed.png
>
>
> In small dialogs where error and various messages are communicated to the 
> user, the text is quite small. I'd recommend increasing the size and line 
> spacing to:
> font-size: 13px;
> line-height: 1.3;
> See attached screenshots for a current example and the proposed change.



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

[jira] [Commented] (NIFI-2833) Increase font-size and line-height for message text in small dialogs

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2833:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-2833] Increase font size and line height for small dialogs



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

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

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

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


commit 6069c7e824b9af7acd4f4e040fd27a2c11d73263
Author: Scott Aslan 
Date:   2016-09-28T18:51:48Z

[NIFI-2833] Increase font size and line height for small dialogs




> Increase font-size and line-height for message text in small dialogs
> 
>
> Key: NIFI-2833
> URL: https://issues.apache.org/jira/browse/NIFI-2833
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Rob Moran
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: current.png, proposed.png
>
>
> In small dialogs where error and various messages are communicated to the 
> user, the text is quite small. I'd recommend increasing the size and line 
> spacing to:
> font-size: 13px;
> line-height: 1.3;
> See attached screenshots for a current example and the proposed change.



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

[GitHub] nifi pull request #1078: [NIFI-2833] Increase font size and line height for ...

[scottyaslan]

GitHub user scottyaslan opened a pull request:

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

[NIFI-2833] Increase font size and line height for small dialogs



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

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

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

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


commit 6069c7e824b9af7acd4f4e040fd27a2c11d73263
Author: Scott Aslan 
Date:   2016-09-28T18:51:48Z

[NIFI-2833] Increase font size and line height for small dialogs




---
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-2763) S3 processors do not work with older S3-compatible object stores

[James Wing (JIRA)]

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

James Wing updated NIFI-2763:
-
Resolution: Fixed
Status: Resolved  (was: Patch Available)

> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>Assignee: James Wing
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[jira] [Commented] (NIFI-2763) S3 processors do not work with older S3-compatible object stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2763:
--

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1076
  
Thanks, @baank.  The updates look good, I like the drop-down solution.


> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[jira] [Assigned] (NIFI-2763) S3 processors do not work with older S3-compatible object stores

[James Wing (JIRA)]

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

James Wing reassigned NIFI-2763:


Assignee: James Wing

> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>Assignee: James Wing
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[GitHub] nifi issue #1076: NIFI-2763: S3 processors do not work with older S3-compati...

[jvwing]

Github user jvwing commented on the issue:

https://github.com/apache/nifi/pull/1076
  
Thanks, @baank.  The updates look good, I like the drop-down solution.


---
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 #1076: NIFI-2763: S3 processors do not work with older S3-...

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2834) GetAzureEventHub should be more configurable

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFI-2834:
---
Description: 
Current GetAzureEventHub processor is configured to always grab a max batch of 
100 events per ontrigger[1]. This internal batching scheme should be made 
configurable.

Also there is an internal default timeout set for PartitionReceivers of 60 
seconds. This means each time the processor is triggered it will be blocked 
waiting for there to be the max number of events (currently 100) before 
canceling 60s later if there isn't 100 events. This should be configurable.

[1] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L215

  was:
Current GetAzureEventHub processor is configured to always grab a max batch of 
100 events per ontrigger[1]. This internal batching scheme should be made 
configurable.

[1] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L215


> GetAzureEventHub should be more configurable
> 
>
> Key: NIFI-2834
> URL: https://issues.apache.org/jira/browse/NIFI-2834
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
>
> Current GetAzureEventHub processor is configured to always grab a max batch 
> of 100 events per ontrigger[1]. This internal batching scheme should be made 
> configurable.
> Also there is an internal default timeout set for PartitionReceivers of 60 
> seconds. This means each time the processor is triggered it will be blocked 
> waiting for there to be the max number of events (currently 100) before 
> canceling 60s later if there isn't 100 events. This should be configurable.
> [1] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L215



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

[jira] [Updated] (NIFI-2834) GetAzureEventHub should be more configurable

[Joseph Percivall (JIRA)]

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

Joseph Percivall updated NIFI-2834:
---
Summary: GetAzureEventHub should be more configurable  (was: 
GetAzureEventHub should make "max events to receive per ontrigger" configurable)

> GetAzureEventHub should be more configurable
> 
>
> Key: NIFI-2834
> URL: https://issues.apache.org/jira/browse/NIFI-2834
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
>
> Current GetAzureEventHub processor is configured to always grab a max batch 
> of 100 events per ontrigger[1]. This internal batching scheme should be made 
> configurable.
> [1] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L215



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

[jira] [Assigned] (NIFI-2834) GetAzureEventHub should make "max events to receive per ontrigger" configurable

[Joseph Niemiec (JIRA)]

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

Joseph Niemiec reassigned NIFI-2834:


Assignee: Joseph Niemiec

> GetAzureEventHub should make "max events to receive per ontrigger" 
> configurable
> ---
>
> Key: NIFI-2834
> URL: https://issues.apache.org/jira/browse/NIFI-2834
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
>
> Current GetAzureEventHub processor is configured to always grab a max batch 
> of 100 events per ontrigger[1]. This internal batching scheme should be made 
> configurable.
> [1] 
> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L215



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

[jira] [Commented] (NIFI-2568) Add Kerberos Support to Solr Processors

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-2568:
---

Commit d4948a377802ecc07f196370eefe92195d8a773f in nifi's branch 
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d4948a3 ]

NIFI-1768 Adding TLS/SSL support to Solr processors NIFI-1980 Added a default 
value for PutSolrContentStream commitWithIn NIFI-2568 Added Kerberos support to 
Solr processors

Upgrading SolrJ to 6.2.

Signed-off-by: Yolanda M. Davis 

This closes #1005


> Add Kerberos Support to Solr Processors
> ---
>
> Key: NIFI-2568
> URL: https://issues.apache.org/jira/browse/NIFI-2568
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.1.0
>
>
> We should add support to the Solr processors for interacting with a 
> kerberized Solr cloud instance. The following pages described how Kerberos 
> works in Solr:
> https://cwiki.apache.org/confluence/display/solr/Kerberos+Authentication+Plugin
> From a client perspective it says you need the following:
> {code}
> System.setProperty("java.security.auth.login.config", 
> "/home/foo/jaas-client.conf");
> HttpClientUtil.setConfigurer(new Krb5HttpClientConfigurer());
> {code}



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

[jira] [Commented] (NIFI-1980) Add 'commit within' value to PutSolrContentStream

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-1980:
---

Commit d4948a377802ecc07f196370eefe92195d8a773f in nifi's branch 
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d4948a3 ]

NIFI-1768 Adding TLS/SSL support to Solr processors NIFI-1980 Added a default 
value for PutSolrContentStream commitWithIn NIFI-2568 Added Kerberos support to 
Solr processors

Upgrading SolrJ to 6.2.

Signed-off-by: Yolanda M. Davis 

This closes #1005


> Add 'commit within' value to PutSolrContentStream
> -
>
> Key: NIFI-1980
> URL: https://issues.apache.org/jira/browse/NIFI-1980
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Affects Versions: 0.6.1
> Environment: Solr 6.0.1 in **standalone** mode (in a docker 
> container).
>Reporter: Andrew Grande
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.1.0
>
>
> Here's a default docker image for Solr with some instructions to create a 
> core: https://github.com/docker-solr/docker-solr
> Have NiFi send to that Solr instance. Everything seems ok, but the number of 
> documents in the core never increases, no commit happens. *Commit Within* 
> must be configured (number of milliseconds) in case of a standalone Solr.
> Often Solr server is configured with auto-commit, but apparently not this 
> default docker image.
> Proposal: update the processor to have a default value for Commit Within 
> (e.g. match Solr's default of 15 seconds or less). Update its description to 
> hint the user to remove the value in case they configure auto-commit in Solr.



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

[jira] [Commented] (NIFI-1768) Add SSL Support for Solr Processors

[ASF subversion and git services (JIRA)]

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

ASF subversion and git services commented on NIFI-1768:
---

Commit d4948a377802ecc07f196370eefe92195d8a773f in nifi's branch 
refs/heads/master from [~bbende]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=d4948a3 ]

NIFI-1768 Adding TLS/SSL support to Solr processors NIFI-1980 Added a default 
value for PutSolrContentStream commitWithIn NIFI-2568 Added Kerberos support to 
Solr processors

Upgrading SolrJ to 6.2.

Signed-off-by: Yolanda M. Davis 

This closes #1005


> Add SSL Support for Solr Processors
> ---
>
> Key: NIFI-1768
> URL: https://issues.apache.org/jira/browse/NIFI-1768
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently the Solr processors do not support communicating with a Solr 
> instance that is secured with SSL. 
> We should be able to add the SSLContextService to the processor and pass an 
> SSLContext to the underlying HttpClient used by the SolrClient in the 
> SolrProcessor base class.



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

[jira] [Commented] (NIFI-1768) Add SSL Support for Solr Processors

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-1768:
--

Github user asfgit closed the pull request at:

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


> Add SSL Support for Solr Processors
> ---
>
> Key: NIFI-1768
> URL: https://issues.apache.org/jira/browse/NIFI-1768
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Extensions
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.1.0
>
>
> Currently the Solr processors do not support communicating with a Solr 
> instance that is secured with SSL. 
> We should be able to add the SSLContextService to the processor and pass an 
> SSLContext to the underlying HttpClient used by the SolrClient in the 
> SolrProcessor base class.



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

[GitHub] nifi pull request #1005: NIFI-1768 Adding TLS/SSL support to Solr processors

[asfgit]

Github user asfgit closed the pull request at:

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


---
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-2826) GetEventHubProcessor Support Enqueue Time

[Joseph Percivall (JIRA)]

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

Joseph Percivall commented on NIFI-2826:


Ticket for better handling restarts: 
https://issues.apache.org/jira/browse/NIFI-2835

> GetEventHubProcessor Support Enqueue Time
> -
>
> Key: NIFI-2826
> URL: https://issues.apache.org/jira/browse/NIFI-2826
> Project: Apache NiFi
>  Issue Type: Improvement
> Environment: centos6, jdk1.8, nifi 1.0.0
>Reporter: Joseph Niemiec
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-NIFI-2826-Adding-enqueue-time-to-GetAzureEventHub-pr.patch, patch.1
>
>
> The current GetEventHubProcessor should support allowing an enqueue time like 
> eventhubs to read messages from the past. This would also support reading 
> messages missed during downtime. Today the behaviour is for the processor to 
> start at the enqueue of when it was started by the user missing any past 
> messages. 



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

[jira] [Created] (NIFI-2835) GetAzureEventHub processor should leverage partition offset to better handle restarts

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFI-2835:
--

 Summary: GetAzureEventHub processor should leverage partition 
offset to better handle restarts
 Key: NIFI-2835
 URL: https://issues.apache.org/jira/browse/NIFI-2835
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Joseph Percivall


The GetAzureEventHub processor utilizes the Azure client that consists of 
receivers for each partition. The processor stores them in a map[1] that gets 
cleared every time the processor is stopped[2]. These receivers have partition 
offsets which keep track of which message it's currently on and which it should 
receive next. So currently, when the processor is stopped/restarted, any 
tracking of which message is next to be received is lost.

If instead of clearing the map each time, we hold onto the receivers, or kept 
track of the partitionId/Offsets when stopping, (barring any relevant 
configuration changes) the processor would restart exactly where it left off 
with no loss of data.

This would work very well with NIFI-2826.


[1]https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L122
[2] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L229



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

[jira] [Commented] (NIFI-2826) GetEventHubProcessor Support Enqueue Time

[Joseph Percivall (JIRA)]

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

Joseph Percivall commented on NIFI-2826:


Ticket for the configurable internal batching: 
https://issues.apache.org/jira/browse/NIFI-2834

> GetEventHubProcessor Support Enqueue Time
> -
>
> Key: NIFI-2826
> URL: https://issues.apache.org/jira/browse/NIFI-2826
> Project: Apache NiFi
>  Issue Type: Improvement
> Environment: centos6, jdk1.8, nifi 1.0.0
>Reporter: Joseph Niemiec
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-NIFI-2826-Adding-enqueue-time-to-GetAzureEventHub-pr.patch, patch.1
>
>
> The current GetEventHubProcessor should support allowing an enqueue time like 
> eventhubs to read messages from the past. This would also support reading 
> messages missed during downtime. Today the behaviour is for the processor to 
> start at the enqueue of when it was started by the user missing any past 
> messages. 



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

[jira] [Created] (NIFI-2834) GetAzureEventHub should make "max events to receive per ontrigger" configurable

[Joseph Percivall (JIRA)]

Joseph Percivall created NIFI-2834:
--

 Summary: GetAzureEventHub should make "max events to receive per 
ontrigger" configurable
 Key: NIFI-2834
 URL: https://issues.apache.org/jira/browse/NIFI-2834
 Project: Apache NiFi
  Issue Type: Improvement
Reporter: Joseph Percivall
Priority: Minor
 Fix For: 1.1.0


Current GetAzureEventHub processor is configured to always grab a max batch of 
100 events per ontrigger[1]. This internal batching scheme should be made 
configurable.

[1] 
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-azure-bundle/nifi-azure-processors/src/main/java/org/apache/nifi/processors/azure/eventhub/GetAzureEventHub.java#L215



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

[jira] [Assigned] (NIFI-2833) Increase font-size and line-height for message text in small dialogs

[Scott Aslan (JIRA)]

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

Scott Aslan reassigned NIFI-2833:
-

Assignee: Scott Aslan

> Increase font-size and line-height for message text in small dialogs
> 
>
> Key: NIFI-2833
> URL: https://issues.apache.org/jira/browse/NIFI-2833
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core UI
>Affects Versions: 1.0.0
>Reporter: Rob Moran
>Assignee: Scott Aslan
>Priority: Minor
> Attachments: current.png, proposed.png
>
>
> In small dialogs where error and various messages are communicated to the 
> user, the text is quite small. I'd recommend increasing the size and line 
> spacing to:
> font-size: 13px;
> line-height: 1.3;
> See attached screenshots for a current example and the proposed change.



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

[jira] [Updated] (NIFI-2831) "Auto-terminate" should be used consistently in Settings tab

[Scott Aslan (JIRA)]

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

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

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

> "Auto-terminate" should be used consistently in Settings tab
> 
>
> Key: NIFI-2831
> URL: https://issues.apache.org/jira/browse/NIFI-2831
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 0.7.0, 1.0.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Trivial
> Attachments: 0.7.0_auto-Terminate.png, 1.0.0_autoTerminate.png
>
>
> As shown in the attached screenshots of the Settings tab (0.7.0 and 1.0.0) 
> when configuring a processor:
> *The text "Auto terminate relationships" is displayed. This should be changed 
> to "Auto-terminate relationships"
> *In the Configuration error, should change "Cannot Auto-Terminate" to 
> "Cannot Auto-terminate"
> These changes would make references to auto-terminate functionality 
> consistent in the application and with the documentation 
> (https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#settings-tab).



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

[jira] [Commented] (NIFI-2831) "Auto-terminate" should be used consistently in Settings tab

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2831:
--

GitHub user scottyaslan opened a pull request:

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

[NIFI-2831] update auto terminate messages



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

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

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

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


commit df33cd47e01cbc8dcbb513523f863a3d481926dc
Author: Scott Aslan 
Date:   2016-09-28T16:21:21Z

[NIFI-2831] update auto terminate messages




> "Auto-terminate" should be used consistently in Settings tab
> 
>
> Key: NIFI-2831
> URL: https://issues.apache.org/jira/browse/NIFI-2831
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Trivial
> Attachments: 0.7.0_auto-Terminate.png, 1.0.0_autoTerminate.png
>
>
> As shown in the attached screenshots of the Settings tab (0.7.0 and 1.0.0) 
> when configuring a processor:
> *The text "Auto terminate relationships" is displayed. This should be changed 
> to "Auto-terminate relationships"
> *In the Configuration error, should change "Cannot Auto-Terminate" to 
> "Cannot Auto-terminate"
> These changes would make references to auto-terminate functionality 
> consistent in the application and with the documentation 
> (https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#settings-tab).



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

[GitHub] nifi pull request #1077: [NIFI-2831] update auto terminate messages

[scottyaslan]

GitHub user scottyaslan opened a pull request:

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

[NIFI-2831] update auto terminate messages



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

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

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

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


commit df33cd47e01cbc8dcbb513523f863a3d481926dc
Author: Scott Aslan 
Date:   2016-09-28T16:21:21Z

[NIFI-2831] update auto terminate messages




---
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-2826) GetEventHubProcessor Support Enqueue Time

[Joseph Percivall (JIRA)]

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

Joseph Percivall commented on NIFI-2826:


Hey [~josephxsxn] a couple thoughts:

1: The input type for enqueue time should probably be changed from epoch time 
to a standard date format. We try to cater to the non-technical users of NiFi 
when it comes to processor configuration and I fear most non-technical users 
would have no idea what epoch time is. Also it would just be annoying to 
convert to.

2: The default value should be removed and instead add a check to the 
"getReceiver" method to see if ENQUEUE_TIME is set. We try our best to not 
change any default behavior in non-major releases and there would be a 
difference between "when the property gets populated with the default value" 
and "when the receiver gets instantiated". So just a check on line 197 where if 
ENQUEUE_TIME is set use it and else use "Instant.now()".

3: Looking at this, the processor could use some improvements in regards to 
durable restart. Currently on every start/stop the partition receiver list is 
cleared. It would be nice to keep those until the configuration changes so that 
the processor could pick back up right where it left off so no data is lost. 
That's outside the scope of this ticket but just putting down some thoughts 
(I'll create another ticket). Also another ticket to be created is to make the 
"Max number of events received" configurable (line 224).

Let me know your thoughts and we can iterate on the patch. Thanks!

> GetEventHubProcessor Support Enqueue Time
> -
>
> Key: NIFI-2826
> URL: https://issues.apache.org/jira/browse/NIFI-2826
> Project: Apache NiFi
>  Issue Type: Improvement
> Environment: centos6, jdk1.8, nifi 1.0.0
>Reporter: Joseph Niemiec
>Assignee: Joseph Niemiec
>Priority: Minor
> Fix For: 1.1.0
>
> Attachments: 
> 0001-NIFI-2826-Adding-enqueue-time-to-GetAzureEventHub-pr.patch, patch.1
>
>
> The current GetEventHubProcessor should support allowing an enqueue time like 
> eventhubs to read messages from the past. This would also support reading 
> messages missed during downtime. Today the behaviour is for the processor to 
> start at the enqueue of when it was started by the user missing any past 
> messages. 



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

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

[trixpan]

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

https://github.com/apache/nifi/pull/785#discussion_r80934511
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/pom.xml ---
@@ -254,6 +254,17 @@ language governing permissions and limitations under 
the License. -->
 org.everit.json.schema
 1.4.0
 
+
+com.fluenda
+ParCEFone
--- End diff --

both done.


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

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

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2341:
--

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

https://github.com/apache/nifi/pull/785#discussion_r80934511
  
--- Diff: 
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/pom.xml ---
@@ -254,6 +254,17 @@ language governing permissions and limitations under 
the License. -->
 org.everit.json.schema
 1.4.0
 
+
+com.fluenda
+ParCEFone
--- End diff --

both done.


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



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

[jira] [Commented] (NIFI-2831) "Auto-terminate" should be used consistently in Settings tab

[Andrew Lim (JIRA)]

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

Andrew Lim commented on NIFI-2831:
--

[~rmoran] Sounds good to change all of these references to "automatically 
terminate".   So in the Settings tab, the text will read "Automatically 
Terminate Relationships".  In the error message it will read "Cannot 
automatically terminate 'success'..."   Once done, I will update the docs 
accordingly.

> "Auto-terminate" should be used consistently in Settings tab
> 
>
> Key: NIFI-2831
> URL: https://issues.apache.org/jira/browse/NIFI-2831
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.0.0, 0.7.0
>Reporter: Andrew Lim
>Assignee: Scott Aslan
>Priority: Trivial
> Attachments: 0.7.0_auto-Terminate.png, 1.0.0_autoTerminate.png
>
>
> As shown in the attached screenshots of the Settings tab (0.7.0 and 1.0.0) 
> when configuring a processor:
> *The text "Auto terminate relationships" is displayed. This should be changed 
> to "Auto-terminate relationships"
> *In the Configuration error, should change "Cannot Auto-Terminate" to 
> "Cannot Auto-terminate"
> These changes would make references to auto-terminate functionality 
> consistent in the application and with the documentation 
> (https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#settings-tab).



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

[GitHub] nifi issue #1064: Verifying Controller Service cannot move out of scope

[mcgilman]

Github user mcgilman commented on the issue:

https://github.com/apache/nifi/pull/1064
  
Good call. Will update.


---
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] [Comment Edited] (NIFI-2615) Add support for GetTCP processor

[Raf Huys (JIRA)]

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

Raf Huys edited comment on NIFI-2615 at 9/28/16 2:11 PM:
-

Hi [~apsaltis], we're having the same requirement: we need a TCP connection 
where we can write to *and* read from. Transformed to NiFi, that would mean a 
PutTCP and a GetTCP.  

I found your release of the nifi-standard-nar 
(https://github.com/apsaltis/nifi-gettcp/releases). I'm using nifi@1.0.0 now, 
and replacing the nifi-standard-nar-1.0.0 with your 0.6.1 gives 
{code}
2016-09-28 15:51:18,626 ERROR [main] org.apache.nifi.NiFi Failure to launch 
NiFi due to java.util.ServiceConfigurationError: 
org.apache.nifi.processor.Processor: Provider 
org.apache.nifi.processors.standard.GetTCP could not be instantiated
java.util.ServiceConfigurationError: org.apache.nifi.processor.Processor: 
Provider org.apache.nifi.processors.standard.GetTCP could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:232) ~[na:1.8.0_101]
at ...
Caused by: java.lang.NoSuchMethodError: 
org.apache.nifi.processors.standard.GetTCP.getLogger()Lorg/apache/nifi/logging/ProcessorLog;
at org.apache.nifi.processors.standard.GetTCP.(GetTCP.java:133) 
~[nifi-standard-processors-0.6.1.jar:0.6.1]
{code}

- do you plan to push this GetTCP feature upstream? If not, any reason why?
- are there plan to open source the release versions of GetTCP?


was (Author: raf.h...@gmail.com):
Hi [~apsaltis], we're having the same requirement: we need a TCP connection 
where we can write to *and* read from. Transformed to NiFi, that would mean a 
PutTCP and a GetTCP.  

I found your release of the nifi-standard-nar 
(https://github.com/apsaltis/nifi-gettcp/releases). I'm using nifi@1.0.0 now, 
and replacing the nifi-standard-nar-1.0.0 with your 0.6.1 gives 
{code}
2016-09-28 15:51:18,626 ERROR [main] org.apache.nifi.NiFi Failure to launch 
NiFi due to java.util.ServiceConfigurationError: 
org.apache.nifi.processor.Processor: Provider 
org.apache.nifi.processors.standard.GetTCP could not be instantiated
java.util.ServiceConfigurationError: org.apache.nifi.processor.Processor: 
Provider org.apache.nifi.processors.standard.GetTCP could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:232) ~[na:1.8.0_101]
at ...
Caused by: java.lang.NoSuchMethodError: 
org.apache.nifi.processors.standard.GetTCP.getLogger()Lorg/apache/nifi/logging/ProcessorLog;
at org.apache.nifi.processors.standard.GetTCP.(GetTCP.java:133) 
~[nifi-standard-processors-0.6.1.jar:0.6.1]
{code}

- do you plan to push this GetTCP feature upstream? If not, any reason why?

> Add support for GetTCP processor
> 
>
> Key: NIFI-2615
> URL: https://issues.apache.org/jira/browse/NIFI-2615
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0, 0.6.1
>Reporter: Andrew Psaltis
>Assignee: Andrew Psaltis
>
> This processor will allow NiFi to connect to a host via TCP, thus acting as 
> the client and consume data. This should provide the following properties:
> * Endpoint -  this should accept a list of addresses in the format of 
> : - if a user wants to be able to track the ingestion rate per 
> address then you would want to have one address in this list. However, there 
> are times when multiple endpoints represent a logical entity and the 
> aggregate ingestion rate is representative of it. 
> * Failover Endpoint - An endpoint to fall over to if the list of Endpoints is 
> exhausted and a connection cannot be made to them or it is disconnected and 
> cannot reconnect.
> * Receive Buffer Size -- The size of the TCP receive buffer to use. This does 
> not related to the size of content in the resulting flow file.
> * Keep Alive -- This enables TCP keep Alive
> * Connection Timeout -- How long to wait when trying to establish a connection
> * Batch Size - The number of messages to put into a Flow File. This will be 
> the max number of messages, as there may be cases where the number of 
> messages received over the wire waiting to be emitted as FF content may be 
> less then the desired batch.
> This processor should also support the following:
> 1. If a connection to end endpoint is broken, it should be logged and 
> reconnections to it should be made. Potentially an exponential backoff 
> strategy will be used. The strategy if there is more than one should be 
> documented and potentially exposed as an Attribute.
> 2. When there are multiple instances of this processor in a flow and NiFi is 
> setup in a cluster, this processor needs to ensure that received messages are 
> not dual processed. For example if this processor is configured to point to 
> the endpoint 

[jira] [Commented] (NIFI-2615) Add support for GetTCP processor

[Raf Huys (JIRA)]

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

Raf Huys commented on NIFI-2615:


Hi [~apsaltis], we're having the same requirement: we need a TCP connection 
where we can write to *and* read from. Transformed to NiFi, that would mean a 
PutTCP and a GetTCP.  

I found your release of the nifi-standard-nar 
(https://github.com/apsaltis/nifi-gettcp/releases). I'm using nifi@1.0.0 now, 
and replacing the nifi-standard-nar-1.0.0 with your 0.6.1 gives 
{code}[Caused by: java.lang.NoSuchMethodError: 
org.apache.nifi.processors.standard.GetTCP.getLogger()Lorg/apache/nifi/logging/ProcessorLog;
at org.apache.nifi.processors.standard.GetTCP.(GetTCP.java:133) 
~[nifi-standard-processors-0.6.1.jar:0.6.1]{code}

- do you plan to push this GetTCP feature upstream? If not, any reason why?

> Add support for GetTCP processor
> 
>
> Key: NIFI-2615
> URL: https://issues.apache.org/jira/browse/NIFI-2615
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0, 0.6.1
>Reporter: Andrew Psaltis
>Assignee: Andrew Psaltis
>
> This processor will allow NiFi to connect to a host via TCP, thus acting as 
> the client and consume data. This should provide the following properties:
> * Endpoint -  this should accept a list of addresses in the format of 
> : - if a user wants to be able to track the ingestion rate per 
> address then you would want to have one address in this list. However, there 
> are times when multiple endpoints represent a logical entity and the 
> aggregate ingestion rate is representative of it. 
> * Failover Endpoint - An endpoint to fall over to if the list of Endpoints is 
> exhausted and a connection cannot be made to them or it is disconnected and 
> cannot reconnect.
> * Receive Buffer Size -- The size of the TCP receive buffer to use. This does 
> not related to the size of content in the resulting flow file.
> * Keep Alive -- This enables TCP keep Alive
> * Connection Timeout -- How long to wait when trying to establish a connection
> * Batch Size - The number of messages to put into a Flow File. This will be 
> the max number of messages, as there may be cases where the number of 
> messages received over the wire waiting to be emitted as FF content may be 
> less then the desired batch.
> This processor should also support the following:
> 1. If a connection to end endpoint is broken, it should be logged and 
> reconnections to it should be made. Potentially an exponential backoff 
> strategy will be used. The strategy if there is more than one should be 
> documented and potentially exposed as an Attribute.
> 2. When there are multiple instances of this processor in a flow and NiFi is 
> setup in a cluster, this processor needs to ensure that received messages are 
> not dual processed. For example if this processor is configured to point to 
> the endpoint (172.31.32.212:1) and the data flow is running on more than 
> one node then only one node should be processing data. In essence they should 
> form a group and have similar semantics as a Kafka consumer group does.



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

[jira] [Comment Edited] (NIFI-2615) Add support for GetTCP processor

[Raf Huys (JIRA)]

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

Raf Huys edited comment on NIFI-2615 at 9/28/16 2:05 PM:
-

Hi [~apsaltis], we're having the same requirement: we need a TCP connection 
where we can write to *and* read from. Transformed to NiFi, that would mean a 
PutTCP and a GetTCP.  

I found your release of the nifi-standard-nar 
(https://github.com/apsaltis/nifi-gettcp/releases). I'm using nifi@1.0.0 now, 
and replacing the nifi-standard-nar-1.0.0 with your 0.6.1 gives 
{code}
2016-09-28 15:51:18,626 ERROR [main] org.apache.nifi.NiFi Failure to launch 
NiFi due to java.util.ServiceConfigurationError: 
org.apache.nifi.processor.Processor: Provider 
org.apache.nifi.processors.standard.GetTCP could not be instantiated
java.util.ServiceConfigurationError: org.apache.nifi.processor.Processor: 
Provider org.apache.nifi.processors.standard.GetTCP could not be instantiated
at java.util.ServiceLoader.fail(ServiceLoader.java:232) ~[na:1.8.0_101]
at ...
Caused by: java.lang.NoSuchMethodError: 
org.apache.nifi.processors.standard.GetTCP.getLogger()Lorg/apache/nifi/logging/ProcessorLog;
at org.apache.nifi.processors.standard.GetTCP.(GetTCP.java:133) 
~[nifi-standard-processors-0.6.1.jar:0.6.1]
{code}

- do you plan to push this GetTCP feature upstream? If not, any reason why?


was (Author: raf.h...@gmail.com):
Hi [~apsaltis], we're having the same requirement: we need a TCP connection 
where we can write to *and* read from. Transformed to NiFi, that would mean a 
PutTCP and a GetTCP.  

I found your release of the nifi-standard-nar 
(https://github.com/apsaltis/nifi-gettcp/releases). I'm using nifi@1.0.0 now, 
and replacing the nifi-standard-nar-1.0.0 with your 0.6.1 gives 
{code}[Caused by: java.lang.NoSuchMethodError: 
org.apache.nifi.processors.standard.GetTCP.getLogger()Lorg/apache/nifi/logging/ProcessorLog;
at org.apache.nifi.processors.standard.GetTCP.(GetTCP.java:133) 
~[nifi-standard-processors-0.6.1.jar:0.6.1]{code}

- do you plan to push this GetTCP feature upstream? If not, any reason why?

> Add support for GetTCP processor
> 
>
> Key: NIFI-2615
> URL: https://issues.apache.org/jira/browse/NIFI-2615
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0, 0.6.1
>Reporter: Andrew Psaltis
>Assignee: Andrew Psaltis
>
> This processor will allow NiFi to connect to a host via TCP, thus acting as 
> the client and consume data. This should provide the following properties:
> * Endpoint -  this should accept a list of addresses in the format of 
> : - if a user wants to be able to track the ingestion rate per 
> address then you would want to have one address in this list. However, there 
> are times when multiple endpoints represent a logical entity and the 
> aggregate ingestion rate is representative of it. 
> * Failover Endpoint - An endpoint to fall over to if the list of Endpoints is 
> exhausted and a connection cannot be made to them or it is disconnected and 
> cannot reconnect.
> * Receive Buffer Size -- The size of the TCP receive buffer to use. This does 
> not related to the size of content in the resulting flow file.
> * Keep Alive -- This enables TCP keep Alive
> * Connection Timeout -- How long to wait when trying to establish a connection
> * Batch Size - The number of messages to put into a Flow File. This will be 
> the max number of messages, as there may be cases where the number of 
> messages received over the wire waiting to be emitted as FF content may be 
> less then the desired batch.
> This processor should also support the following:
> 1. If a connection to end endpoint is broken, it should be logged and 
> reconnections to it should be made. Potentially an exponential backoff 
> strategy will be used. The strategy if there is more than one should be 
> documented and potentially exposed as an Attribute.
> 2. When there are multiple instances of this processor in a flow and NiFi is 
> setup in a cluster, this processor needs to ensure that received messages are 
> not dual processed. For example if this processor is configured to point to 
> the endpoint (172.31.32.212:1) and the data flow is running on more than 
> one node then only one node should be processing data. In essence they should 
> form a group and have similar semantics as a Kafka consumer group does.



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

[jira] [Assigned] (NIFI-2830) Template UUIDs out of sync in cluster

[Matt Gilman (JIRA)]

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

Matt Gilman reassigned NIFI-2830:
-

Assignee: Matt Gilman

> Template UUIDs out of sync in cluster
> -
>
> Key: NIFI-2830
> URL: https://issues.apache.org/jira/browse/NIFI-2830
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0
>Reporter: Aldrin Piri
>Assignee: Matt Gilman
>
> I uploaded a template to a clustered instance of NiFi which presented me with 
> a success dialog.  This, and subsequent actions, were performed through a 
> node, nifi1.  Upon trying to add this template to the canvas, I received a 
> message that
> {code}
> Node nifi2:8443 is unable to fulfill this request due to: Unable to locate 
> template with id '76c907b3-2664-30e4-987b-e9021ebcc844'.
> {code}
> Upon performing an inspection on several of the nodes in the cluster, I saw 
> that all but nifi2 had the above listed UUID, but nifi2 had a different UUID. 
>  Upon trying to delete the template, I was presented with the same error.  
> This behavior, inclusive of the error message was the same when performing 
> the same actions on nifi2.
> Re-uploading the template with a different name, everything worked as 
> anticipated.
> There was nothing of note in nifi-app or nifi-user logs beyond the 
> information provided in the error dialog.  Of possible note is that the node 
> in question was possibly having some intermittent network issues but was 
> listed as continuously connected on the node I was accessing.



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

[jira] [Created] (NIFI-2833) Increase font-size and line-height for message text in small dialogs

[Rob Moran (JIRA)]

Rob Moran created NIFI-2833:
---

 Summary: Increase font-size and line-height for message text in 
small dialogs
 Key: NIFI-2833
 URL: https://issues.apache.org/jira/browse/NIFI-2833
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Core UI
Affects Versions: 1.0.0
Reporter: Rob Moran
Priority: Minor


In small dialogs where error and various messages are communicated to the user, 
the text is quite small. I'd recommend increasing the size and line spacing to:

font-size: 13px;
line-height: 1.3;

See attached screenshots for a current example and the proposed change.



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

[GitHub] nifi-minifi-cpp issue #13: MINIFI-109: Add ExecuteProcess

[apiri]

Github user apiri commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/13
  
@benqiu2016 Looks good here!  Will merge in and thanks for the contribution.


---
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-2763) S3 processors do not work with older S3-compatible object stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2763:
--

GitHub user baank opened a pull request:

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

NIFI-2763: S3 processors do not work with older S3-compatible object …

Updated to reflect comments i.e. made it S3 only and a dropdown.

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

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

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

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


commit 7431cfbd76608a2f68d22d0fc526294c5ecca799
Author: d810146 
Date:   2016-09-28T06:16:21Z

NIFI-2763: S3 processors do not work with older S3-compatible object stores




> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[GitHub] nifi pull request #1076: NIFI-2763: S3 processors do not work with older S3-...

[baank]

GitHub user baank opened a pull request:

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

NIFI-2763: S3 processors do not work with older S3-compatible object …

Updated to reflect comments i.e. made it S3 only and a dropdown.

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

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

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

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


commit 7431cfbd76608a2f68d22d0fc526294c5ecca799
Author: d810146 
Date:   2016-09-28T06:16:21Z

NIFI-2763: S3 processors do not work with older S3-compatible object stores




---
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-2763) S3 processors do not work with older S3-compatible object stores

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on NIFI-2763:
--

Github user baank closed the pull request at:

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


> S3 processors do not work with older S3-compatible object stores
> 
>
> Key: NIFI-2763
> URL: https://issues.apache.org/jira/browse/NIFI-2763
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0
>Reporter: Franco
>  Labels: easyfix
> Fix For: 1.1.0
>
>
> In the 1.0.0 release of NiFi it is using the AWS library for connecting to S3 
> and S3-compatible object stores.
> This library by default expects V4 signer support which if you are using an 
> older object store will not be available and so NiFi will be unusable.
> The fix is simple:
> Allow the user to specify (if they wish) the signer type that AWS library 
> should use.



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

[GitHub] nifi pull request #1008: NIFI-2763 S3 processors do not work with older S3-c...

[baank]

Github user baank closed the pull request at:

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


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