date:20170919


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

Deon Huang updated NIFI-4395:
-
Summary: GenerateTableFetch can't fetch column type by state after instance 
reboot  (was: GnerateTableFetch can't fetch column type by state through 
instance reboot)

> GenerateTableFetch can't fetch column type by state after instance reboot
> -
>
> Key: NIFI-4395
> URL: https://issues.apache.org/jira/browse/NIFI-4395
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Deon Huang
> Fix For: 1.4.0
>
> Attachments: GenerateTableFetch_Exception.png
>
>
> The problem can easily be reproduce.
> Once GenerateTableFetch store state and encounter NiFi instance reboot.
> (Dynamic naming table by expression language)
> The exception will occur.
> The error in source code is list below.
> ---
> if (type == null) {
> // This shouldn't happen as we are populating columnTypeMap when the 
> processor is scheduled or when the first maximum is observed
> throw new IllegalArgumentException("No column type found for: " + 
> colName);
> }
> ---
> When this situation happened. The FlowFile will also be grab and can't 
> release or observed.
> Processor can't existing grab column type from columnTypeMap through instance 
> reboot.
> Hence will inevidible get this exception, rollback FlowFile and never success.
> QueryDatabaseTable processor will not encounter this exception due to it 
> setup(context) every time,
> While GenerateTableFetch will not pass the condition and thus try to fetch 
> column type from 0 length columnTypeMap.
> ---
> if (!isDynamicTableName && !isDynamicMaxValues) {
> super.setup(context);
> }
> ---
> I can take the issue if it is recognize as bug.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3248) GetSolr can miss recently updated documents

2017-09-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura commented on NIFI-3248:
-

Hi [~jope], thanks for your update. By looking at (1), I wonder if NiFi will be 
able to follow situations such as [Splitting 
Shards|https://cwiki.apache.org/confluence/display/solr/Collections+API], 
especially if NiFi user has to specify shard names. Once a shard is split the 
processor configuration has to be updated manually. Also the processor has to 
handle state management properly.

If dealing with Solr internal mechanism (_version_ and sharding) is too complex 
from NiFi codebase, I'd be fine to implement it with "StreamSolr" approach that 
Bryan mentioned earlier, and keep existing GetSolr implementation simple as of 
now.

(3) This is great!
(4) I like this enhancement. Since many Record aware processors added 
separately in addition to existing processors, it'd be also reasonable to 
implement this capability at the new "StreamSolr" processor if we are going to 
add that. In order to support record, processor has to work with 
RecordSetWriter and schema, so processor properties and documentation may 
become more complex if we support this at GetSolr. Maybe I just overly concern 
about it, but adding many features within a single processor would make it 
harder to maintain overtime.

> GetSolr can miss recently updated documents
> ---
>
> Key: NIFI-3248
> URL: https://issues.apache.org/jira/browse/NIFI-3248
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0, 0.5.0, 0.6.0, 0.5.1, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 
> 1.0.1
>Reporter: Koji Kawamura
>Assignee: Johannes Peter
> Attachments: nifi-flow.png, query-result-with-curly-bracket.png, 
> query-result-with-square-bracket.png
>
>
> GetSolr holds the last query timestamp so that it only fetches documents 
> those have been added or updated since the last query.
> However, GetSolr misses some of those updated documents, and once the 
> documents date field value becomes older than last query timestamp, the 
> document won't be able to be queried by GetSolr any more.
> This JIRA is for tracking the process of investigating this behavior, and 
> discussion on them.
> Here are things that can be a cause of this behavior:
> |#|Short description|Should we address it?|
> |1|Timestamp range filter, curly or square bracket?|No|
> |2|Timezone difference between update and query|Additional docs might be 
> helpful|
> |3|Lag comes from NearRealTIme nature of Solr|Should be documented at least, 
> add 'commit lag-time'?|
> h2. 1. Timestamp range filter, curly or square bracket?
> At the first glance, using curly and square bracket in mix looked strange 
> ([source 
> code|https://github.com/apache/nifi/blob/support/nifi-0.5.x/nifi-nar-bundles/nifi-solr-bundle/nifi-solr-processors/src/main/java/org/apache/nifi/processors/solr/GetSolr.java#L202]).
>  But these difference has a meaning.
> The square bracket on the range query is inclusive and the curly bracket is 
> exclusive. If we use inclusive on both sides and a document has a time stamp 
> exactly on the boundary then it could be returned in two consecutive 
> executions, and we only want it in one.
> This is intentional, and it should be as it is.
> h2. 2. Timezone difference between update and query
> Solr treats date fields as [UTC 
> representation|https://cwiki.apache.org/confluence/display/solr/Working+with+Dates|].
>  If date field String value of an updated document represents time without 
> timezone, and NiFi is running on an environment using timezone other than 
> UTC, GetSolr can't perform date range query as users expect.
> Let's say NiFi is running with JST(UTC+9). A process added a document to Solr 
> at 15:00 JST. But the date field doesn't have timezone. So, Solr indexed it 
> as 15:00 UTC. Then GetSolr performs range query at 15:10 JST, targeting any 
> documents updated from 15:00 to 15:10 JST. GetSolr formatted dates using UTC, 
> i.e. 6:00 to 6:10 UTC. The updated document won't be matched with the date 
> range filter.
> To avoid this, updated documents must have proper timezone in date field 
> string representation.
> If one uses NiFi expression language to set current timestamp to that date 
> field, following NiFi expression can be used:
> {code}
> ${now():format("-MM-dd'T'HH:mm:ss.SSSZ")}
> {code}
> It will produce a result like:
> {code}
> 2016-12-27T15:30:04.895+0900
> {code}
> Then it will be indexed in Solr with UTC and will be queried by GetSolr as 
> expected.
> h2. 3. Lag comes from NearRealTIme nature of Solr
> Solr provides Near Real Time search capability, that means, the recently 
> updated documents can be queried in Near Real Time, but it's not real time. 
> This

[jira] [Commented] (MINIFICPP-67) Mergecontent processor for minifi-cpp


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

ASF GitHub Bot commented on MINIFICPP-67:
-

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/133
  
@phrocker rebased


> Mergecontent processor for minifi-cpp
> -
>
> Key: MINIFICPP-67
> URL: https://issues.apache.org/jira/browse/MINIFICPP-67
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Karthik Narayanan
>
> A simpler processor than the nifi merge content processor. It should support 
> at least binary concatenation. it will basically allow a flow running in 
> minifi to group several events at a time and send them to nifi, to better 
> utilize the network bandwidth. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-minifi-cpp issue #133: MINIFICPP-67: Merge Content processor

2017-09-19 Thread minifirocks

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/133
  
@phrocker rebased


---

[jira] [Commented] (MINIFICPP-67) Mergecontent processor for minifi-cpp


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

ASF GitHub Bot commented on MINIFICPP-67:
-

Github user phrocker commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/133
  
@minifirocks Can you rebase against master? Your commits have unrelated 
content.


> Mergecontent processor for minifi-cpp
> -
>
> Key: MINIFICPP-67
> URL: https://issues.apache.org/jira/browse/MINIFICPP-67
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Karthik Narayanan
>
> A simpler processor than the nifi merge content processor. It should support 
> at least binary concatenation. it will basically allow a flow running in 
> minifi to group several events at a time and send them to nifi, to better 
> utilize the network bandwidth. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-minifi-cpp issue #133: MINIFICPP-67: Merge Content processor

Github user phrocker commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/133
  
@minifirocks Can you rebase against master? Your commits have unrelated 
content.


---

[jira] [Commented] (MINIFICPP-67) Mergecontent processor for minifi-cpp


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

ASF GitHub Bot commented on MINIFICPP-67:
-

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/133
  
@phrocker @apiri please approve the same, i would like to merge that before 
i add the compression/tar support for merge content.


> Mergecontent processor for minifi-cpp
> -
>
> Key: MINIFICPP-67
> URL: https://issues.apache.org/jira/browse/MINIFICPP-67
> Project: NiFi MiNiFi C++
>  Issue Type: Improvement
>Reporter: Karthik Narayanan
>
> A simpler processor than the nifi merge content processor. It should support 
> at least binary concatenation. it will basically allow a flow running in 
> minifi to group several events at a time and send them to nifi, to better 
> utilize the network bandwidth. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-minifi-cpp issue #133: MINIFICPP-67: Merge Content processor

2017-09-19 Thread minifirocks

Github user minifirocks commented on the issue:

https://github.com/apache/nifi-minifi-cpp/pull/133
  
@phrocker @apiri please approve the same, i would like to merge that before 
i add the compression/tar support for merge content.


---

[jira] [Commented] (MINIFICPP-72) Add tar and compression support for MergeContent

2017-09-19 Thread bqiu (JIRA)


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

bqiu commented on MINIFICPP-72:
---

Hey, Aldrin

the NiFi merge content  processor support merge format like Binary 
Concatenation/TAR/ZIP.
The MergeContent Processor that i did for MiNiFI only support Binary 
Concatenation for the merge BIN files.
We need to add TAR and ZIP format.

The compress content processor is different than merge content, if we get the 
common libarchive in, we can scope the work for compress content processor also.

> Add tar and compression support for MergeContent
> 
>
> Key: MINIFICPP-72
> URL: https://issues.apache.org/jira/browse/MINIFICPP-72
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: bqiu
> Fix For: 1.0.0
>
>
> Add tar and compression support for MergeContent
> will use the https://www.libarchive.org



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-3248) GetSolr can miss recently updated documents

2017-09-19 Thread Johannes Peter (JIRA)


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

Johannes Peter commented on NIFI-3248:
--

Update:

I am almost done with the new processor implementation. Quick update: 

(1) Meanwhile I had a little conversation with Cassandra Targett (Solr PMC), 
and she helped me clarifying some things about field \_version\_. 
Unfortunately, it is not possible to convert a value of this field into a valid 
timestamp. The values of this field are monotonically increasing depending on 
indexing time, but only at shard level, not at collection level. I am sorry for 
the confusion. The processor therefore iterates over shards if (a) Solr runs in 
cloud mode and (b) \_version\_ is used to track document retrieval instead of a 
dedicated date field. Although this way might require more queries and 
therefore be slower if collections comprise many shards, I implemented this to 
make the processor suitable for many more collections. The shard names 
currently have to be specified by property as I yet have not found a reliable 
way to figure them out automatically (shard names != core names).
(2) I implemented an option to make the use of filter query caches 
configurable. 
(3) The processor now makes use of the StateManager. 
(4) I will add an option to convert results into records.

> GetSolr can miss recently updated documents
> ---
>
> Key: NIFI-3248
> URL: https://issues.apache.org/jira/browse/NIFI-3248
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.0.0, 0.5.0, 0.6.0, 0.5.1, 0.7.0, 0.6.1, 1.1.0, 0.7.1, 
> 1.0.1
>Reporter: Koji Kawamura
>Assignee: Johannes Peter
> Attachments: nifi-flow.png, query-result-with-curly-bracket.png, 
> query-result-with-square-bracket.png
>
>
> GetSolr holds the last query timestamp so that it only fetches documents 
> those have been added or updated since the last query.
> However, GetSolr misses some of those updated documents, and once the 
> documents date field value becomes older than last query timestamp, the 
> document won't be able to be queried by GetSolr any more.
> This JIRA is for tracking the process of investigating this behavior, and 
> discussion on them.
> Here are things that can be a cause of this behavior:
> |#|Short description|Should we address it?|
> |1|Timestamp range filter, curly or square bracket?|No|
> |2|Timezone difference between update and query|Additional docs might be 
> helpful|
> |3|Lag comes from NearRealTIme nature of Solr|Should be documented at least, 
> add 'commit lag-time'?|
> h2. 1. Timestamp range filter, curly or square bracket?
> At the first glance, using curly and square bracket in mix looked strange 
> ([source 
> code|https://github.com/apache/nifi/blob/support/nifi-0.5.x/nifi-nar-bundles/nifi-solr-bundle/nifi-solr-processors/src/main/java/org/apache/nifi/processors/solr/GetSolr.java#L202]).
>  But these difference has a meaning.
> The square bracket on the range query is inclusive and the curly bracket is 
> exclusive. If we use inclusive on both sides and a document has a time stamp 
> exactly on the boundary then it could be returned in two consecutive 
> executions, and we only want it in one.
> This is intentional, and it should be as it is.
> h2. 2. Timezone difference between update and query
> Solr treats date fields as [UTC 
> representation|https://cwiki.apache.org/confluence/display/solr/Working+with+Dates|].
>  If date field String value of an updated document represents time without 
> timezone, and NiFi is running on an environment using timezone other than 
> UTC, GetSolr can't perform date range query as users expect.
> Let's say NiFi is running with JST(UTC+9). A process added a document to Solr 
> at 15:00 JST. But the date field doesn't have timezone. So, Solr indexed it 
> as 15:00 UTC. Then GetSolr performs range query at 15:10 JST, targeting any 
> documents updated from 15:00 to 15:10 JST. GetSolr formatted dates using UTC, 
> i.e. 6:00 to 6:10 UTC. The updated document won't be matched with the date 
> range filter.
> To avoid this, updated documents must have proper timezone in date field 
> string representation.
> If one uses NiFi expression language to set current timestamp to that date 
> field, following NiFi expression can be used:
> {code}
> ${now():format("-MM-dd'T'HH:mm:ss.SSSZ")}
> {code}
> It will produce a result like:
> {code}
> 2016-12-27T15:30:04.895+0900
> {code}
> Then it will be indexed in Solr with UTC and will be queried by GetSolr as 
> expected.
> h2. 3. Lag comes from NearRealTIme nature of Solr
> Solr provides Near Real Time search capability, that means, the recently 
> updated documents can be queried in Near Real Time, but it's not real time. 
> This latency can be

[jira] [Commented] (NIFI-2663) Add Websocket support for MQTT protocol


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

ASF GitHub Bot commented on NIFI-2663:
--

Github user SebastianCarroll commented on the issue:

https://github.com/apache/nifi/pull/2154
  
Hey @JPercivall! Thanks for the review! What I was referring to with the 3 
letter change was in the test class itself not the core code. For example, I 
thought  about changing the 'ssl' value in 
[TestConsumeMqttSSL](https://github.com/apache/nifi/blob/7923fd04c35737df8145b213536bdf333ef72713/nifi-nar-bundles/nifi-mqtt-bundle/nifi-mqtt-processors/src/test/java/org/apache/nifi/processors/mqtt/integration/TestConsumeMqttSSL.java#L74)
 assuming that we would want to run all the same tests for wss as to ssl (and 
similarly for ws as for tcp). Subclassing common/Test*MqttCommon as you suggest 
won't remove this issue as I would essentially be reimplementing all the tests 
and setup from TestConsumeMqttSSL. However I could subclass TestConsumeMqttSSL 
-> TestConsumeMqttWss (for example) and pull the assigning of the broker out 
into a method and just overwrite that in the subclass.

For the changes to MqttTestClient.java, they were autogenerated using 
Intellij. I believe this is due to changes in the IMqttClient  interface 
referenced in the newer version of the Paho dependancy (1.1.1 from 1.0.2). Is 
it good practice to leave these as are? It does feel unnecessary to have all 
the comments there given they are only implemented to make a stub (or mock? I'm 
never sure exactly which is which)

I'm still trying to get the -Pcontrib-check flag to work. I originally 
ticked that box in the PR erroneously.

Hope this helps with the review and thanks again!
Seb


> Add Websocket support for MQTT protocol
> ---
>
> Key: NIFI-2663
> URL: https://issues.apache.org/jira/browse/NIFI-2663
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.7.0, 0.6.1
>Reporter: Andrew Psaltis
>Assignee: Andrew Psaltis
>
> Today NiFi only supports MQTT over plain TCP using the PublishMQTT and 
> ConsumeMQTT processors. However, there are many cases in the IoT world where 
> WebSockets (secure and not) is the preferred transport mechanism for MQTT.  
> This JIRA is to enhance those processors to also support WS.
> Following are the basics of what is required:
>  
> 1)  Require to configure web socket as the transport protocol, currently 
> PublishMQTT processor supports TCP as the only transport protocol
> 2)  URL input for the Web socket transport should be in the format of 
> ws://IPAddress:websocket_listening_port, as of now it accepts only TCP url, 
> and a bulletin is raised if a protocol other than tcp or ssl is used.
> 3)  Similar to TCP non-secured and secured publisher we should 
> extend/provide processor to support WS and WSS transport protocols



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2154: NIFI-2663: Add WebSocket support for MQTT processors

2017-09-19 Thread SebastianCarroll

Github user SebastianCarroll commented on the issue:

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

Hey @JPercivall! Thanks for the review! What I was referring to with the 3
letter change was in the test class itself not the core code. For example, I
thought about changing the 'ssl' value in
[TestConsumeMqttSSL](https://github.com/apache/nifi/blob/7923fd04c35737df8145b213536bdf333ef72713/nifi-nar-bundles/nifi-mqtt-bundle/nifi-mqtt-processors/src/test/java/org/apache/nifi/processors/mqtt/integration/TestConsumeMqttSSL.java#L74)
assuming that we would want to run all the same tests for wss as to ssl (and
similarly for ws as for tcp). Subclassing common/Test*MqttCommon as you suggest
won't remove this issue as I would essentially be reimplementing all the tests
and setup from TestConsumeMqttSSL. However I could subclass TestConsumeMqttSSL
-> TestConsumeMqttWss (for example) and pull the assigning of the broker out
into a method and just overwrite that in the subclass.

For the changes to MqttTestClient.java, they were autogenerated using
Intellij. I believe this is due to changes in the IMqttClient interface
referenced in the newer version of the Paho dependancy (1.1.1 from 1.0.2). Is
it good practice to leave these as are? It does feel unnecessary to have all
the comments there given they are only implemented to make a stub (or mock? I'm
never sure exactly which is which)

I'm still trying to get the -Pcontrib-check flag to work. I originally
ticked that box in the PR erroneously.

Hope this helps with the review and thanks again!
Seb

---

[jira] [Commented] (NIFI-4326) ExtractEmailHeaders.java unhandled Exceptions


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

ASF GitHub Bot commented on NIFI-4326:
--

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

https://github.com/apache/nifi/pull/2111#discussion_r139775977
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ExtractEmailHeaders.java
 ---
@@ -103,6 +102,21 @@
 .defaultValue("x-mailer")
 .build();
 
+private static final String STRICT_ADDRESSING_DEFAULT_VALUE = "true";
+public static final PropertyDescriptor STRICT_ADDRESSING = new 
PropertyDescriptor.Builder()
+.name("STRICT_ADDRESS_PARSING")
+.displayName("Use Strict Address Parsing")
+.description("If true, strict address format parsing rules are 
applied to mailbox and mailbox list fields, " +
+"such as \"to\" and \"from\" headers, and FlowFiles 
with poorly formed addresses will be routed " +
+"to the failure relationship, similar to messages that 
fail RFC compliant format validation. " +
+"If false, the processor will extract the contents of 
mailbox list headers as comma-separated " +
+"values without attempting to parse each value as 
well-formed Internet mailbox addresses. " +
+"This is optional and defaults to " + 
STRICT_ADDRESSING_DEFAULT_VALUE)
+.required(false)
+.defaultValue(STRICT_ADDRESSING_DEFAULT_VALUE)
+.allowableValues("true", "false")
--- End diff --

No worries! Will do, thanks!


> ExtractEmailHeaders.java unhandled Exceptions
> -
>
> Key: NIFI-4326
> URL: https://issues.apache.org/jira/browse/NIFI-4326
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
> Environment: jdk 1.8.0_121-b13
> openjdk 8u131-b11
>Reporter: Benjamin Wood
>Assignee: Benjamin Wood
>Priority: Minor
> Fix For: 1.4.0
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The ExtractEmailHeaders  processor throws a NullPointerException if there is 
> no TO, CC, and BCC recipients.
> If there are no recipients "originalMessage.getAllRecipients()" returns NULL, 
> and not a 0 length array.
> If an address is empty (<> or " ") then getRecipients() will throw an "Empty 
> Address" AddressException



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2111: NIFI-4326 - ExtractEmailHeaders.java unhandled Null...

2017-09-19 Thread kevdoran

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

https://github.com/apache/nifi/pull/2111#discussion_r139775977
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ExtractEmailHeaders.java
 ---
@@ -103,6 +102,21 @@
 .defaultValue("x-mailer")
 .build();
 
+private static final String STRICT_ADDRESSING_DEFAULT_VALUE = "true";
+public static final PropertyDescriptor STRICT_ADDRESSING = new 
PropertyDescriptor.Builder()
+.name("STRICT_ADDRESS_PARSING")
+.displayName("Use Strict Address Parsing")
+.description("If true, strict address format parsing rules are 
applied to mailbox and mailbox list fields, " +
+"such as \"to\" and \"from\" headers, and FlowFiles 
with poorly formed addresses will be routed " +
+"to the failure relationship, similar to messages that 
fail RFC compliant format validation. " +
+"If false, the processor will extract the contents of 
mailbox list headers as comma-separated " +
+"values without attempting to parse each value as 
well-formed Internet mailbox addresses. " +
+"This is optional and defaults to " + 
STRICT_ADDRESSING_DEFAULT_VALUE)
+.required(false)
+.defaultValue(STRICT_ADDRESSING_DEFAULT_VALUE)
+.allowableValues("true", "false")
--- End diff --

No worries! Will do, thanks!


---

[jira] [Commented] (NIFI-4326) ExtractEmailHeaders.java unhandled Exceptions


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

ASF GitHub Bot commented on NIFI-4326:
--

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

https://github.com/apache/nifi/pull/2111#discussion_r139775788
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ExtractEmailHeaders.java
 ---
@@ -103,6 +102,21 @@
 .defaultValue("x-mailer")
 .build();
 
+private static final String STRICT_ADDRESSING_DEFAULT_VALUE = "true";
+public static final PropertyDescriptor STRICT_ADDRESSING = new 
PropertyDescriptor.Builder()
+.name("STRICT_ADDRESS_PARSING")
+.displayName("Use Strict Address Parsing")
+.description("If true, strict address format parsing rules are 
applied to mailbox and mailbox list fields, " +
+"such as \"to\" and \"from\" headers, and FlowFiles 
with poorly formed addresses will be routed " +
+"to the failure relationship, similar to messages that 
fail RFC compliant format validation. " +
+"If false, the processor will extract the contents of 
mailbox list headers as comma-separated " +
+"values without attempting to parse each value as 
well-formed Internet mailbox addresses. " +
+"This is optional and defaults to " + 
STRICT_ADDRESSING_DEFAULT_VALUE)
+.required(false)
+.defaultValue(STRICT_ADDRESSING_DEFAULT_VALUE)
+.allowableValues("true", "false")
--- End diff --

Sorry forgot about that. I had the "office plague" (flu) last week. I'll 
commit again very soon, and you can re-review.


> ExtractEmailHeaders.java unhandled Exceptions
> -
>
> Key: NIFI-4326
> URL: https://issues.apache.org/jira/browse/NIFI-4326
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
> Environment: jdk 1.8.0_121-b13
> openjdk 8u131-b11
>Reporter: Benjamin Wood
>Assignee: Benjamin Wood
>Priority: Minor
> Fix For: 1.4.0
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The ExtractEmailHeaders  processor throws a NullPointerException if there is 
> no TO, CC, and BCC recipients.
> If there are no recipients "originalMessage.getAllRecipients()" returns NULL, 
> and not a 0 length array.
> If an address is empty (<> or " ") then getRecipients() will throw an "Empty 
> Address" AddressException



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2111: NIFI-4326 - ExtractEmailHeaders.java unhandled Null...

2017-09-19 Thread btwood

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

https://github.com/apache/nifi/pull/2111#discussion_r139775788
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ExtractEmailHeaders.java
 ---
@@ -103,6 +102,21 @@
 .defaultValue("x-mailer")
 .build();
 
+private static final String STRICT_ADDRESSING_DEFAULT_VALUE = "true";
+public static final PropertyDescriptor STRICT_ADDRESSING = new 
PropertyDescriptor.Builder()
+.name("STRICT_ADDRESS_PARSING")
+.displayName("Use Strict Address Parsing")
+.description("If true, strict address format parsing rules are 
applied to mailbox and mailbox list fields, " +
+"such as \"to\" and \"from\" headers, and FlowFiles 
with poorly formed addresses will be routed " +
+"to the failure relationship, similar to messages that 
fail RFC compliant format validation. " +
+"If false, the processor will extract the contents of 
mailbox list headers as comma-separated " +
+"values without attempting to parse each value as 
well-formed Internet mailbox addresses. " +
+"This is optional and defaults to " + 
STRICT_ADDRESSING_DEFAULT_VALUE)
+.required(false)
+.defaultValue(STRICT_ADDRESSING_DEFAULT_VALUE)
+.allowableValues("true", "false")
--- End diff --

Sorry forgot about that. I had the "office plague" (flu) last week. I'll 
commit again very soon, and you can re-review.


---

[jira] [Commented] (MINIFICPP-72) Add tar and compression support for MergeContent


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

Aldrin Piri commented on MINIFICPP-72:
--

Hey [~bqiu]

Looks like this could also be involved with/more appropriate for a 
CompressContent processor.  Could you outline what you propose covering with 
these enhancements to merge content?

> Add tar and compression support for MergeContent
> 
>
> Key: MINIFICPP-72
> URL: https://issues.apache.org/jira/browse/MINIFICPP-72
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Affects Versions: 1.0.0
>Reporter: bqiu
> Fix For: 1.0.0
>
>
> Add tar and compression support for MergeContent
> will use the https://www.libarchive.org



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (MINIFICPP-42) Create separate C++ issue tracker and migrate issues


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

Aldrin Piri commented on MINIFICPP-42:
--

Will migrate the remainder of the C++ issues but want to first have the 
MINIFICPP JIRA converted to the appropriate workflow.  That request is 
available here https://issues.apache.org/jira/browse/INFRA-15118

The general logistics of the move are as follows.  All C++ component issues and 
those with a cpp-* fix version prefix have been/will be migrated to the 
MINIFICPP project.

I have created versions in the MINIFICPP project without the "cpp-" prefix and 
map these versions upon the Bulk operation in JIRA.  JIRA handles the linking 
of old MINIFI issues to the new MINIFICPP issues.  

> Create separate C++ issue tracker and migrate issues
> 
>
> Key: MINIFICPP-42
> URL: https://issues.apache.org/jira/browse/MINIFICPP-42
> Project: NiFi MiNiFi C++
>  Issue Type: Task
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
>
> As per mailing list discussion, a separate issue tracker for the C++ project 
> seems like it would be helpful for maintaining dev efforts.
> Associated conversation located here: 
> https://lists.apache.org/thread.html/3d66e0091040fd0a1025158fef817f45eea7f4aa3ee3ef4cff5d230b@%3Cdev.nifi.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Moved] (MINIFICPP-91) Move docs into a separate module.


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

Aldrin Piri moved MINIFI-306 to MINIFICPP-91:
-

Fix Version/s: (was: cpp-0.3.0)
   0.3.0
  Component/s: (was: C++)
 Workflow: jira  (was: patch-available, re-open possible)
  Key: MINIFICPP-91  (was: MINIFI-306)
  Project: NiFi MiNiFi C++  (was: Apache NiFi MiNiFi)

> Move docs into a separate module. 
> --
>
> Key: MINIFICPP-91
> URL: https://issues.apache.org/jira/browse/MINIFICPP-91
> Project: NiFi MiNiFi C++
>  Issue Type: Sub-task
>Reporter: marco polo
>Assignee: marco polo
> Fix For: 0.3.0
>
>
> MINIFI-304 will move tests into a separate cmake module. we can move docs 
> into a separate cmake module to clean up the cmake file a bit. 



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (NIFI-4398) FlattenRecord Processor

2017-09-19 Thread Nicholas Hughes (JIRA)

Nicholas Hughes created NIFI-4398:
-

 Summary: FlattenRecord Processor
 Key: NIFI-4398
 URL: https://issues.apache.org/jira/browse/NIFI-4398
 Project: Apache NiFi
  Issue Type: New Feature
Reporter: Nicholas Hughes


Requesting a "FlattenRecord" processor, which performs much like the "Field 
Flattener" processor included in StreamSets Data Collector [2]

This should be able to act on all supported record types, and would take nested 
data and bring it out to the top level of the record by adding a prefix to the 
property name (or potentially other strategies).

The easiest way to demonstrate the desired effect is with the following JSON 
example. For input data like that shown below from Yahoo [1]

 {
   "query": {
 "count": 1,
 "created": "2017-09-15T11:20:26Z",
 "lang": "en-US",
 "results": {
   "channel": {
 "item": {
   "condition": { 
 "code": "33",
 "date": "Fri, 15 Sep 2017 06:00 AM EDT",
 "temp": "63",
 "text": "Mostly Clear"
   }
 }
   }
 }
   }
 }

...we'd end up with output something like this:

 {
   "query.count": 1,
   "query.created": "2017-09-15T11:20:26Z",
   "query.lang": "en-US",
   "query.results.channel.item.condition.code": "33",
   "query.results.channel.item.condition.date": "Fri, 15 Sep 2017 06:00 AM EDT",
   "query.results.channel.item.condition.temp": "63",
   "query.results.channel.item.condition.text": "Mostly Clear"
 }


[1] 
https://query.yahooapis.com/v1/public/yql?q=select%20item.condition%20from%20weather.forecast%20where%20woeid%20%3D%202383558=json=store%3A%2F%2Fdatatables.org%2Falltableswithkeys

[2] 
https://github.com/streamsets/datacollector/tree/master/basic-lib/src/main/java/com/streamsets/pipeline/stage/processor/fieldflattener



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Resolved] (NIFI-4394) gRPC processor (Listen) CPU usage while listening processor is started

2017-09-19 Thread Michael Hogue (JIRA)


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

Michael Hogue resolved NIFI-4394.
-
   Resolution: Fixed
Fix Version/s: 1.4.0

> gRPC processor (Listen) CPU usage while listening processor is started
> --
>
> Key: NIFI-4394
> URL: https://issues.apache.org/jira/browse/NIFI-4394
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
> Environment: All
>Reporter: Sébastien Bouchex Bellomié
>Priority: Minor
> Fix For: 1.4.0
>
>
> * Create a gRPC (ListenGRPC) processor in the interface
> * Start the processor
> * Check the CPU usage on the machine
> Problem : CPU usage is high



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4394) gRPC processor (Listen) CPU usage while listening processor is started

2017-09-19 Thread ASF subversion and git services (JIRA)


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

ASF GitHub Bot commented on NIFI-4394:
--

Github user asfgit closed the pull request at:

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


> gRPC processor (Listen) CPU usage while listening processor is started
> --
>
> Key: NIFI-4394
> URL: https://issues.apache.org/jira/browse/NIFI-4394
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
> Environment: All
>Reporter: Sébastien Bouchex Bellomié
>Priority: Minor
>
> * Create a gRPC (ListenGRPC) processor in the interface
> * Start the processor
> * Check the CPU usage on the machine
> Problem : CPU usage is high



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4394) gRPC processor (Listen) CPU usage while listening processor is started


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

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

Commit 2ee21b9255f8188b2843314e7fc0bcd0e7bb7bb8 in nifi's branch 
refs/heads/master from [~sbouc...@infovista.com]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=2ee21b9 ]

NIFI-4394 Fixed CPU issue - gRPC

Signed-off-by: Pierre Villard 

This closes #2163.


> gRPC processor (Listen) CPU usage while listening processor is started
> --
>
> Key: NIFI-4394
> URL: https://issues.apache.org/jira/browse/NIFI-4394
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
> Environment: All
>Reporter: Sébastien Bouchex Bellomié
>Priority: Minor
>
> * Create a gRPC (ListenGRPC) processor in the interface
> * Start the processor
> * Check the CPU usage on the machine
> Problem : CPU usage is high



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2163: NIFI-4394 Fixed CPU issue in gRPC (Listen) processo...

2017-09-19 Thread asfgit

Github user asfgit closed the pull request at:

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


---

[jira] [Commented] (NIFI-4394) gRPC processor (Listen) CPU usage while listening processor is started


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

ASF GitHub Bot commented on NIFI-4394:
--

Github user m-hogue commented on the issue:

https://github.com/apache/nifi/pull/2163
  
LGTM. I definitely missed this when i added this. Thanks!


> gRPC processor (Listen) CPU usage while listening processor is started
> --
>
> Key: NIFI-4394
> URL: https://issues.apache.org/jira/browse/NIFI-4394
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.4.0
> Environment: All
>Reporter: Sébastien Bouchex Bellomié
>Priority: Minor
>
> * Create a gRPC (ListenGRPC) processor in the interface
> * Start the processor
> * Check the CPU usage on the machine
> Problem : CPU usage is high



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #2163: NIFI-4394 Fixed CPU issue in gRPC (Listen) processor

2017-09-19 Thread m-hogue

Github user m-hogue commented on the issue:

https://github.com/apache/nifi/pull/2163
  
LGTM. I definitely missed this when i added this. Thanks!


---

[jira] [Created] (NIFI-4397) PutElasticsearchHttp Processor: Elasticsearch URL property isn't expanding nifi language expressions

2017-09-19 Thread Joe Warner (JIRA)

Joe Warner created NIFI-4397:


 Summary: PutElasticsearchHttp Processor: Elasticsearch URL 
property isn't expanding nifi language expressions
 Key: NIFI-4397
 URL: https://issues.apache.org/jira/browse/NIFI-4397
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.3.0
Reporter: Joe Warner
Priority: Minor


Despite the documentation saying that the PutElasticsearchHttp processor should 
support expression language this isn't happening. The Index property works 
correctly however. The property validates whether the value looks like a URL. 
But it seems like this validation is taking place before the expression is 
evaluated. Also, expressions like 'http://${url}' still are not evaluated.

Technically I guess this isn't a 'major' issue, but it is quite painful to use 
it without the replacement happening. See also NIFI-4396 which is very similar 
behaviour.




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFI-4326) ExtractEmailHeaders.java unhandled Exceptions


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

ASF GitHub Bot commented on NIFI-4326:
--

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

https://github.com/apache/nifi/pull/2111#discussion_r139724038
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ExtractEmailHeaders.java
 ---
@@ -103,6 +102,21 @@
 .defaultValue("x-mailer")
 .build();
 
+private static final String STRICT_ADDRESSING_DEFAULT_VALUE = "true";
+public static final PropertyDescriptor STRICT_ADDRESSING = new 
PropertyDescriptor.Builder()
+.name("STRICT_ADDRESS_PARSING")
+.displayName("Use Strict Address Parsing")
+.description("If true, strict address format parsing rules are 
applied to mailbox and mailbox list fields, " +
+"such as \"to\" and \"from\" headers, and FlowFiles 
with poorly formed addresses will be routed " +
+"to the failure relationship, similar to messages that 
fail RFC compliant format validation. " +
+"If false, the processor will extract the contents of 
mailbox list headers as comma-separated " +
+"values without attempting to parse each value as 
well-formed Internet mailbox addresses. " +
+"This is optional and defaults to " + 
STRICT_ADDRESSING_DEFAULT_VALUE)
+.required(false)
+.defaultValue(STRICT_ADDRESSING_DEFAULT_VALUE)
+.allowableValues("true", "false")
--- End diff --

I would change this to use the "AllowableValue" class and move some of the 
description of "true" vs. "false" behavior from the description field into each 
value. Here is an example: 
https://github.com/apache/nifi/pull/2148/files#diff-4f399a5e493f124a256ae2740c20f839
 


> ExtractEmailHeaders.java unhandled Exceptions
> -
>
> Key: NIFI-4326
> URL: https://issues.apache.org/jira/browse/NIFI-4326
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.3.0
> Environment: jdk 1.8.0_121-b13
> openjdk 8u131-b11
>Reporter: Benjamin Wood
>Assignee: Benjamin Wood
>Priority: Minor
> Fix For: 1.4.0
>
>   Original Estimate: 0.5h
>  Remaining Estimate: 0.5h
>
> The ExtractEmailHeaders  processor throws a NullPointerException if there is 
> no TO, CC, and BCC recipients.
> If there are no recipients "originalMessage.getAllRecipients()" returns NULL, 
> and not a 0 length array.
> If an address is empty (<> or " ") then getRecipients() will throw an "Empty 
> Address" AddressException



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi pull request #2111: NIFI-4326 - ExtractEmailHeaders.java unhandled Null...

2017-09-19 Thread kevdoran

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

https://github.com/apache/nifi/pull/2111#discussion_r139724038
  
--- Diff: 
nifi-nar-bundles/nifi-email-bundle/nifi-email-processors/src/main/java/org/apache/nifi/processors/email/ExtractEmailHeaders.java
 ---
@@ -103,6 +102,21 @@
 .defaultValue("x-mailer")
 .build();
 
+private static final String STRICT_ADDRESSING_DEFAULT_VALUE = "true";
+public static final PropertyDescriptor STRICT_ADDRESSING = new 
PropertyDescriptor.Builder()
+.name("STRICT_ADDRESS_PARSING")
+.displayName("Use Strict Address Parsing")
+.description("If true, strict address format parsing rules are 
applied to mailbox and mailbox list fields, " +
+"such as \"to\" and \"from\" headers, and FlowFiles 
with poorly formed addresses will be routed " +
+"to the failure relationship, similar to messages that 
fail RFC compliant format validation. " +
+"If false, the processor will extract the contents of 
mailbox list headers as comma-separated " +
+"values without attempting to parse each value as 
well-formed Internet mailbox addresses. " +
+"This is optional and defaults to " + 
STRICT_ADDRESSING_DEFAULT_VALUE)
+.required(false)
+.defaultValue(STRICT_ADDRESSING_DEFAULT_VALUE)
+.allowableValues("true", "false")
--- End diff --

I would change this to use the "AllowableValue" class and move some of the 
description of "true" vs. "false" behavior from the description field into each 
value. Here is an example: 
https://github.com/apache/nifi/pull/2148/files#diff-4f399a5e493f124a256ae2740c20f839
 


---

[jira] [Created] (NIFI-4396) PutElasticsearchHttp Processor: Type property isn't expanding nifi language expressions

2017-09-19 Thread Joe Warner (JIRA)

Joe Warner created NIFI-4396:


 Summary: PutElasticsearchHttp Processor: Type property isn't 
expanding nifi language expressions
 Key: NIFI-4396
 URL: https://issues.apache.org/jira/browse/NIFI-4396
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.3.0
Reporter: Joe Warner
Priority: Minor


Despite the documentation saying that the PutElasticsearchHttp processor should 
support expression language this isn't happening. The Index property works 
correctly however. Looking the source I notice that these two properties use 
different validators and wonder if the issue could be related.

Technically I guess this isn't a 'major' issue, but it is quite painful to use 
it without the replacement happening.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Created] (MINIFICPP-72) Add tar and compression support for MergeContent

2017-09-19 Thread bqiu (JIRA)

bqiu created MINIFICPP-72:
-

 Summary: Add tar and compression support for MergeContent
 Key: MINIFICPP-72
 URL: https://issues.apache.org/jira/browse/MINIFICPP-72
 Project: NiFi MiNiFi C++
  Issue Type: New Feature
Affects Versions: 1.0.0
Reporter: bqiu
 Fix For: 1.0.0


Add tar and compression support for MergeContent
will use the https://www.libarchive.org




--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Assigned] (MINIFICPP-42) Create separate C++ issue tracker and migrate issues


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

Aldrin Piri reassigned MINIFICPP-42:


Assignee: Aldrin Piri

> Create separate C++ issue tracker and migrate issues
> 
>
> Key: MINIFICPP-42
> URL: https://issues.apache.org/jira/browse/MINIFICPP-42
> Project: NiFi MiNiFi C++
>  Issue Type: Task
>Reporter: Aldrin Piri
>Assignee: Aldrin Piri
>
> As per mailing list discussion, a separate issue tracker for the C++ project 
> seems like it would be helpful for maintaining dev efforts.
> Associated conversation located here: 
> https://lists.apache.org/thread.html/3d66e0091040fd0a1025158fef817f45eea7f4aa3ee3ef4cff5d230b@%3Cdev.nifi.apache.org%3E



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[jira] [Commented] (NIFIREG-18) Refactor MetadataProvider to use an embedded database


[ 
https://issues.apache.org/jira/browse/NIFIREG-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16171776#comment-16171776
 ] 

ASF GitHub Bot commented on NIFIREG-18:
---

GitHub user bbende opened a pull request:

https://github.com/apache/nifi-registry/pull/10

NIFIREG-18 Refactor MetadataProvider to use an embedded database

- Initial plumbing for H2 database
- Setup Flyway with initial migration to define tables
- Setup entity classes with repositories
- Setup unit testing for repositories
- Removed existing MetadataProvider concept
- Removed provider impl module and moved remaining pieces into framework
- Added MetadataService with DatabaseMetadataService implementation
- Refactored RegistryService to use MetadataService
- Introduced verbose flag on some end-points to control loading nested 
objects
- Added ability to pass down paging/sorting params
- Added endpoints for available fields
- Adding ItemResource and ability to retrieve all items, or items by bucket
- Changing from Set to List on retrieval methods

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

$ git pull https://github.com/bbende/nifi-registry NIFIREG-18

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

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


commit 8f394bd73bf9a077b5b41ce897015daadac7
Author: Bryan Bende 
Date:   2017-09-19T14:01:24Z

NIFIREG-18 Initial plumbling for H2 database
- Setup Flyway with initial migration to define tables
- Setup entity classes with repositories
- Setup unit testing for repositories
- Removed existing MetadataProvider concept
- Removed provider impl module and moved remaining pieces into framework
- Added MetadataService with DatabaseMetadataService implementation
- Refactored RegistryService to use MetadataService
- Introduced verbose flag on some end-points to control loading nested 
objects
- Added ability to pass down paging/sorting params
- Added endpoints for available fields
- Adding ItemResource and ability to retrieve all items, or items by bucket
- Changing from Set to List on retrieval methods




> Refactor MetadataProvider to use an embedded database
> -
>
> Key: NIFIREG-18
> URL: https://issues.apache.org/jira/browse/NIFIREG-18
> Project: NiFi Registry
>  Issue Type: Improvement
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
>
> We need to leverage transactions when persisting data to avoid inconsistent 
> states. Currently the MetadataProvider is based on an XML file which doesn't 
> offer much way to rollback an operation. We should switch to using an 
> embedded database.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-registry pull request #10: NIFIREG-18 Refactor MetadataProvider to use ...

2017-09-19 Thread bbende

GitHub user bbende opened a pull request:

https://github.com/apache/nifi-registry/pull/10

NIFIREG-18 Refactor MetadataProvider to use an embedded database

- Initial plumbing for H2 database
- Setup Flyway with initial migration to define tables
- Setup entity classes with repositories
- Setup unit testing for repositories
- Removed existing MetadataProvider concept
- Removed provider impl module and moved remaining pieces into framework
- Added MetadataService with DatabaseMetadataService implementation
- Refactored RegistryService to use MetadataService
- Introduced verbose flag on some end-points to control loading nested 
objects
- Added ability to pass down paging/sorting params
- Added endpoints for available fields
- Adding ItemResource and ability to retrieve all items, or items by bucket
- Changing from Set to List on retrieval methods

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

$ git pull https://github.com/bbende/nifi-registry NIFIREG-18

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

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


commit 8f394bd73bf9a077b5b41ce897015daadac7
Author: Bryan Bende 
Date:   2017-09-19T14:01:24Z

NIFIREG-18 Initial plumbling for H2 database
- Setup Flyway with initial migration to define tables
- Setup entity classes with repositories
- Setup unit testing for repositories
- Removed existing MetadataProvider concept
- Removed provider impl module and moved remaining pieces into framework
- Added MetadataService with DatabaseMetadataService implementation
- Refactored RegistryService to use MetadataService
- Introduced verbose flag on some end-points to control loading nested 
objects
- Added ability to pass down paging/sorting params
- Added endpoints for available fields
- Adding ItemResource and ability to retrieve all items, or items by bucket
- Changing from Set to List on retrieval methods




---

[jira] [Commented] (MINIFICPP-36) Begin building controlling API to facilitate control of agents


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

ASF GitHub Bot commented on MINIFICPP-36:
-

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

https://github.com/apache/nifi-minifi-cpp/pull/134#discussion_r139702066
  
--- Diff: libminifi/include/core/Processor.h ---
@@ -153,7 +154,8 @@ class Processor : public Connectable, public 
ConfigurableComponent, public std::
   }
   // decrement Active Task Counts
   void decrementActiveTask(void) {
-active_tasks_--;
+if (active_tasks_ > 0)
+  active_tasks_--;
--- End diff --

Since the input ( stop command for example ) is user provided, this is only 
a protection. Decrement only occurs when an exception occurs during on trigger. 
If this happens just after unschedule occurs ( and the active tasks is set to 0 
) then we could arrive at -1. I didn't want to impose additional locking. 

Not ideal, and this can be solved more elegantly by not decrementing active 
tasks during an exception since the number isn't currently important ( just 
that tasks > 0 )...but I did not want to make additional changes here. 


> Begin building controlling API to facilitate control of agents
> --
>
> Key: MINIFICPP-36
> URL: https://issues.apache.org/jira/browse/MINIFICPP-36
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: marco polo
>Assignee: marco polo
>Priority: Critical
>  Labels: Durability, Reliability, Statistics
>
> Begin building the controlling API in MiNiFi C++. This API will evolve and 
> likely have public and private elements. As development progresses we may 
> want more capabilities. 
> What I want to create as a straw man will be basic control and metrics 
> gathering
> -- Start
> -- Stop
> -- Pause
> -- Gather metrics
>** Throughput of of flow components
>** Execution time ( run time minus sleep time )
>** Memory consumption
> -- Drain repositories
> -- Switch repository types. 
> Better employ update listener within this controlling API



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-minifi-cpp pull request #134: MINIFI-339: Add C2 base allowing for 1 pr...

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

https://github.com/apache/nifi-minifi-cpp/pull/134#discussion_r139702066
  
--- Diff: libminifi/include/core/Processor.h ---
@@ -153,7 +154,8 @@ class Processor : public Connectable, public 
ConfigurableComponent, public std::
   }
   // decrement Active Task Counts
   void decrementActiveTask(void) {
-active_tasks_--;
+if (active_tasks_ > 0)
+  active_tasks_--;
--- End diff --

Since the input ( stop command for example ) is user provided, this is only 
a protection. Decrement only occurs when an exception occurs during on trigger. 
If this happens just after unschedule occurs ( and the active tasks is set to 0 
) then we could arrive at -1. I didn't want to impose additional locking. 

Not ideal, and this can be solved more elegantly by not decrementing active 
tasks during an exception since the number isn't currently important ( just 
that tasks > 0 )...but I did not want to make additional changes here. 


---

[jira] [Updated] (NIFI-4395) GnerateTableFetch can't fetch column type by state through instance reboot


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

Deon Huang updated NIFI-4395:
-
Description: 
The problem can easily be reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.

---
if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
}
---

When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

---
if (!isDynamicTableName && !isDynamicMaxValues) {
super.setup(context);
}
---

I can take the issue if it is recognize as bug.

  was:
The problem can easily be reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.

if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
}


When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

if (!isDynamicTableName && !isDynamicMaxValues) {
super.setup(context);
}

I can take the issue if it is recognize as bug.


> GnerateTableFetch can't fetch column type by state through instance reboot
> --
>
> Key: NIFI-4395
> URL: https://issues.apache.org/jira/browse/NIFI-4395
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Deon Huang
> Fix For: 1.4.0
>
> Attachments: GenerateTableFetch_Exception.png
>
>
> The problem can easily be reproduce.
> Once GenerateTableFetch store state and encounter NiFi instance reboot.
> (Dynamic naming table by expression language)
> The exception will occur.
> The error in source code is list below.
> ---
> if (type == null) {
> // This shouldn't happen as we are populating columnTypeMap when the 
> processor is scheduled or when the first maximum is observed
> throw new IllegalArgumentException("No column type found for: " + 
> colName);
> }
> ---
> When this situation happened. The FlowFile will also be grab and can't 
> release or observed.
> Processor can't existing grab column type from columnTypeMap through instance 
> reboot.
> Hence will inevidible get this exception, rollback FlowFile and never success.
> QueryDatabaseTable processor will not encounter this exception due to it 
> setup(context) every time,
> While GenerateTableFetch will not pass the condition and thus try to fetch 
> column type from 0 length columnTypeMap.
> ---
> if (!isDynamicTableName && !isDynamicMaxValues) {
> super.setup(context);
> }
> ---
> I can take the issue if it is recognize as bug.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-minifi-cpp pull request #134: MINIFI-339: Add C2 base allowing for 1 pr...

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

https://github.com/apache/nifi-minifi-cpp/pull/134#discussion_r139699391
  
--- Diff: libminifi/include/c2/C2Payload.h ---
@@ -0,0 +1,187 @@
+/**
+ *
+ * Licensed to the Apache Software Foundation (ASF) under one or more
+ * contributor license agreements.  See the NOTICE file distributed with
+ * this work for additional information regarding copyright ownership.
+ * The ASF licenses this file to You under the Apache License, Version 2.0
+ * (the "License"); you may not use this file except in compliance with
+ * the License.  You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+#ifndef LIBMINIFI_INCLUDE_C2_C2PAYLOAD_H_
+#define LIBMINIFI_INCLUDE_C2_C2PAYLOAD_H_
+
+#include 
+#include 
+#include 
+#include "core/state/UpdateController.h"
+
+namespace org {
+namespace apache {
+namespace nifi {
+namespace minifi {
+namespace c2 {
+
+enum Operation {
+  ACKNOWLEDGE,
+  START,
+  STOP,
+  RESTART,
+  DESCRIBE,
+  HEARTBEAT,
+  UPDATE,
+  VALIDATE,
+  CLEAR
+};
+
+enum Direction {
+  TRANSMIT,
+  RECEIVE
+};
+
+class C2ContentResponse {
+ public:
+  C2ContentResponse(Operation op);
+
+  C2ContentResponse(const C2ContentResponse );
+
+  C2ContentResponse(const C2ContentResponse &);
+
+  C2ContentResponse & operator=(const C2ContentResponse &);
+
+  C2ContentResponse & operator=(const C2ContentResponse );
+
+  Operation op;
+  // determines if the operation is required
+  bool required;
+  // identifier
+  std::string ident;
+  // delay before running
+  uint32_t delay;
+  // max time before this response will no longer be honored.
+  uint64_t ttl;
+  // name applied to commands
+  std::string name;
+  // commands that correspond with the operation.
+  std::map operation_arguments;
+//  std::vector content;
+};
+
+/**
+ * C2Payload is an update for the state manager.
+ * Note that the payload can either consist of other payloads or
+ * have content directly within it, represented by C2ContentResponse 
objects, above.
+ *
+ * Payloads can also contain raw data, which can be binary data.
+ */
+class C2Payload : public state::Update {
+ public:
+  virtual ~C2Payload() {
+
+  }
+
+  C2Payload(Operation op, std::string identifier, bool resp = false, bool 
isRaw = false);
+
+  C2Payload(Operation op, bool resp = false, bool isRaw = false);
+
+  C2Payload(Operation op, state::UpdateState state, bool resp = false, 
bool isRaw = false);
+
+  C2Payload(const C2Payload );
+
+  C2Payload(const C2Payload &);
+
+  void setIdentifier(const std::string );
+
+  std::string getIdentifier() const;
+
+  void setLabel(const std::string label) {
+label_ = label;
+  }
+
+  std::string getLabel() const {
+return label_;
+  }
+
+  /**
+   * Gets the operation for this payload. May be nested or a single 
operation.
+   */
+  Operation getOperation() const;
+
+  /**
+   * Validate the payload, if necessary and/or possible.
+   */
+  virtual bool validate();
+
+  /**
+   * Get content responses from this payload.
+   */
+  const std::vector () const;
+
+  /**
+   * Add a content response to this payload.
+   */
+  void addContent(const C2ContentResponse &);
+
+  /**
+   * Determines if this object contains raw data.
+   */
+  bool isRaw() const;
+
+  /**
+   * Sets raw data within this object.
+   */
+  void setRawData(const std::string );
--- End diff --

A string contains raw bytes. It can be accessed with std::string::data. I 
don't know if there is really a fundamental difference between vector and 
std::string. Performance is negligible and a setRawData(vector data ) 
exists, so we don't impose a semantic that says you must use text, if the 
developer interprets the signature as such. 


---

[jira] [Updated] (NIFI-4395) GnerateTableFetch can't fetch column type by state through instance reboot


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

Deon Huang updated NIFI-4395:
-
Description: 
The problem can easily be reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.

if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
}


When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

if (!isDynamicTableName && !isDynamicMaxValues) {
super.setup(context);
}

I can take the issue if it is recognize as bug.

  was:
The problem can easily be reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.
```
if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
  }
```

When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

```
if (!isDynamicTableName && !isDynamicMaxValues) {
  super.setup(context);
  }
```

I can take the issue if it is recognize as bug.The problem can easily be 
reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.
```
if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
  }
```

When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

```
if (!isDynamicTableName && !isDynamicMaxValues) {
  super.setup(context);
  }
```

I can take the issue if it is recognize as bug.


> GnerateTableFetch can't fetch column type by state through instance reboot
> --
>
> Key: NIFI-4395
> URL: https://issues.apache.org/jira/browse/NIFI-4395
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.3.0
>Reporter: Deon Huang
> Fix For: 1.4.0
>
> Attachments: GenerateTableFetch_Exception.png
>
>
> The problem can easily be reproduce.
> Once GenerateTableFetch store state and encounter NiFi instance reboot.
> (Dynamic naming table by expression language)
> The exception will occur.
> The error in source code is list below.
> if (type == null) {
> // This shouldn't happen as we are populating columnTypeMap when the 
> processor is scheduled or when the first maximum is observed
> throw new IllegalArgumentException("No column type found for: " + 
> colName);
> }
> When this situation happened. The FlowFile will also be grab and can't 
> release or observed.
> Processor can't existing grab column type from columnTypeMap through instance 
> reboot.
> Hence will inevidible get this exception, rollback FlowFile and never success.
> QueryDatabaseTable processor will not encounter this exception due to it 
> setup(context) every time,
> While GenerateTableFetch will not pass the condition and thus try to fetch 
> column type from 0 length columnTypeMap.
> if (!isDynamicTableName && !isDynamicMaxValues) {
>

[jira] [Created] (NIFI-4395) GnerateTableFetch can't fetch column type by state through instance reboot

Deon Huang created NIFI-4395:


 Summary: GnerateTableFetch can't fetch column type by state 
through instance reboot
 Key: NIFI-4395
 URL: https://issues.apache.org/jira/browse/NIFI-4395
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.3.0
Reporter: Deon Huang
 Fix For: 1.4.0
 Attachments: GenerateTableFetch_Exception.png

The problem can easily be reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.
```
if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
  }
```

When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

```
if (!isDynamicTableName && !isDynamicMaxValues) {
  super.setup(context);
  }
```

I can take the issue if it is recognize as bug.The problem can easily be 
reproduce.
Once GenerateTableFetch store state and encounter NiFi instance reboot.
(Dynamic naming table by expression language)
The exception will occur.

The error in source code is list below.
```
if (type == null) {
// This shouldn't happen as we are populating columnTypeMap when the 
processor is scheduled or when the first maximum is observed
throw new IllegalArgumentException("No column type found for: " + colName);
  }
```

When this situation happened. The FlowFile will also be grab and can't release 
or observed.
Processor can't existing grab column type from columnTypeMap through instance 
reboot.
Hence will inevidible get this exception, rollback FlowFile and never success.

QueryDatabaseTable processor will not encounter this exception due to it 
setup(context) every time,
While GenerateTableFetch will not pass the condition and thus try to fetch 
column type from 0 length columnTypeMap.

```
if (!isDynamicTableName && !isDynamicMaxValues) {
  super.setup(context);
  }
```

I can take the issue if it is recognize as bug.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi-minifi-cpp pull request #134: MINIFI-339: Add C2 base allowing for 1 pr...

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

https://github.com/apache/nifi-minifi-cpp/pull/134#discussion_r139696520
  
--- Diff: libminifi/include/FlowController.h ---
@@ -158,7 +176,7 @@ class FlowController : public 
core::controller::ControllerServiceProvider, publi
   // first it will validate the payload with the current root node config 
for flowController
   // like FlowController id/name is the same and new version is greater 
than the current version
   // after that, it will apply the configuration
-  bool applyConfiguration(std::string );
+  bool applyConfiguration(const std::string );
--- End diff --

FlowConfiguratin should be sanitized of YAML related variable names. 
Unfortunately this was reintroduced in a recent PR. 


---

[GitHub] nifi-minifi-cpp pull request #134: MINIFI-339: Add C2 base allowing for 1 pr...

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

https://github.com/apache/nifi-minifi-cpp/pull/134#discussion_r139694071
  
--- Diff: libminifi/include/FlowController.h ---
@@ -124,14 +123,33 @@ class FlowController : public 
core::controller::ControllerServiceProvider, publi
   virtual bool isRunning() {
 return running_.load();
   }
+
   // Whether the Flow Controller has already been initialized (loaded flow 
XML)
   virtual bool isInitialized() {
 return initialized_.load();
   }
   // Start to run the Flow Controller which internally start the root 
process group and all its children
-  virtual bool start();
+  virtual int16_t start();
--- End diff --

I completely agree. I've created a ticket to track this: 
https://issues.apache.org/jira/browse/MINIFI-400 MINIFI-399 will encompass 
other structural changes that we can apply


---

[jira] [Commented] (NIFI-3688) Create extended groovy scripting processor


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

ASF GitHub Bot commented on NIFI-3688:
--

Github user dlukyanov commented on the issue:

https://github.com/apache/nifi/pull/1662
  
@mattyb149, do you have any comments to my last commit?


> Create extended groovy scripting processor
> --
>
> Key: NIFI-3688
> URL: https://issues.apache.org/jira/browse/NIFI-3688
> Project: Apache NiFi
>  Issue Type: New Feature
>  Components: Extensions
>Reporter: Dmitry Lukyanov
>Priority: Minor
>
> The idea is to simplify groovy scripting.
> Main targets:
> - to be compatible with existing groovy scripting
> - simplify read/write attributes
> - simplify read/write content
> - avoid closure casting to nifi types like `StreamCallback`
> - simplify and provide visibility when accessing to controller services from 
> script



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

[GitHub] nifi issue #1662: NIFI-3688 Extended Groovy Nifi Processor

2017-09-19 Thread dlukyanov

Github user dlukyanov commented on the issue:

https://github.com/apache/nifi/pull/1662
  
@mattyb149, do you have any comments to my last commit?


---

[jira] [Commented] (NIFI-4394) gRPC processor (Listen) CPU usage while listening processor is started