[jira] [Created] (NIFI-6134) InferAvroSchema does not honour Analysis sampling.

2019-03-19 Thread Steven Fister (JIRA)
Steven Fister created NIFI-6134:
---

 Summary: InferAvroSchema does not honour Analysis sampling.
 Key: NIFI-6134
 URL: https://issues.apache.org/jira/browse/NIFI-6134
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.9.0
 Environment: Windows
Reporter: Steven Fister
 Attachments: image-2019-03-20-18-04-50-595.png

When using the InferAvroSchema setting the inferred.avro.schema setting even 
when setting to 25 or 250 it still only samples 10 records.  In my sample I 
skip the first line which is a header that has blanks in it.  The module only 
samples the remaining 9 after the first line in skipped in the  CSV File.

!image-2019-03-20-18-04-50-595.png!



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


[jira] [Commented] (NIFI-5918) MergeRecord works wrong with Defragment strategy

2019-03-19 Thread ASF subversion and git services (JIRA)


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

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

Commit cd3567873be7586aa285bd6b27e928e320299bee in nifi's branch 
refs/heads/master from Koji Kawamura
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=cd35678 ]

NIFI-5918 Fix issue with MergeRecord when DefragmentStrategy is on

Added an unit test representing the fixed issue.
And updated existing testDefragment test to illustrate
the remaining FlowFiles those did not meet the threshold.


> MergeRecord works wrong with Defragment strategy
> 
>
> Key: NIFI-5918
> URL: https://issues.apache.org/jira/browse/NIFI-5918
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.8.0
>Reporter: Alexander Bukarev
>Assignee: Alexander Bukarev
>Priority: Major
> Attachments: NIFI-5918_MergeRecord.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *Steps*
> # Create the simple flow: 
> #* {{GenerateFlowFile}} (with constant payload "txt1,txt2" and 10 secs 
> schedulling) 
> #* -> {{SplitContent}} (with comma as a separator)
> #* -> some chain of processors which get "txt1" and "txt2" as a inbound 
> params and produce flowfiles with more than 1 record ((!) that's important). 
> For example, I use {{ExtractText}} (to get "txt1" and "txt2" as an 
> attribute), then {{ExecuteSQLRecord}} (to execute SQL using "txt1" and "txt2" 
> as a parameter)
> #* -> {{MergeRecord}} (with *Defragment* merge strategy - (!) that's 
> important)
> #* -> {{LogAttribute}} or whatever you prefer to observe the merge result
> # Now just run the flow
> *Result:* we'll see an error in logs like {panel}Could not merge bin with 1 
> FlowFiles because of the 'fragment.count' attribute had a value of '2' but 
> only 1 of 2 FlowFiles were encountered before this bin was evicted (due to to 
> Max Bin Age being reached or due to the Maximum Number of Bins being 
> exceeded).{panel}
> *Expected result:* the flow file containing records from both SQL queries 
> (for "txt1" and "txt2")
> The cause is {{RecordBinManager}} uses {{fragment.count}} flow file attribute 
> to calculate required *record* number to release the bin. However, the 
> attribute contains the number of *flow files* instead. As in above scenario 
> each file contains more than 1 records (at least 2) that means {{RecordBin}} 
> thinks the bin is "full enough" when first flow file arrives (because it 
> contains >= 2 records and {{fragment.count}} is equal to 2 in the scenario). 
> So the bin is released wrongly.
> I think there is a mistake and in *Defragment* mode we are interested in a 
> number of flow files and never in records number. In opposite, we should care 
> about a number of records usin Bin-Packaging Algorithm.



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


[jira] [Updated] (NIFI-5918) MergeRecord works wrong with Defragment strategy

2019-03-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura updated NIFI-5918:

   Resolution: Fixed
Fix Version/s: 1.10.0
   Status: Resolved  (was: Patch Available)

> MergeRecord works wrong with Defragment strategy
> 
>
> Key: NIFI-5918
> URL: https://issues.apache.org/jira/browse/NIFI-5918
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.8.0
>Reporter: Alexander Bukarev
>Assignee: Alexander Bukarev
>Priority: Major
> Fix For: 1.10.0
>
> Attachments: NIFI-5918_MergeRecord.xml
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> *Steps*
> # Create the simple flow: 
> #* {{GenerateFlowFile}} (with constant payload "txt1,txt2" and 10 secs 
> schedulling) 
> #* -> {{SplitContent}} (with comma as a separator)
> #* -> some chain of processors which get "txt1" and "txt2" as a inbound 
> params and produce flowfiles with more than 1 record ((!) that's important). 
> For example, I use {{ExtractText}} (to get "txt1" and "txt2" as an 
> attribute), then {{ExecuteSQLRecord}} (to execute SQL using "txt1" and "txt2" 
> as a parameter)
> #* -> {{MergeRecord}} (with *Defragment* merge strategy - (!) that's 
> important)
> #* -> {{LogAttribute}} or whatever you prefer to observe the merge result
> # Now just run the flow
> *Result:* we'll see an error in logs like {panel}Could not merge bin with 1 
> FlowFiles because of the 'fragment.count' attribute had a value of '2' but 
> only 1 of 2 FlowFiles were encountered before this bin was evicted (due to to 
> Max Bin Age being reached or due to the Maximum Number of Bins being 
> exceeded).{panel}
> *Expected result:* the flow file containing records from both SQL queries 
> (for "txt1" and "txt2")
> The cause is {{RecordBinManager}} uses {{fragment.count}} flow file attribute 
> to calculate required *record* number to release the bin. However, the 
> attribute contains the number of *flow files* instead. As in above scenario 
> each file contains more than 1 records (at least 2) that means {{RecordBin}} 
> thinks the bin is "full enough" when first flow file arrives (because it 
> contains >= 2 records and {{fragment.count}} is equal to 2 in the scenario). 
> So the bin is released wrongly.
> I think there is a mistake and in *Defragment* mode we are interested in a 
> number of flow files and never in records number. In opposite, we should care 
> about a number of records usin Bin-Packaging Algorithm.



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


[GitHub] [nifi] ijokarumawak commented on issue #3334: NIFI-5918 Fix issue with MergeRecord when DefragmentStrategy is on

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3334: NIFI-5918 Fix issue with MergeRecord 
when DefragmentStrategy is on
URL: https://github.com/apache/nifi/pull/3334#issuecomment-474672722
 
 
   I was able to reproduce the reported issue and confirmed the provided fix 
addresses it.
   I've added a unit test representing the issue.
   
https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/test/java/org/apache/nifi/processors/standard/TestMergeRecord.java#L211
   
   LGTM +1. Merged to master. Thanks again @andresgaragiola !


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (NIFI-5918) MergeRecord works wrong with Defragment strategy

2019-03-19 Thread ASF subversion and git services (JIRA)


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

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

Commit b97fbd2c89caafec4bde485c6118a6daa087fcb2 in nifi's branch 
refs/heads/master from Andres Garagiola
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=b97fbd2 ]

NIFI-5918 Fix issue with MergeRecord when DefragmentStrategy is on

This closes #3334.

Signed-off-by: Andres Garagiola 
Signed-off-by: Koji Kawamura 


> MergeRecord works wrong with Defragment strategy
> 
>
> Key: NIFI-5918
> URL: https://issues.apache.org/jira/browse/NIFI-5918
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.8.0
>Reporter: Alexander Bukarev
>Assignee: Alexander Bukarev
>Priority: Major
> Attachments: NIFI-5918_MergeRecord.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *Steps*
> # Create the simple flow: 
> #* {{GenerateFlowFile}} (with constant payload "txt1,txt2" and 10 secs 
> schedulling) 
> #* -> {{SplitContent}} (with comma as a separator)
> #* -> some chain of processors which get "txt1" and "txt2" as a inbound 
> params and produce flowfiles with more than 1 record ((!) that's important). 
> For example, I use {{ExtractText}} (to get "txt1" and "txt2" as an 
> attribute), then {{ExecuteSQLRecord}} (to execute SQL using "txt1" and "txt2" 
> as a parameter)
> #* -> {{MergeRecord}} (with *Defragment* merge strategy - (!) that's 
> important)
> #* -> {{LogAttribute}} or whatever you prefer to observe the merge result
> # Now just run the flow
> *Result:* we'll see an error in logs like {panel}Could not merge bin with 1 
> FlowFiles because of the 'fragment.count' attribute had a value of '2' but 
> only 1 of 2 FlowFiles were encountered before this bin was evicted (due to to 
> Max Bin Age being reached or due to the Maximum Number of Bins being 
> exceeded).{panel}
> *Expected result:* the flow file containing records from both SQL queries 
> (for "txt1" and "txt2")
> The cause is {{RecordBinManager}} uses {{fragment.count}} flow file attribute 
> to calculate required *record* number to release the bin. However, the 
> attribute contains the number of *flow files* instead. As in above scenario 
> each file contains more than 1 records (at least 2) that means {{RecordBin}} 
> thinks the bin is "full enough" when first flow file arrives (because it 
> contains >= 2 records and {{fragment.count}} is equal to 2 in the scenario). 
> So the bin is released wrongly.
> I think there is a mistake and in *Defragment* mode we are interested in a 
> number of flow files and never in records number. In opposite, we should care 
> about a number of records usin Bin-Packaging Algorithm.



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


[GitHub] [nifi] asfgit closed pull request #3334: NIFI-5918 Fix issue with MergeRecord when DefragmentStrategy is on

2019-03-19 Thread GitBox
asfgit closed pull request #3334: NIFI-5918 Fix issue with MergeRecord when 
DefragmentStrategy is on
URL: https://github.com/apache/nifi/pull/3334
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (NIFI-5918) MergeRecord works wrong with Defragment strategy

2019-03-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura updated NIFI-5918:

Status: Patch Available  (was: Open)

[~javajefe] Thanks for the PR. Next time, when you submit a PR, please click 
the 'Submit Patch' button on the Jira issue. That updates Jira status to 'Patch 
Available'.

> MergeRecord works wrong with Defragment strategy
> 
>
> Key: NIFI-5918
> URL: https://issues.apache.org/jira/browse/NIFI-5918
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.8.0
>Reporter: Alexander Bukarev
>Assignee: Alexander Bukarev
>Priority: Major
> Attachments: NIFI-5918_MergeRecord.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *Steps*
> # Create the simple flow: 
> #* {{GenerateFlowFile}} (with constant payload "txt1,txt2" and 10 secs 
> schedulling) 
> #* -> {{SplitContent}} (with comma as a separator)
> #* -> some chain of processors which get "txt1" and "txt2" as a inbound 
> params and produce flowfiles with more than 1 record ((!) that's important). 
> For example, I use {{ExtractText}} (to get "txt1" and "txt2" as an 
> attribute), then {{ExecuteSQLRecord}} (to execute SQL using "txt1" and "txt2" 
> as a parameter)
> #* -> {{MergeRecord}} (with *Defragment* merge strategy - (!) that's 
> important)
> #* -> {{LogAttribute}} or whatever you prefer to observe the merge result
> # Now just run the flow
> *Result:* we'll see an error in logs like {panel}Could not merge bin with 1 
> FlowFiles because of the 'fragment.count' attribute had a value of '2' but 
> only 1 of 2 FlowFiles were encountered before this bin was evicted (due to to 
> Max Bin Age being reached or due to the Maximum Number of Bins being 
> exceeded).{panel}
> *Expected result:* the flow file containing records from both SQL queries 
> (for "txt1" and "txt2")
> The cause is {{RecordBinManager}} uses {{fragment.count}} flow file attribute 
> to calculate required *record* number to release the bin. However, the 
> attribute contains the number of *flow files* instead. As in above scenario 
> each file contains more than 1 records (at least 2) that means {{RecordBin}} 
> thinks the bin is "full enough" when first flow file arrives (because it 
> contains >= 2 records and {{fragment.count}} is equal to 2 in the scenario). 
> So the bin is released wrongly.
> I think there is a mistake and in *Defragment* mode we are interested in a 
> number of flow files and never in records number. In opposite, we should care 
> about a number of records usin Bin-Packaging Algorithm.



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


[jira] [Updated] (NIFI-5918) MergeRecord works wrong with Defragment strategy

2019-03-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura updated NIFI-5918:

Attachment: NIFI-5918_MergeRecord.xml

> MergeRecord works wrong with Defragment strategy
> 
>
> Key: NIFI-5918
> URL: https://issues.apache.org/jira/browse/NIFI-5918
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.8.0
>Reporter: Alexander Bukarev
>Assignee: Alexander Bukarev
>Priority: Major
> Attachments: NIFI-5918_MergeRecord.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *Steps*
> # Create the simple flow: 
> #* {{GenerateFlowFile}} (with constant payload "txt1,txt2" and 10 secs 
> schedulling) 
> #* -> {{SplitContent}} (with comma as a separator)
> #* -> some chain of processors which get "txt1" and "txt2" as a inbound 
> params and produce flowfiles with more than 1 record ((!) that's important). 
> For example, I use {{ExtractText}} (to get "txt1" and "txt2" as an 
> attribute), then {{ExecuteSQLRecord}} (to execute SQL using "txt1" and "txt2" 
> as a parameter)
> #* -> {{MergeRecord}} (with *Defragment* merge strategy - (!) that's 
> important)
> #* -> {{LogAttribute}} or whatever you prefer to observe the merge result
> # Now just run the flow
> *Result:* we'll see an error in logs like {panel}Could not merge bin with 1 
> FlowFiles because of the 'fragment.count' attribute had a value of '2' but 
> only 1 of 2 FlowFiles were encountered before this bin was evicted (due to to 
> Max Bin Age being reached or due to the Maximum Number of Bins being 
> exceeded).{panel}
> *Expected result:* the flow file containing records from both SQL queries 
> (for "txt1" and "txt2")
> The cause is {{RecordBinManager}} uses {{fragment.count}} flow file attribute 
> to calculate required *record* number to release the bin. However, the 
> attribute contains the number of *flow files* instead. As in above scenario 
> each file contains more than 1 records (at least 2) that means {{RecordBin}} 
> thinks the bin is "full enough" when first flow file arrives (because it 
> contains >= 2 records and {{fragment.count}} is equal to 2 in the scenario). 
> So the bin is released wrongly.
> I think there is a mistake and in *Defragment* mode we are interested in a 
> number of flow files and never in records number. In opposite, we should care 
> about a number of records usin Bin-Packaging Algorithm.



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


[jira] [Commented] (NIFI-5918) MergeRecord works wrong with Defragment strategy

2019-03-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura commented on NIFI-5918:
-

Attached a template to reproduce the issue.

> MergeRecord works wrong with Defragment strategy
> 
>
> Key: NIFI-5918
> URL: https://issues.apache.org/jira/browse/NIFI-5918
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.8.0
>Reporter: Alexander Bukarev
>Assignee: Alexander Bukarev
>Priority: Major
> Attachments: NIFI-5918_MergeRecord.xml
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> *Steps*
> # Create the simple flow: 
> #* {{GenerateFlowFile}} (with constant payload "txt1,txt2" and 10 secs 
> schedulling) 
> #* -> {{SplitContent}} (with comma as a separator)
> #* -> some chain of processors which get "txt1" and "txt2" as a inbound 
> params and produce flowfiles with more than 1 record ((!) that's important). 
> For example, I use {{ExtractText}} (to get "txt1" and "txt2" as an 
> attribute), then {{ExecuteSQLRecord}} (to execute SQL using "txt1" and "txt2" 
> as a parameter)
> #* -> {{MergeRecord}} (with *Defragment* merge strategy - (!) that's 
> important)
> #* -> {{LogAttribute}} or whatever you prefer to observe the merge result
> # Now just run the flow
> *Result:* we'll see an error in logs like {panel}Could not merge bin with 1 
> FlowFiles because of the 'fragment.count' attribute had a value of '2' but 
> only 1 of 2 FlowFiles were encountered before this bin was evicted (due to to 
> Max Bin Age being reached or due to the Maximum Number of Bins being 
> exceeded).{panel}
> *Expected result:* the flow file containing records from both SQL queries 
> (for "txt1" and "txt2")
> The cause is {{RecordBinManager}} uses {{fragment.count}} flow file attribute 
> to calculate required *record* number to release the bin. However, the 
> attribute contains the number of *flow files* instead. As in above scenario 
> each file contains more than 1 records (at least 2) that means {{RecordBin}} 
> thinks the bin is "full enough" when first flow file arrives (because it 
> contains >= 2 records and {{fragment.count}} is equal to 2 in the scenario). 
> So the bin is released wrongly.
> I think there is a mistake and in *Defragment* mode we are interested in a 
> number of flow files and never in records number. In opposite, we should care 
> about a number of records usin Bin-Packaging Algorithm.



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


[jira] [Created] (NIFI-6133) minifi-docker module should depend on minifi-assembly

2019-03-19 Thread Aldrin Piri (JIRA)
Aldrin Piri created NIFI-6133:
-

 Summary: minifi-docker module should depend on minifi-assembly
 Key: NIFI-6133
 URL: https://issues.apache.org/jira/browse/NIFI-6133
 Project: Apache NiFi
  Issue Type: Bug
  Components: Docker, Tools and Build
Reporter: Aldrin Piri
 Fix For: 0.5.0


Currently the docker module does not depend on the assembly.  This means that 
for multhreaded builds there is a potential that the docker build will make use 
of what is a stale assembly.  Or, for a clean state, will not be able to build 
when activated.



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


[GitHub] [nifi] ijokarumawak commented on issue #3334: NIFI-5918 Fix issue with MergeRecord when DefragmentStrategy is on

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3334: NIFI-5918 Fix issue with MergeRecord 
when DefragmentStrategy is on
URL: https://github.com/apache/nifi/pull/3334#issuecomment-474653775
 
 
   Thanks @andresgaragiola for your contribution! I'm going to review it.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (NIFI-6120) nifi-toolkit should use use same nifi-registry version as nifi-framework

2019-03-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura updated NIFI-6120:

   Resolution: Fixed
Fix Version/s: 1.10.0
   Status: Resolved  (was: Patch Available)

> nifi-toolkit should use use same nifi-registry version as nifi-framework
> 
>
> Key: NIFI-6120
> URL: https://issues.apache.org/jira/browse/NIFI-6120
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
> Fix For: 1.10.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently the nifi-framework has a property for nifi.registry.version which 
> is set to 0.3.0, and nifi-toolkit also has dependencies on nifi-registry 
> modules, but has the version hard-coded to 0.2.0. These should be in sync so 
> that when we do a release they are using the same version.



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


[jira] [Commented] (NIFI-6120) nifi-toolkit should use use same nifi-registry version as nifi-framework

2019-03-19 Thread ASF subversion and git services (JIRA)


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

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

Commit 9d21a106ad6674ab4f12828b9dd007f28e5808f2 in nifi's branch 
refs/heads/master from Bryan Bende
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=9d21a10 ]

NIFI-6120 Move nifi.registry.version property to root pom so it can be shared 
between nifi-framework and nifi-toolkit

This closes #3369.

Signed-off-by: Koji Kawamura 


> nifi-toolkit should use use same nifi-registry version as nifi-framework
> 
>
> Key: NIFI-6120
> URL: https://issues.apache.org/jira/browse/NIFI-6120
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.8.0, 1.9.0
>Reporter: Bryan Bende
>Assignee: Bryan Bende
>Priority: Minor
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Currently the nifi-framework has a property for nifi.registry.version which 
> is set to 0.3.0, and nifi-toolkit also has dependencies on nifi-registry 
> modules, but has the version hard-coded to 0.2.0. These should be in sync so 
> that when we do a release they are using the same version.



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


[GitHub] [nifi] asfgit closed pull request #3369: NIFI-6120 Move nifi.registry.version property to root pom so it can b…

2019-03-19 Thread GitBox
asfgit closed pull request #3369: NIFI-6120 Move nifi.registry.version property 
to root pom so it can b…
URL: https://github.com/apache/nifi/pull/3369
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi] ijokarumawak commented on issue #3369: NIFI-6120 Move nifi.registry.version property to root pom so it can b…

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3369: NIFI-6120 Move nifi.registry.version 
property to root pom so it can b…
URL: https://github.com/apache/nifi/pull/3369#issuecomment-474653011
 
 
   LGTM +1, thanks @bbende ! Merging.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (NIFI-6122) PutS3Object should support national characters in filenames

2019-03-19 Thread Koji Kawamura (JIRA)


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

Koji Kawamura updated NIFI-6122:

   Resolution: Fixed
Fix Version/s: 1.10.0
   Status: Resolved  (was: Patch Available)

> PutS3Object should support national characters in filenames
> ---
>
> Key: NIFI-6122
> URL: https://issues.apache.org/jira/browse/NIFI-6122
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
> Fix For: 1.10.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> PutS3Object sends the filename in the Content-Disposition HTTP header to S3.
> If the filename contains national characters, then the encoding will be wrong 
> which results in the following error:
> {code}
> com.amazonaws.services.s3.model.AmazonS3Exception: The request signature we 
> calculated does not match the signature you provided.
> {code}
> (Due to the character encoding error, the S3 client and the server calculate 
> the signature based on different byte sequences.)
> The filename should be URL encoded before sending to S3.



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


[GitHub] [nifi] asfgit closed pull request #3373: NIFI-6122: PutS3Object supports national characters in filenames.

2019-03-19 Thread GitBox
asfgit closed pull request #3373: NIFI-6122: PutS3Object supports national 
characters in filenames.
URL: https://github.com/apache/nifi/pull/3373
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (NIFI-6122) PutS3Object should support national characters in filenames

2019-03-19 Thread ASF subversion and git services (JIRA)


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

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

Commit 77b84edf5bd3eca03d7b2ef1d17e4cf6e2f5e15c in nifi's branch 
refs/heads/master from Peter Turcsanyi
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=77b84ed ]

NIFI-6122: PutS3Object supports national characters in filenames.

This closes #3373.

Signed-off-by: Koji Kawamura 


> PutS3Object should support national characters in filenames
> ---
>
> Key: NIFI-6122
> URL: https://issues.apache.org/jira/browse/NIFI-6122
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Reporter: Peter Turcsanyi
>Assignee: Peter Turcsanyi
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> PutS3Object sends the filename in the Content-Disposition HTTP header to S3.
> If the filename contains national characters, then the encoding will be wrong 
> which results in the following error:
> {code}
> com.amazonaws.services.s3.model.AmazonS3Exception: The request signature we 
> calculated does not match the signature you provided.
> {code}
> (Due to the character encoding error, the S3 client and the server calculate 
> the signature based on different byte sequences.)
> The filename should be URL encoded before sending to S3.



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


[GitHub] [nifi] ijokarumawak commented on issue #3373: NIFI-6122: PutS3Object supports national characters in filenames.

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3373: NIFI-6122: PutS3Object supports national 
characters in filenames.
URL: https://github.com/apache/nifi/pull/3373#issuecomment-474652167
 
 
   Thanks @turcsanyip for fixing this! I confirmed Japanese characters can be 
used as a filename. Merging to master!
   
   
![image](https://user-images.githubusercontent.com/1107620/54653438-0f477280-4afe-11e9-9082-1e6faefa77b5.png)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi] ijokarumawak commented on issue #3373: NIFI-6122: PutS3Object supports national characters in filenames.

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3373: NIFI-6122: PutS3Object supports national 
characters in filenames.
URL: https://github.com/apache/nifi/pull/3373#issuecomment-474649782
 
 
   Reviewing...


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi] asfgit closed pull request #3378: NIFI-6127: Fixed NPE in match() and find() EL functions when attribute doesn't exist

2019-03-19 Thread GitBox
asfgit closed pull request #3378: NIFI-6127: Fixed NPE in match() and find() EL 
functions when attribute doesn't exist
URL: https://github.com/apache/nifi/pull/3378
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (NIFI-6127) AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison object is a non existing flowfile attribute

2019-03-19 Thread ASF subversion and git services (JIRA)


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

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

Commit 06f41ac6f8645fc2e37be2529200e89177f48197 in nifi's branch 
refs/heads/master from Matt Burgess
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=06f41ac ]

NIFI-6127: Fixed NPE in match() and find() EL functions when attribute doesn't 
exist

This closes #3378.

Signed-off-by: Koji Kawamura 


> AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison 
> object is a non existing flowfile attribute
> --
>
> Key: NIFI-6127
> URL: https://issues.apache.org/jira/browse/NIFI-6127
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Steven Youtsey
>Assignee: Matt Burgess
>Priority: Major
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> MatchesEvaluator, line 56 - When the flow file attributes do not contain the 
> attribute specified in the comparison portion of a 'matches' operation, the 
> Pattern.compile(null) throws an NPE.
> Since there is no guarantee that a specified flow file attribute is present, 
> this should simply return BooleanQueryResult(false) if the desired attribute 
> does not exist.



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


[GitHub] [nifi] ijokarumawak commented on issue #3378: NIFI-6127: Fixed NPE in match() and find() EL functions when attribute doesn't exist

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3378: NIFI-6127: Fixed NPE in match() and 
find() EL functions when attribute doesn't exist
URL: https://github.com/apache/nifi/pull/3378#issuecomment-474648109
 
 
   Thanks @mattyb149 for the fix. LGTM +1. Merging!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi] ijokarumawak commented on issue #3351: NIFI-2933 Remote input/output ports at any PG

2019-03-19 Thread GitBox
ijokarumawak commented on issue #3351: NIFI-2933 Remote input/output ports at 
any PG
URL: https://github.com/apache/nifi/pull/3351#issuecomment-474642552
 
 
   @mcgilman Thanks for reviewing. I hope the last commit addresses all your 
comments, except the one about the number of port on the canvas.
   
   I'm not sure if I understand it correctly, but I found that a child PG shows 
total number of ports regardless of public/local, while it only shows total num 
of FlowFiles and received bytes for local connections.
   I think the child PG on the parent PG should show the total num of FlowFiles 
and received bytes including both public and local connections as its `In` 
value.
   
   Is this the same concern you mentioned above?
   
   
![image](https://user-images.githubusercontent.com/1107620/54651433-3306ba80-4af6-11e9-8d66-6ef9a431f797.png)
   
   
![image](https://user-images.githubusercontent.com/1107620/54651438-4023a980-4af6-11e9-9afd-2dfbfaf666a8.png)
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Assigned] (MINIFICPP-780) Change GenerateFlowFile to allow 0b content FlowFIles

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault reassigned MINIFICPP-780:


Assignee: Mr TheSegfault

> Change GenerateFlowFile to allow 0b content FlowFIles
> -
>
> Key: MINIFICPP-780
> URL: https://issues.apache.org/jira/browse/MINIFICPP-780
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.7.0
>
>
> Would also behoove us to fill some gaps with this processor since it's used 
> so frequently



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


[jira] [Assigned] (MINIFICPP-780) Change GenerateFlowFile to allow 0b content FlowFIles

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault reassigned MINIFICPP-780:


Assignee: (was: Mr TheSegfault)

> Change GenerateFlowFile to allow 0b content FlowFIles
> -
>
> Key: MINIFICPP-780
> URL: https://issues.apache.org/jira/browse/MINIFICPP-780
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: Mr TheSegfault
>Priority: Major
> Fix For: 0.7.0
>
>
> Would also behoove us to fill some gaps with this processor since it's used 
> so frequently



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


[jira] [Commented] (NIFIREG-237) Importing previously exported flow removes definitions of loadBalanceCompression loadBalanceStrategy and partitioningAttribute

2019-03-19 Thread Wojciech Bartosiak (JIRA)


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

Wojciech Bartosiak commented on NIFIREG-237:


I'm using version 0.12.0

Problem exists only when exporting flow via REST (export has these fields only 
when flow is verasioned by Nifi app)

Then I'm trying to import this flow into  registry and everything is fine but 
when I export this flow once again it has no fields

> Importing previously exported flow removes definitions of 
> loadBalanceCompression loadBalanceStrategy and partitioningAttribute
> --
>
> Key: NIFIREG-237
> URL: https://issues.apache.org/jira/browse/NIFIREG-237
> Project: NiFi Registry
>  Issue Type: Bug
>Affects Versions: 0.3.0
>Reporter: Wojciech Bartosiak
>Priority: Critical
>
> When you export Nifi flow (previously versioned by Nifi GUI) from Registry as 
> JSON it has definitions of
>  * loadBalanceCompression
>  * loadBalanceStrategy
>  * partitioningAttribute
> inside connections sections.
>  
> When you reimport flow from json, creating new version, and then re-export 
> it, above definitions are not included in JSON.
>  



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


[jira] [Assigned] (MINIFICPP-780) Change GenerateFlowFile to allow 0b content FlowFIles

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault reassigned MINIFICPP-780:


Assignee: Mr TheSegfault

> Change GenerateFlowFile to allow 0b content FlowFIles
> -
>
> Key: MINIFICPP-780
> URL: https://issues.apache.org/jira/browse/MINIFICPP-780
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
> Fix For: 0.7.0
>
>
> Would also behoove us to fill some gaps with this processor since it's used 
> so frequently



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


[jira] [Updated] (NIFI-6132) NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo by default

2019-03-19 Thread Mark Payne (JIRA)


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

Mark Payne updated NIFI-6132:
-
Priority: Blocker  (was: Major)

> NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo 
> by default
> 
>
> Key: NIFI-6132
> URL: https://issues.apache.org/jira/browse/NIFI-6132
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Priority: Blocker
>
> It is not recommended to use G1GC along with the Write-Ahead Provenance 
> Repository due to known bugs in the G1GC in versions of Java earlier than 
> 1.9. The default for the Provenance Repository was changed to the Write-Ahead 
> Provenance Repository, but the garbage collector still defaults to G1GC.



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


[jira] [Created] (NIFI-6132) NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo by default

2019-03-19 Thread Mark Payne (JIRA)
Mark Payne created NIFI-6132:


 Summary: NiFi defaults to using G1GC but now also uses the 
Write-Ahead Provenance Repo by default
 Key: NIFI-6132
 URL: https://issues.apache.org/jira/browse/NIFI-6132
 Project: Apache NiFi
  Issue Type: Bug
Reporter: Mark Payne


It is not recommended to use G1GC along with the Write-Ahead Provenance 
Repository due to known bugs in the G1GC in versions of Java earlier than 1.9. 
The default for the Provenance Repository was changed to the Write-Ahead 
Provenance Repository, but the garbage collector still defaults to G1GC.



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


[jira] [Updated] (NIFI-6132) NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo by default

2019-03-19 Thread Mark Payne (JIRA)


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

Mark Payne updated NIFI-6132:
-
Labels: beginner easy newbie  (was: )

> NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo 
> by default
> 
>
> Key: NIFI-6132
> URL: https://issues.apache.org/jira/browse/NIFI-6132
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Priority: Blocker
>  Labels: beginner, easy, newbie
> Fix For: 1.10.0
>
>
> It is not recommended to use G1GC along with the Write-Ahead Provenance 
> Repository due to known bugs in the G1GC in versions of Java earlier than 
> 1.9. The default for the Provenance Repository was changed to the Write-Ahead 
> Provenance Repository, but the garbage collector still defaults to G1GC.



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


[jira] [Updated] (NIFI-6132) NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo by default

2019-03-19 Thread Mark Payne (JIRA)


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

Mark Payne updated NIFI-6132:
-
Fix Version/s: 1.10.0

> NiFi defaults to using G1GC but now also uses the Write-Ahead Provenance Repo 
> by default
> 
>
> Key: NIFI-6132
> URL: https://issues.apache.org/jira/browse/NIFI-6132
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Mark Payne
>Priority: Blocker
> Fix For: 1.10.0
>
>
> It is not recommended to use G1GC along with the Write-Ahead Provenance 
> Repository due to known bugs in the G1GC in versions of Java earlier than 
> 1.9. The default for the Provenance Repository was changed to the Write-Ahead 
> Provenance Repository, but the garbage collector still defaults to G1GC.



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


[jira] [Commented] (MINIFICPP-622) Transmit binary information for CAPI implementations in heartbeat

2019-03-19 Thread Aldrin Piri (JIRA)


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

Aldrin Piri commented on MINIFICPP-622:
---

Hey [~aboda],

I am a little unclear on some of the intent items but there are a few scenarios 
we need to consider.  To clarify, is your current approach assuming that the 
system doing the compilation will also be the host environment?  I do agree 
that the need to transmit this information is infrequent, but only once could 
be problematic as systems evolve and are patched.

There is a construct of registration where an initial offering of information 
is provided.  There has been some discussion about DESCRIBE filling the area 
you are talking about.  Perhaps we could have a particular operand that maps to 
this class of information?

> Transmit binary information for CAPI implementations in heartbeat
> -
>
> Key: MINIFICPP-622
> URL: https://issues.apache.org/jira/browse/MINIFICPP-622
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: Mr TheSegfault
>Assignee: Arpad Boda
>Priority: Major
>  Labels: CAPI, nanofi
>
> Heartbeats transmit a great deal of information as per our defined spec: 
> [https://cwiki.apache.org/confluence/display/MINIFI/C2+Design+Proposal]
> This ticket will be responsible for figuring out what can and cannot be sent 
> via these binaries created using the CAPI
>  
> For CAPI : probably need the AgentBuild information, but also potentially 
> information from a consumer's program – is there a way to capture information 
> about THEIR binary information
>  
> May include information like python version, GCC version, etc that's NOT 
> about our library ( and not captured in AgentBuild) – but rather about 
> theirs. 



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


[GitHub] [nifi] mcgilman commented on issue #3281: NIFI-5986 Adding "Stop & Configure" button functionality to Processor…

2019-03-19 Thread GitBox
mcgilman commented on issue #3281: NIFI-5986 Adding "Stop & Configure" button 
functionality to Processor…
URL: https://github.com/apache/nifi/pull/3281#issuecomment-474533126
 
 
   @aeaversa Thanks for the updates. Good work here. A few more comments on the 
behavior. I haven't had a chance to dig in yet but want to share some initial 
thoughts. 
   
   - I think the `Stop & Configure` menu item should be available when the 
component is stopped but there are active threads. This is most easily testable 
using `DebugFlow` and setting the `On Trigger Pause Time`. Should this menu 
item be visible under the same conditions as the `View configuration` menu item?
   - Should the status bar be visible when it's unneeded?
   - Quickly looking at the changes introduced into the jquery dialog 
component, I'm wondering if we should decouple the status bar content so that 
there's no dialog instance specific things in there. The fact that we're 
rendering component status, threads, and bulletins there are very specific to 
this use case and probably shouldn't be in the generic dialog component. What 
if we wanted to take this approach with other dialogs and other components that 
may report status differently (like active transmission for remote ports)? The 
fact that the button model is configurable is great.
   
   @moranr Any thoughts? Icon for the `Stop & Configure` menu item look good?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (MINIFICPP-780) Change GenerateFlowFile to allow 0b content FlowFIles

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault updated MINIFICPP-780:
-
Description: Would also behoove us to fill some gaps with this processor 
since it's used so frequently

> Change GenerateFlowFile to allow 0b content FlowFIles
> -
>
> Key: MINIFICPP-780
> URL: https://issues.apache.org/jira/browse/MINIFICPP-780
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: Mr TheSegfault
>Priority: Major
> Fix For: 0.7.0
>
>
> Would also behoove us to fill some gaps with this processor since it's used 
> so frequently



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


[jira] [Created] (MINIFICPP-780) Change GenerateFlowFile to allow 0b content FlowFIles

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-780:


 Summary: Change GenerateFlowFile to allow 0b content FlowFIles
 Key: MINIFICPP-780
 URL: https://issues.apache.org/jira/browse/MINIFICPP-780
 Project: NiFi MiNiFi C++
  Issue Type: New Feature
Reporter: Mr TheSegfault
 Fix For: 0.7.0






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


[jira] [Updated] (NIFI-6127) AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison object is a non existing flowfile attribute

2019-03-19 Thread Matt Burgess (JIRA)


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

Matt Burgess updated NIFI-6127:
---
Summary: AttributeExpressionLanguage - 'match' and 'find' throw NPE when 
comparison object is a non existing flowfile attribute  (was: 
AttributeExpressionLanguage - 'match' throws NPE when comparison object is a 
non existing flowfile attribute)

> AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison 
> object is a non existing flowfile attribute
> --
>
> Key: NIFI-6127
> URL: https://issues.apache.org/jira/browse/NIFI-6127
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.8.0
>Reporter: Steven Youtsey
>Priority: Major
>
> MatchesEvaluator, line 56 - When the flow file attributes do not contain the 
> attribute specified in the comparison portion of a 'matches' operation, the 
> Pattern.compile(null) throws an NPE.
> Since there is no guarantee that a specified flow file attribute is present, 
> this should simply return BooleanQueryResult(false) if the desired attribute 
> does not exist.



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


[jira] [Updated] (NIFI-6127) AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison object is a non existing flowfile attribute

2019-03-19 Thread Matt Burgess (JIRA)


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

Matt Burgess updated NIFI-6127:
---
Affects Version/s: (was: 1.8.0)
   Status: Patch Available  (was: In Progress)

> AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison 
> object is a non existing flowfile attribute
> --
>
> Key: NIFI-6127
> URL: https://issues.apache.org/jira/browse/NIFI-6127
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Reporter: Steven Youtsey
>Assignee: Matt Burgess
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> MatchesEvaluator, line 56 - When the flow file attributes do not contain the 
> attribute specified in the comparison portion of a 'matches' operation, the 
> Pattern.compile(null) throws an NPE.
> Since there is no guarantee that a specified flow file attribute is present, 
> this should simply return BooleanQueryResult(false) if the desired attribute 
> does not exist.



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


[GitHub] [nifi] mattyb149 opened a new pull request #3378: NIFI-6127: Fixed NPE in match() and find() EL functions when attribute doesn't exist

2019-03-19 Thread GitBox
mattyb149 opened a new pull request #3378: NIFI-6127: Fixed NPE in match() and 
find() EL functions when attribute doesn't exist
URL: https://github.com/apache/nifi/pull/3378
 
 
   
   Thank you for submitting a contribution to Apache NiFi.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [x] Is there a JIRA ticket associated with this PR? Is it referenced 
in the commit message?
   
   - [x] Does your PR title start with NIFI- where  is the JIRA number 
you are trying to resolve? Pay particular attention to the hyphen "-" character.
   
   - [x] Has your PR been rebased against the latest commit within the target 
branch (typically master)?
   
   - [x] Is your initial contribution a single, squashed commit?
   
   ### For code changes:
   - [x] Have you ensured that the full suite of tests is executed via mvn 
-Pcontrib-check clean install at the root nifi folder?
   - [x] Have you written or updated unit tests to verify your changes?
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)? 
   - [ ] If applicable, have you updated the LICENSE file, including the main 
LICENSE file under nifi-assembly?
   - [ ] If applicable, have you updated the NOTICE file, including the main 
NOTICE file found under nifi-assembly?
   - [ ] If adding new Properties, have you added .displayName in addition to 
.name (programmatic access) for each of the new properties?
   
   ### For documentation related changes:
   - [ ] Have you ensured that format looks appropriate for the output in which 
it is rendered?
   
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Assigned] (NIFI-6127) AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison object is a non existing flowfile attribute

2019-03-19 Thread Matt Burgess (JIRA)


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

Matt Burgess reassigned NIFI-6127:
--

Assignee: Matt Burgess

> AttributeExpressionLanguage - 'match' and 'find' throw NPE when comparison 
> object is a non existing flowfile attribute
> --
>
> Key: NIFI-6127
> URL: https://issues.apache.org/jira/browse/NIFI-6127
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.8.0
>Reporter: Steven Youtsey
>Assignee: Matt Burgess
>Priority: Major
>
> MatchesEvaluator, line 56 - When the flow file attributes do not contain the 
> attribute specified in the comparison portion of a 'matches' operation, the 
> Pattern.compile(null) throws an NPE.
> Since there is no guarantee that a specified flow file attribute is present, 
> this should simply return BooleanQueryResult(false) if the desired attribute 
> does not exist.



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


[jira] [Updated] (MINIFICPP-615) Provide Windows OpenSSL Support

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault updated MINIFICPP-615:
-
Fix Version/s: (was: 0.6.0)
   0.7.0

> Provide Windows OpenSSL Support
> ---
>
> Key: MINIFICPP-615
> URL: https://issues.apache.org/jira/browse/MINIFICPP-615
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
> Environment: Microsoft Windows
>Reporter: Mr TheSegfault
>Assignee: Mr TheSegfault
>Priority: Major
>  Labels: windows
> Fix For: 0.7.0
>
>
> Ensure OpenSSL support works throughout our project in windows.
>  
> MINIFICPP-6



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


[jira] [Commented] (NIFIREG-237) Importing previously exported flow removes definitions of loadBalanceCompression loadBalanceStrategy and partitioningAttribute

2019-03-19 Thread Bryan Bende (JIRA)


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

Bryan Bende commented on NIFIREG-237:
-

Can you provide what version of nipyapi you are using?

>From looking at the project releases, I think you would have to be using v 
>0.12.0 in order for this to work correctly:

https://github.com/Chaffelson/nipyapi/releases

> Importing previously exported flow removes definitions of 
> loadBalanceCompression loadBalanceStrategy and partitioningAttribute
> --
>
> Key: NIFIREG-237
> URL: https://issues.apache.org/jira/browse/NIFIREG-237
> Project: NiFi Registry
>  Issue Type: Bug
>Affects Versions: 0.3.0
>Reporter: Wojciech Bartosiak
>Priority: Critical
>
> When you export Nifi flow (previously versioned by Nifi GUI) from Registry as 
> JSON it has definitions of
>  * loadBalanceCompression
>  * loadBalanceStrategy
>  * partitioningAttribute
> inside connections sections.
>  
> When you reimport flow from json, creating new version, and then re-export 
> it, above definitions are not included in JSON.
>  



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


[GitHub] [nifi-registry] bbende commented on issue #144: NIFIREG-209 Rebuild metadata DB from FlowPersistenceProvider when emp…

2019-03-19 Thread GitBox
bbende commented on issue #144: NIFIREG-209 Rebuild metadata DB from 
FlowPersistenceProvider when emp…
URL: https://github.com/apache/nifi-registry/pull/144#issuecomment-474463056
 
 
   @asxtray I haven't tried this from master in a while, but I don't know of 
any reason why it wouldn't still be working. Can you check your 
nifi-registry-app.log during start up for any of the following log statements?
   ```
   "*  FlowPersistenceProvider is not metadata-aware, nothing to synchronize"
   "*  Found existing buckets, will not synchronize metadata"
   "*  Synchronizing metadata from FlowPersistenceProvider to metadata 
database..."
   ```
   Let us know which of these printed.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi-registry] asxtray edited a comment on issue #144: NIFIREG-209 Rebuild metadata DB from FlowPersistenceProvider when emp…

2019-03-19 Thread GitBox
asxtray edited a comment on issue #144: NIFIREG-209 Rebuild metadata DB from 
FlowPersistenceProvider when emp…
URL: https://github.com/apache/nifi-registry/pull/144#issuecomment-474454670
 
 
   Has anyone tried the functionality from master branch? Pulled and rebuilt 
from master, starting registry with preconfigured GitFlowPersistenceProvider 
and local flow file git folder but the registry is empty. Shall I specify some 
startup flag to rebuild the database?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi-registry] asxtray commented on issue #144: NIFIREG-209 Rebuild metadata DB from FlowPersistenceProvider when emp…

2019-03-19 Thread GitBox
asxtray commented on issue #144: NIFIREG-209 Rebuild metadata DB from 
FlowPersistenceProvider when emp…
URL: https://github.com/apache/nifi-registry/pull/144#issuecomment-474454670
 
 
   Has anyone tried the functionality from master branch? Pulled and rebuilt 
from master, staring registry with preconfigured GitFlowPersistenceProvider and 
local flow file git folder but the registry is empty. Shall I specify some 
startup flag to rebuild the database?


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi] gideonkorir commented on issue #3343: Nifi 5572

2019-03-19 Thread GitBox
gideonkorir commented on issue #3343: Nifi 5572
URL: https://github.com/apache/nifi/pull/3343#issuecomment-474429103
 
 
   Realized I was naive in my initial PR, I've gone through all the references 
to `RecordFieldType` and made the following changes:
   
   - [x]  Update PutCassandra processor to handle decimal and added tests for 
that
   - [x] Update PutElasticSearch processor to handle decimal and added tests 
for that. Caveat, I'm using BigDecimal.toPlainString() so that we don't have 
scientific notation in the json output; not sure if OK
   - [x] Added decimal tests for HBase
   - [x] Added decimal tests for Kudu
   - [x] Update PutMongoRecord processor to handle decimal, added codec package 
that adds the necessary codecs for that. 
   - [x] Update StandardSchemaValidator, support decimal in `validate`, added 
tests for that
   - [x] ResultSetRecordSet has decimal support, factoring in precision and 
scale of the returned decimals
   - [x] JsonPathRowRecordReader has decimal support, added tests for that
   - [x] JsonTreeRowRecordReader has decimal support, added tests for that


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Assigned] (MINIFICPP-779) u18 make target

2019-03-19 Thread Aldrin Piri (JIRA)


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

Aldrin Piri reassigned MINIFICPP-779:
-

Assignee: Mr TheSegfault

> u18 make target
> ---
>
> Key: MINIFICPP-779
> URL: https://issues.apache.org/jira/browse/MINIFICPP-779
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Aldrin Piri
>Assignee: Mr TheSegfault
>Priority: Minor
> Fix For: 0.6.0
>
> Attachments: screenshot-1.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Subsequent builds using the `make u18` target are no longer functioning.  It 
> appears the previously relied upon package no longer exists in upstream 
> repositories for libpython3.5-dev for the u18 base image.



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


[jira] [Resolved] (MINIFICPP-779) u18 make target

2019-03-19 Thread Aldrin Piri (JIRA)


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

Aldrin Piri resolved MINIFICPP-779.
---
Resolution: Fixed

> u18 make target
> ---
>
> Key: MINIFICPP-779
> URL: https://issues.apache.org/jira/browse/MINIFICPP-779
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Aldrin Piri
>Assignee: Mr TheSegfault
>Priority: Minor
> Fix For: 0.6.0
>
> Attachments: screenshot-1.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Subsequent builds using the `make u18` target are no longer functioning.  It 
> appears the previously relied upon package no longer exists in upstream 
> repositories for libpython3.5-dev for the u18 base image.



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


[GitHub] [nifi] SatwikBhandiwad commented on issue #3257: NIFI-5435 Prometheus /metrics http endpoint for monitoring integration

2019-03-19 Thread GitBox
SatwikBhandiwad commented on issue #3257: NIFI-5435 Prometheus /metrics http 
endpoint for monitoring integration
URL: https://github.com/apache/nifi/pull/3257#issuecomment-474405535
 
 
   Hi @kevdoran, I've made the suggested code changes regarding client 
authentication. Please review and let me know if there are any changes required.


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi-minifi-cpp] asfgit closed pull request #517: MINIFICPP-779: Change debian and apt repos to use libpython3-dev, wit…

2019-03-19 Thread GitBox
asfgit closed pull request #517: MINIFICPP-779: Change debian and apt repos to 
use libpython3-dev, wit…
URL: https://github.com/apache/nifi-minifi-cpp/pull/517
 
 
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Updated] (NIFI-6117) DataTypeUtils.isBigIntTypeCompatible always returns false

2019-03-19 Thread Matt Burgess (JIRA)


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

Matt Burgess updated NIFI-6117:
---
Status: Patch Available  (was: Open)

> DataTypeUtils.isBigIntTypeCompatible always returns false
> -
>
> Key: NIFI-6117
> URL: https://issues.apache.org/jira/browse/NIFI-6117
> Project: Apache NiFi
>  Issue Type: Bug
>Reporter: Koji Kawamura
>Assignee: Koji Kawamura
>Priority: Major
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Because it checks null value wrongly:
> {code:java}
> public static boolean isBigIntTypeCompatible(final Object value) {
> return value == null && (value instanceof BigInteger || value 
> instanceof Long);
> }
> {code}
> should be:
> {code:java}
> public static boolean isBigIntTypeCompatible(final Object value) {
> // We need something similar to isIntegral, but the value can be 
> larger than the max long.
> return isNumberTypeCompatible(value, s -> 
> somethingSimilarToIsIntegral(s))
> }
> {code}



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


[jira] [Updated] (MINIFICPP-779) u18 make target

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault updated MINIFICPP-779:
-
Fix Version/s: 0.6.0

> u18 make target
> ---
>
> Key: MINIFICPP-779
> URL: https://issues.apache.org/jira/browse/MINIFICPP-779
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Aldrin Piri
>Priority: Minor
> Fix For: 0.6.0
>
> Attachments: screenshot-1.png
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Subsequent builds using the `make u18` target are no longer functioning.  It 
> appears the previously relied upon package no longer exists in upstream 
> repositories for libpython3.5-dev for the u18 base image.



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


[GitHub] [nifi-minifi-cpp] apiri commented on issue #517: MINIFICPP-779: Change debian and apt repos to use libpython3-dev, wit…

2019-03-19 Thread GitBox
apiri commented on issue #517: MINIFICPP-779: Change debian and apt repos to 
use libpython3-dev, wit…
URL: https://github.com/apache/nifi-minifi-cpp/pull/517#issuecomment-474378428
 
 
   reviewing


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[GitHub] [nifi-minifi-cpp] phrocker opened a new pull request #517: MINIFICPP-779: Change debian and apt repos to use libpython3-dev, wit…

2019-03-19 Thread GitBox
phrocker opened a new pull request #517: MINIFICPP-779: Change debian and apt 
repos to use libpython3-dev, wit…
URL: https://github.com/apache/nifi-minifi-cpp/pull/517
 
 
   …h knowledge that they'll be 3.5+. If a user does an update they will either 
need to install the older version or already have it installed to run the 
convenience binaries based on how libpython is linked
   
   Thank you for submitting a contribution to Apache NiFi - MiNiFi C++.
   
   In order to streamline the review of the contribution we ask you
   to ensure the following steps have been taken:
   
   ### For all changes:
   - [ ] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
   
   - [ ] Does your PR title start with MINIFICPP- where  is the JIRA 
number you are trying to resolve? Pay particular attention to the hyphen "-" 
character.
   
   - [ ] Has your PR been rebased against the latest commit within the target 
branch (typically master)?
   
   - [ ] Is your initial contribution a single, squashed commit?
   
   ### For code changes:
   - [ ] If adding new dependencies to the code, are these dependencies 
licensed in a way that is compatible for inclusion under [ASF 
2.0](http://www.apache.org/legal/resolved.html#category-a)?
   - [ ] If applicable, have you updated the LICENSE file?
   - [ ] If applicable, have you updated the NOTICE file?
   
   ### For documentation related changes:
   - [ ] Have you ensured that format looks appropriate for the output in which 
it is rendered?
   
   ### Note:
   Please ensure that once the PR is submitted, you check travis-ci for build 
issues and submit an update to your PR as soon as possible.
   


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Created] (NIFI-6131) MergeContent is not properly storing file permissions from tar.permissions

2019-03-19 Thread Justin Rittenhouse (JIRA)
Justin Rittenhouse created NIFI-6131:


 Summary: MergeContent is not properly storing file permissions 
from tar.permissions
 Key: NIFI-6131
 URL: https://issues.apache.org/jira/browse/NIFI-6131
 Project: Apache NiFi
  Issue Type: Bug
  Components: Extensions
Affects Versions: 1.9.0
Reporter: Justin Rittenhouse


* GetFile retrieves files, with permissions stored in file.permissions in "rwx" 
format
 * UpdateAttribute converts rwx to digits and stores in tar.permissions via the 
following:
 ** 
${file.permissions:replaceAll('rwx','7'):replaceAll('rw-','6'):replaceAll('r-x','5'):replaceAll('r--','4'):replaceAll('-wx','3'):replaceAll('-w-','2'):replaceAll('–x','1'):replaceAll('—','0')}
 * MergeContent creates tar file, reading tar.permissions
 * Download and extract files from tarball
 * Check permissions against incoming files
 ** Permissions do not match, for example:
 *** -rwxrwx--- becomes -r--wT
 *** -rwxr-xr-x becomes --wxrw–wt
 *** -rw-rw-r-- becomes --w–wx–T
 *** -rw--- becomes ---x-wx–T
 *** -rw-r--r-- becomes --wr-T
 *** -rwxrwxr-x becomes -r-rwt
 *** -rwxr-xr-x becomes --wxrw–wt
 * Have tried pre-pending a leading 0, which also does not work.



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


[jira] [Updated] (MINIFICPP-779) u18 make target

2019-03-19 Thread Aldrin Piri (JIRA)


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

Aldrin Piri updated MINIFICPP-779:
--
Attachment: screenshot-1.png

> u18 make target
> ---
>
> Key: MINIFICPP-779
> URL: https://issues.apache.org/jira/browse/MINIFICPP-779
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Aldrin Piri
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Subsequent builds using the `make u18` target are no longer functioning.  It 
> appears the previously relied upon package no longer exists in upstream 
> repositories for libpython3.5-dev



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


[GitHub] [nifi] SavtechSolutions commented on issue #3269: NIFI-5960 add compatibility rating to RECORD schemas

2019-03-19 Thread GitBox
SavtechSolutions commented on issue #3269: NIFI-5960 add compatibility rating 
to RECORD schemas
URL: https://github.com/apache/nifi/pull/3269#issuecomment-474359825
 
 
   Fixed the Javadoc for the new method


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services


[jira] [Commented] (MINIFICPP-779) u18 make target

2019-03-19 Thread Mr TheSegfault (JIRA)


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

Mr TheSegfault commented on MINIFICPP-779:
--

Thanks for finding this. The issue is actually in our bootstrap, so there is 
quite a bit verification needed to get this into 0.6.0. 

> u18 make target
> ---
>
> Key: MINIFICPP-779
> URL: https://issues.apache.org/jira/browse/MINIFICPP-779
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Aldrin Piri
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Subsequent builds using the `make u18` target are no longer functioning.  It 
> appears the previously relied upon package no longer exists in upstream 
> repositories for libpython3.5-dev for the u18 base image.



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


[jira] [Updated] (MINIFICPP-779) u18 make target

2019-03-19 Thread Aldrin Piri (JIRA)


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

Aldrin Piri updated MINIFICPP-779:
--
Description: Subsequent builds using the `make u18` target are no longer 
functioning.  It appears the previously relied upon package no longer exists in 
upstream repositories for libpython3.5-dev for the u18 base image.  (was: 
Subsequent builds using the `make u18` target are no longer functioning.  It 
appears the previously relied upon package no longer exists in upstream 
repositories for libpython3.5-dev)

> u18 make target
> ---
>
> Key: MINIFICPP-779
> URL: https://issues.apache.org/jira/browse/MINIFICPP-779
> Project: NiFi MiNiFi C++
>  Issue Type: Bug
>Affects Versions: 0.6.0
>Reporter: Aldrin Piri
>Priority: Minor
> Attachments: screenshot-1.png
>
>
> Subsequent builds using the `make u18` target are no longer functioning.  It 
> appears the previously relied upon package no longer exists in upstream 
> repositories for libpython3.5-dev for the u18 base image.



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


[jira] [Created] (MINIFICPP-779) u18 make target

2019-03-19 Thread Aldrin Piri (JIRA)
Aldrin Piri created MINIFICPP-779:
-

 Summary: u18 make target
 Key: MINIFICPP-779
 URL: https://issues.apache.org/jira/browse/MINIFICPP-779
 Project: NiFi MiNiFi C++
  Issue Type: Bug
Affects Versions: 0.6.0
Reporter: Aldrin Piri
 Attachments: screenshot-1.png

Subsequent builds using the `make u18` target are no longer functioning.  It 
appears the previously relied upon package no longer exists in upstream 
repositories for libpython3.5-dev



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


[jira] [Commented] (MINIFICPP-622) Transmit binary information for CAPI implementations in heartbeat

2019-03-19 Thread Arpad Boda (JIRA)


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

Arpad Boda commented on MINIFICPP-622:
--

Just to have some written concept here.

I found two ways of gathering system information:

-Add some compiler macros in Nanofi API that provide some information about the 
customer's program (compiler, version, architecture, etc).

-Execute some subprocesses with popen (to get python version and uname).

I think this information is only to be sent once, so we can either:

-Add a new section to heartbeat, which is not mandatory, only the first 
heartbeat contains this information.

-Add a new operation, which is only sent once after C2 connection is initiated. 

 

[~phrocker] , [~aldrin] do you have anything to add to the above or do you see 
any pitfalls? 

 

> Transmit binary information for CAPI implementations in heartbeat
> -
>
> Key: MINIFICPP-622
> URL: https://issues.apache.org/jira/browse/MINIFICPP-622
> Project: NiFi MiNiFi C++
>  Issue Type: New Feature
>Reporter: Mr TheSegfault
>Assignee: Arpad Boda
>Priority: Major
>  Labels: CAPI, nanofi
>
> Heartbeats transmit a great deal of information as per our defined spec: 
> [https://cwiki.apache.org/confluence/display/MINIFI/C2+Design+Proposal]
> This ticket will be responsible for figuring out what can and cannot be sent 
> via these binaries created using the CAPI
>  
> For CAPI : probably need the AgentBuild information, but also potentially 
> information from a consumer's program – is there a way to capture information 
> about THEIR binary information
>  
> May include information like python version, GCC version, etc that's NOT 
> about our library ( and not captured in AgentBuild) – but rather about 
> theirs. 



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


[jira] [Created] (MINIFICPP-778) Docker build and test directories should be copied into build directory, not source tree

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-778:


 Summary: Docker build and test directories should be copied into 
build directory, not source tree
 Key: MINIFICPP-778
 URL: https://issues.apache.org/jira/browse/MINIFICPP-778
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
Affects Versions: 0.6.0
Reporter: Mr TheSegfault
 Fix For: 0.7.0






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


[jira] [Created] (MINIFICPP-775) Explore triggers for windows API calls

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-775:


 Summary: Explore triggers for windows API calls
 Key: MINIFICPP-775
 URL: https://issues.apache.org/jira/browse/MINIFICPP-775
 Project: NiFi MiNiFi C++
  Issue Type: New Feature
 Environment: Windows
Reporter: Mr TheSegfault


Explore creating triggers on a windows system that allow us to capture events 
and create provenance when needed.



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


[jira] [Created] (MINIFICPP-777) Build nanofi for windows

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-777:


 Summary: Build nanofi for windows 
 Key: MINIFICPP-777
 URL: https://issues.apache.org/jira/browse/MINIFICPP-777
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
 Environment: Windows
Reporter: Mr TheSegfault


Allow nanofi to be built for windows and supplied as a DLL



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


[jira] [Created] (MINIFICPP-776) Add binary diff capability to windows c2 updates

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-776:


 Summary: Add binary diff capability to windows c2 updates
 Key: MINIFICPP-776
 URL: https://issues.apache.org/jira/browse/MINIFICPP-776
 Project: NiFi MiNiFi C++
  Issue Type: New Feature
 Environment: Windows
Reporter: Mr TheSegfault


Add binary diff capability to windows c2 updates – in linux this feature sends 
a binary diff and allows for agent updates to be much smaller in nature



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


[jira] [Created] (MINIFICPP-774) Create Windows Service

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-774:


 Summary: Create Windows Service 
 Key: MINIFICPP-774
 URL: https://issues.apache.org/jira/browse/MINIFICPP-774
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
 Environment: Windows
Reporter: Mr TheSegfault


Create Windows Service from the agent. this may mean creating a new entry point 
for MiNiFiMain, but not a separate project



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


[jira] [Created] (MINIFICPP-773) Create ConsumeWindowsEvent log

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-773:


 Summary: Create ConsumeWindowsEvent log 
 Key: MINIFICPP-773
 URL: https://issues.apache.org/jira/browse/MINIFICPP-773
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
 Environment: Windows
Reporter: Mr TheSegfault


Create ConsumeWindowsEvent log reader to match functionality from NiFi



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


[jira] [Created] (MINIFICPP-772) Improve Appveyor builds

2019-03-19 Thread Mr TheSegfault (JIRA)
Mr TheSegfault created MINIFICPP-772:


 Summary: Improve Appveyor builds
 Key: MINIFICPP-772
 URL: https://issues.apache.org/jira/browse/MINIFICPP-772
 Project: NiFi MiNiFi C++
  Issue Type: Improvement
 Environment: Windows
Reporter: Mr TheSegfault


Appveyor builds need to be improved so that they complete on time. Part of this 
reason is the fact that we don't suppress some warnings, and in some code we 
have warnings that would otherwise not show if rewritten. 



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


[jira] [Commented] (NIFIREG-237) Importing previously exported flow removes definitions of loadBalanceCompression loadBalanceStrategy and partitioningAttribute

2019-03-19 Thread Wojciech Bartosiak (JIRA)


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

Wojciech Bartosiak commented on NIFIREG-237:


I'm using REST communication - nipyapi

> Importing previously exported flow removes definitions of 
> loadBalanceCompression loadBalanceStrategy and partitioningAttribute
> --
>
> Key: NIFIREG-237
> URL: https://issues.apache.org/jira/browse/NIFIREG-237
> Project: NiFi Registry
>  Issue Type: Bug
>Affects Versions: 0.3.0
>Reporter: Wojciech Bartosiak
>Priority: Critical
>
> When you export Nifi flow (previously versioned by Nifi GUI) from Registry as 
> JSON it has definitions of
>  * loadBalanceCompression
>  * loadBalanceStrategy
>  * partitioningAttribute
> inside connections sections.
>  
> When you reimport flow from json, creating new version, and then re-export 
> it, above definitions are not included in JSON.
>  



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


[GitHub] [nifi] pepov commented on issue #3257: NIFI-5435 Prometheus /metrics http endpoint for monitoring integration

2019-03-19 Thread GitBox
pepov commented on issue #3257: NIFI-5435 Prometheus /metrics http endpoint for 
monitoring integration
URL: https://github.com/apache/nifi/pull/3257#issuecomment-474234923
 
 
   @SatwikBhandiwad my browser tricked me, sorry! Works like a charm!


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services