[jira] [Comment Edited] (NIFI-4621) Allow inputs to ListSFTP

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-4621 at 1/22/18 6:26 PM:
--

Requesting for comment on pros, cons and security implication.

[~soumya.ghosh] Could you please provide a real life usecase for this feature? 
can we go for a limited number of SFTP hosts? Opening this feature for all 
hosts / unlimited unique sftp hosts could become a stepping stone for DDoS 
attack.


was (Author: puspendu.baner...@gmail.com):
Requesting for comment on pros, cons and security implication.

[~soumya.ghosh] Can you provide a real life usecase for this feature? can we go 
for a limited number of SFTP hosts? Opening this feature for all hosts / 
unlimited unique sftp hosts could become a stepping stone for DDoS attack.

> Allow inputs to ListSFTP
> 
>
> Key: NIFI-4621
> URL: https://issues.apache.org/jira/browse/NIFI-4621
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Soumya Shanta Ghosh
>Assignee: Puspendu Banerjee
>Priority: Critical
>
> ListSFTP supports listing of the supplied directory (Remote Path) 
> out-of-the-box on the supplied "Hostname" using the 'Username" and 'Password" 
> / "Private Key Passphrase". 
> The password can change at a regular interval (depending on organization 
> policy) or the Hostname or the Remote Path can change based on some other 
> requirement.
> This is a case to allow ListSFTP to leverage the use of Nifi Expression 
> language so that the values of Hostname, Password and/or Remote Path can be 
> set based on the attributes of an incoming flow file.



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

[jira] [Assigned] (NIFI-4621) Allow inputs to ListSFTP

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee reassigned NIFI-4621:
---

Assignee: Puspendu Banerjee

> Allow inputs to ListSFTP
> 
>
> Key: NIFI-4621
> URL: https://issues.apache.org/jira/browse/NIFI-4621
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Soumya Shanta Ghosh
>Assignee: Puspendu Banerjee
>Priority: Critical
>
> ListSFTP supports listing of the supplied directory (Remote Path) 
> out-of-the-box on the supplied "Hostname" using the 'Username" and 'Password" 
> / "Private Key Passphrase". 
> The password can change at a regular interval (depending on organization 
> policy) or the Hostname or the Remote Path can change based on some other 
> requirement.
> This is a case to allow ListSFTP to leverage the use of Nifi Expression 
> language so that the values of Hostname, Password and/or Remote Path can be 
> set based on the attributes of an incoming flow file.



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

[jira] [Commented] (NIFI-4621) Allow inputs to ListSFTP

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-4621:
-

Requesting for comment on pros, cons and security implication.

[~soumya.ghosh] Can you provide a real life usecase for this feature? can we go 
for a limited number of SFTP hosts? Opening this feature for all hosts / 
unlimited unique sftp hosts could become a stepping stone for DDoS attack.

> Allow inputs to ListSFTP
> 
>
> Key: NIFI-4621
> URL: https://issues.apache.org/jira/browse/NIFI-4621
> Project: Apache NiFi
>  Issue Type: Improvement
>Affects Versions: 1.4.0
>Reporter: Soumya Shanta Ghosh
>Priority: Critical
>
> ListSFTP supports listing of the supplied directory (Remote Path) 
> out-of-the-box on the supplied "Hostname" using the 'Username" and 'Password" 
> / "Private Key Passphrase". 
> The password can change at a regular interval (depending on organization 
> policy) or the Hostname or the Remote Path can change based on some other 
> requirement.
> This is a case to allow ListSFTP to leverage the use of Nifi Expression 
> language so that the values of Hostname, Password and/or Remote Path can be 
> set based on the attributes of an incoming flow file.



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

[jira] [Closed] (NIFI-3586) Nifi is not returning PID in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee closed NIFI-3586.
---

[~tkurc] Thanks Tony. Closing it as resolved.

> Nifi is not returning PID in Windows
> 
>
> Key: NIFI-3586
> URL: https://issues.apache.org/jira/browse/NIFI-3586
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.5.0, 0.6.0, 0.7.0, 1.2.0, 1.1.1, 1.0.1
> Environment: Java <=8, Windows
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Minor
> Fix For: 1.2.0
>
>
> Nifi PID is unavailable during startup under Windows



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3666) Skipped tests on windows need to be validated or fixed

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3666:
-

Raised NIFI-3593 when found that many tests are failing on Windows.

> Skipped tests on windows need to be validated or fixed
> --
>
> Key: NIFI-3666
> URL: https://issues.apache.org/jira/browse/NIFI-3666
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Extensions
>Reporter: Joseph Witt
>Priority: Critical
>
> In NIFI-3440 a number of relatively recently created tests were failing on 
> windows.  These tests were skipped when running on windows to help keep the 
> build moving along and to continue to test regressions on older more stable 
> tests.  However, this approach leaves room for error because we must go 
> through each and validate whether it was a bad test that needs to be fixed to 
> be more stable/portable OR whether the test exposed a bug in the code and its 
> behavior on windows.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

[~markap14] Sure.

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Fix For: 1.2.0
>
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

[~markap14] Is it still happening for WriteAhead Repo or in general.

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Fix For: 1.2.0
>
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Issue Comment Deleted] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3579:

Comment: was deleted

(was: [~markap14] Is it still happening for WriteAhead Repo or in general.)

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Fix For: 1.2.0
>
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3590) FetchSFTP Move Completion Strategy Remote Host Properties

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3590:
-

please attach a couple of screenshot of your processor to depict the 
configuration.

> FetchSFTP Move Completion Strategy Remote Host Properties
> -
>
> Key: NIFI-3590
> URL: https://issues.apache.org/jira/browse/NIFI-3590
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.1
> Environment: Debian Wheezy, jdk1.8
>Reporter: Marek Kovar
>  Labels: newbie
>
> There is an problem to use Move Completion strategy with remote host defined 
> using Expression Language.
> Eg. Port number defined using Expression language (${sftp.remote.port}) is 
> fine for the fetch itself, but for the file renaming it's causing following 
> error:
> {quote}
> 2017-03-13 15:58:06,181 ERROR [Timer-Driven Process Thread-6] 
> o.a.nifi.processors.standard.FetchSFTP
> java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_111]
> at java.lang.Integer.parseInt(Integer.java:592) ~[na:1.8.0_111]
> at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_111]
> at 
> org.apache.nifi.attribute.expression.language.StandardPropertyValue.asInteger(StandardPropertyValue.java:78)
>  ~[nifi-expression-language-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.util.SFTPTransfer.getChannel(SFTPTransfer.java:400)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.util.SFTPTransfer.rename(SFTPTransfer.java:608)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.FetchFileTransfer.onTrigger(FetchFileTransfer.java:316)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (NIFI-3535) Use keytab for local filesystem

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee reassigned NIFI-3535:
---

Assignee: Puspendu Banerjee

> Use keytab for local filesystem
> ---
>
> Key: NIFI-3535
> URL: https://issues.apache.org/jira/browse/NIFI-3535
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1, 1.0.1
> Environment: ie redhat
>Reporter: Sunile Manjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: authentication, kerbeos, security
>
> For enterprises which require strict access control to local file systems, 
> the requirement is to enable nifi processors which access local file system 
> to use keytab or another process to use user account which was used during 
> nifi authentication.   without such enforcement all users within a restricted 
> group have access to full local file system via nifi processor.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3590) FetchSFTP Move Completion Strategy Remote Host Properties

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3590:
-

"Move File" Strategy requires Destination Directory, not a remote host. If I 
have understood correctly, you are trying to move the file to a remote host.

> FetchSFTP Move Completion Strategy Remote Host Properties
> -
>
> Key: NIFI-3590
> URL: https://issues.apache.org/jira/browse/NIFI-3590
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 1.1.1
> Environment: Debian Wheezy, jdk1.8
>Reporter: Marek Kovar
>  Labels: newbie
>
> There is an problem to use Move Completion strategy with remote host defined 
> using Expression Language.
> Eg. Port number defined using Expression language (${sftp.remote.port}) is 
> fine for the fetch itself, but for the file renaming it's causing following 
> error:
> {quote}
> 2017-03-13 15:58:06,181 ERROR [Timer-Driven Process Thread-6] 
> o.a.nifi.processors.standard.FetchSFTP
> java.lang.NumberFormatException: For input string: ""
> at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_111]
> at java.lang.Integer.parseInt(Integer.java:592) ~[na:1.8.0_111]
> at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_111]
> at 
> org.apache.nifi.attribute.expression.language.StandardPropertyValue.asInteger(StandardPropertyValue.java:78)
>  ~[nifi-expression-language-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.util.SFTPTransfer.getChannel(SFTPTransfer.java:400)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.util.SFTPTransfer.rename(SFTPTransfer.java:608)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processors.standard.FetchFileTransfer.onTrigger(FetchFileTransfer.java:316)
>  ~[nifi-standard-processors-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.processor.AbstractProcessor.onTrigger(AbstractProcessor.java:27)
>  ~[nifi-api-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1099)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:136)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.tasks.ContinuallyRunProcessorTask.call(ContinuallyRunProcessorTask.java:47)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:132)
>  [nifi-framework-core-1.1.2.jar:1.1.2]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [na:1.8.0_111]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) 
> [na:1.8.0_111]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [na:1.8.0_111]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [na:1.8.0_111]
> at java.lang.Thread.run(Thread.java:745) [na:1.8.0_111]
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

Same kind of issue.

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (NIFI-2117) Implementation gap of relationships in Script Processor

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee closed NIFI-2117.
---

> Implementation gap of relationships in Script Processor
> ---
>
> Key: NIFI-2117
> URL: https://issues.apache.org/jira/browse/NIFI-2117
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.6.0, 0.7.0
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
> Fix For: 1.0.0, 1.0.0-Beta
>
>
> Javadoc/Contract for invoke scripted processor says t {quote} * Returns the 
> valid relationships for this processor. SUCCESS and FAILURE are always 
> returned, and if the script
>  * processor has defined additional relationships, those will be added as 
> well.{quote}
> but does not return defaults if additional relationships have been added.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-2117) Implementation gap of relationships in Script Processor

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-2117:

Status: Resolved  (was: Closed)

> Implementation gap of relationships in Script Processor
> ---
>
> Key: NIFI-2117
> URL: https://issues.apache.org/jira/browse/NIFI-2117
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.6.0, 0.7.0
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
> Fix For: 1.0.0, 1.0.0-Beta
>
>
> Javadoc/Contract for invoke scripted processor says t {quote} * Returns the 
> valid relationships for this processor. SUCCESS and FAILURE are always 
> returned, and if the script
>  * processor has defined additional relationships, those will be added as 
> well.{quote}
> but does not return defaults if additional relationships have been added.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3593) Conditionally Ignore Junit Tests

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3593:

Description: 
We should incorporate a capability to conditionally ignore unit tests which are 
not relevant to certain condition, environment, language, locale etc.
For example, 
# YUI compressor fails on windows
# CEFParser fails on non-English environment and we are yet to get an updated 
version for that.

Definitely, we can craft our test-cases to fit in, but that may lead to 
unintended foul-play. Instead of that if we run those tests in  a quarantine, 
still we will have a clear view of what ran and what not as well as we will be 
able to proceed through a green build. 

As long as release management is concerned,  
# we need to be very careful about choosing what to quarantine or conditionally 
ignore
# we should have a clean quarantine before release for certain environment.
I am thinking about some annotation driven solution like the below one, so that 
we can easily track it and report.
{code:java}
@IgnoreOn(since:Date, reason:String, conditionExpr:String)
{code}

The way Junit's *assume* or *assumeThat* works doesn't fit in directly.
Looking forward for inputs.

Ref: https://martinfowler.com/articles/nonDeterminism.html#Quarantine

  was:

We should incorporate a capability to conditionally ignore unit tests which are 
not relevant to certain condition, environment, language, locale etc.
For example, 
# YUI compressor fails on windows
# CEFParser fails on non-English environment and we are yet to get an updated 
version for that.

Definitely, we can craft our test-cases to fit in, but that may lead to 
unintended foul-play. Instead of that if we run those tests in  a quarantine, 
still we will have a clear view of what ran and what not as well as we will be 
able to proceed through a green build. 

As long as release management is concerned,  
# we need to be very careful about choosing what to quarantine or conditionally 
ignore
# we should have a clean quarantine before release for certain environment.
I am thinking about some annotation driven solution like the below one, so that 
we can easily track it and report.
{code:java}
@IgnoreOn(since:Date, reason:String, conditionExpr:String)
{code}

The way Junit's *assume* or *assumeThat* works doesn't fit in directly.
Looking forward for inputs.


> Conditionally Ignore Junit Tests
> 
>
> Key: NIFI-3593
> URL: https://issues.apache.org/jira/browse/NIFI-3593
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.0.0, 1.2.0
>Reporter: Puspendu Banerjee
>Priority: Minor
>  Labels: build, environment, junit
>
> We should incorporate a capability to conditionally ignore unit tests which 
> are not relevant to certain condition, environment, language, locale etc.
> For example, 
> # YUI compressor fails on windows
> # CEFParser fails on non-English environment and we are yet to get an updated 
> version for that.
> Definitely, we can craft our test-cases to fit in, but that may lead to 
> unintended foul-play. Instead of that if we run those tests in  a quarantine, 
> still we will have a clear view of what ran and what not as well as we will 
> be able to proceed through a green build. 
> As long as release management is concerned,  
> # we need to be very careful about choosing what to quarantine or 
> conditionally ignore
> # we should have a clean quarantine before release for certain environment.
> I am thinking about some annotation driven solution like the below one, so 
> that we can easily track it and report.
> {code:java}
> @IgnoreOn(since:Date, reason:String, conditionExpr:String)
> {code}
> The way Junit's *assume* or *assumeThat* works doesn't fit in directly.
> Looking forward for inputs.
> Ref: https://martinfowler.com/articles/nonDeterminism.html#Quarantine



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3593) Conditionally Ignore Junit Tests

[Puspendu Banerjee (JIRA)]

Puspendu Banerjee created NIFI-3593:
---

 Summary: Conditionally Ignore Junit Tests
 Key: NIFI-3593
 URL: https://issues.apache.org/jira/browse/NIFI-3593
 Project: Apache NiFi
  Issue Type: Improvement
  Components: Tools and Build
Affects Versions: 1.0.0, 1.2.0
Reporter: Puspendu Banerjee



We should incorporate a capability to conditionally ignore unit tests which are 
not relevant to certain condition, environment, language, locale etc.
For example, 
# YUI compressor fails on windows
# CEFParser fails on non-English environment and we are yet to get an updated 
version for that.

Definitely, we can craft our test-cases to fit in, but that may lead to 
unintended foul-play. Instead of that if we run those tests in  a quarantine, 
still we will have a clear view of what ran and what not as well as we will be 
able to proceed through a green build. 

As long as release management is concerned,  
# we need to be very careful about choosing what to quarantine or conditionally 
ignore
# we should have a clean quarantine before release for certain environment.
I am thinking about some annotation driven solution like the below one, so that 
we can easily track it and report.
{code:java}
@IgnoreOn(since:Date, reason:String, conditionExpr:String)
{code}

The way Junit's *assume* or *assumeThat* works doesn't fit in directly.
Looking forward for inputs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3593) Conditionally Ignore Junit Tests

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3593:

Priority: Minor  (was: Major)

> Conditionally Ignore Junit Tests
> 
>
> Key: NIFI-3593
> URL: https://issues.apache.org/jira/browse/NIFI-3593
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.0.0, 1.2.0
>Reporter: Puspendu Banerjee
>Priority: Minor
>  Labels: build, environment, junit
>
> We should incorporate a capability to conditionally ignore unit tests which 
> are not relevant to certain condition, environment, language, locale etc.
> For example, 
> # YUI compressor fails on windows
> # CEFParser fails on non-English environment and we are yet to get an updated 
> version for that.
> Definitely, we can craft our test-cases to fit in, but that may lead to 
> unintended foul-play. Instead of that if we run those tests in  a quarantine, 
> still we will have a clear view of what ran and what not as well as we will 
> be able to proceed through a green build. 
> As long as release management is concerned,  
> # we need to be very careful about choosing what to quarantine or 
> conditionally ignore
> # we should have a clean quarantine before release for certain environment.
> I am thinking about some annotation driven solution like the below one, so 
> that we can easily track it and report.
> {code:java}
> @IgnoreOn(since:Date, reason:String, conditionExpr:String)
> {code}
> The way Junit's *assume* or *assumeThat* works doesn't fit in directly.
> Looking forward for inputs.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3579:

Status: Patch Available  (was: In Progress)

https://github.com/apache/nifi/pull/1580.patch

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.1.1, 1.2.0
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3579 at 3/13/17 6:48 AM:
--

[~mosermw] Please note, even though drive D exists as a logical drive but 
*mountvol* could not find it and saying "NO MOUNT POINTS". 
BTW, D drive is permanently mounted via Session Manager in Windows and can be 
verified at registry 
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS 
Devices"
I think, you are using standard windows installation and my system has a lot of 
modification on drives, mount points and partitions :). Can you please run 
following 2 commands and pass the information.
{noformat}
PS C:\Users\puspendu> mountvol
Possible values for VolumeName along with current mount points are:

\\?\Volume{ebf1d1c4-99f2-428b-bee6-627f10c83e59}\
C:\

\\?\Volume{141fd1e8-48d6-46e5-b72c-b4d27c6bbacc}\
*** NO MOUNT POINTS ***
==
PS C:\Users\puspendu> WMIC LOGICALDISK where drivetype!=4 get 
deviceid,FileSystem,description
Description   DeviceID  FileSystem
Local Fixed Disk  C:NTFS
Local Fixed Disk  D:NTFS
{noformat}
It seems the issue is similar to an open JDK bug : 
https://bugs.openjdk.java.net/browse/JDK-8165852

Following are the reference to same kind of issue in *Non-Windows* System but 
sounds related:
# https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in 
chroot environment
# https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a 
file in overlayfs in Docker
# https://bugs.openjdk.java.net/browse/JDK-8166162 - cannot get FileStore if 
device of path is not in /proc/mounts
# 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/65042b713b12/src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java
# http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html

So, I think the PR corresponding to this ticket will take care of both of the 
scenarios without any harm.


was (Author: puspendu.baner...@gmail.com):
[~mosermw] Please note, even though drive D exists as a logical drive but 
mountvol could not find it and saying "NO MOUNT POINTS". 
BTW, D drive is permanently mounted via Session Manager in Windows and can be 
verified at registry 
"HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\DOS 
Devices"
I think, you are using standard windows installation without much modification 
on drives, mount points and partitions :). Can you please run following 2 
commands and pass the information.
{noformat}
PS C:\Users\puspendu> mountvol
Possible values for VolumeName along with current mount points are:

\\?\Volume{ebf1d1c4-99f2-428b-bee6-627f10c83e59}\
C:\

\\?\Volume{141fd1e8-48d6-46e5-b72c-b4d27c6bbacc}\
*** NO MOUNT POINTS ***
==
PS C:\Users\puspendu> WMIC LOGICALDISK where drivetype!=4 get 
deviceid,FileSystem,description
Description   DeviceID  FileSystem
Local Fixed Disk  C:NTFS
Local Fixed Disk  D:NTFS
{noformat}
It seems the issue is similar to an open JDK bug : 
https://bugs.openjdk.java.net/browse/JDK-8165852

Following are the reference to same kind of issue in *Non-Windows* System but 
sounds related:
# https://bugs.openjdk.java.net/browse/JDK-8165323 - cannot get FileStore in 
chroot environment
# https://bugs.openjdk.java.net/browse/JDK-8165852 - cannot get FileStore for a 
file in overlayfs in Docker
# https://bugs.openjdk.java.net/browse/JDK-8166162 - cannot get FileStore if 
device of path is not in /proc/mounts
# 
http://hg.openjdk.java.net/jdk9/dev/jdk/file/65042b713b12/src/java.base/linux/classes/sun/nio/fs/LinuxFileStore.java
# http://mail.openjdk.java.net/pipermail/nio-dev/2016-October/003915.html

So, I think the PR corresponding to this ticket will take care of both of the 
scenarios without any harm.

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks 

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

@mosermw We may get different result due to  substituted drive, partition 
configuration and a lot more known or unknown reasons.
Historically, java nio has left a trail of a lot of issues/JDK bugs, ex: 
- https://bugs.openjdk.java.net/browse/JDK-8002388
- http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8034057
As of now, I don't know the exact reason for this problem but  I have traced 
that, the constructor for WindowsFileStore freaks during a call to 
{code:java}WindowsNativeDispatcher#GetVolumeInformation{code}, which is a 
native method and likely calling 
https://msdn.microsoft.com/en-us/library/windows/desktop/aa364993(v=vs.85).aspx

So, in current scenario, I wanted to get things running and using io works for 
both of the cases.

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Closed] (NIFI-3587) Nifi build fails for CEF Parser when Language is not English

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee closed NIFI-3587.
---

closing as dup

> Nifi build fails for CEF Parser when Language is not English
> 
>
> Key: NIFI-3587
> URL: https://issues.apache.org/jira/browse/NIFI-3587
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 1.2.0
> Environment: Junit
>Reporter: Puspendu Banerjee
>
> Nifi build fails for CEF Parser when Language is not English. The issue in 
> ParCEFone library has been fixed at version 1.2.1-SNAPSHOT at 
> [GitHub|https://github.com/fluenda/ParCEFone/commit/45d97c1002f2dfcbdc2ddf32e682f8b6a5f30e34]
> [~trixpan] as ParCEFone is your creation, please release a new version and 
> incorporate.
> {quote}
> [pool-1-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
> ParseCEF[id=94d0782a-389f-4830-aff7-5ca1a5df0997] Failed to parse 
> FlowFile[0,197280016436937.mockFlowFile,25B] as a CEF message: it does not 
> conform to the CEF standard; routing to failure
> [pool-2-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
> com.fluenda.parcefone.event.CEFHandlingException: Error setting value to 
> field rt
> [pool-2-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
> ParseCEF[id=5cbfd906-9933-461a-9ea8-5acb57eda4d8] Failed to parse 
> FlowFile[0,197280050157962.mockFlowFile,422B] as a CEF message: it does not 
> conform to the CEF standard; routing to failure
> [pool-3-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
> com.fluenda.parcefone.event.CEFHandlingException: Error setting value to 
> field rt
> [pool-3-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
> ParseCEF[id=ff52d793-ee5b-497e-95a6-422bd27fc3fb] Failed to parse 
> FlowFile[0,197280060692476.mockFlowFile,422B] as a CEF message: it does not 
> conform to the CEF standard; routing to failure
> [pool-4-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
> com.fluenda.parcefone.event.CEFHandlingException: Error setting value to 
> field rt
> [pool-4-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
> ParseCEF[id=83c6c134-04f2-4344-8978-534ef603dfb6] Failed to parse 
> FlowFile[0,197280063882911.mockFlowFile,422B] as a CEF message: it does not 
> conform to the CEF standard; routing to failure
> [pool-5-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
> com.fluenda.parcefone.event.CEFHandlingException: Error setting value to 
> field rt
> [pool-5-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
> ParseCEF[id=f3f25e5f-df5a-4958-831d-f76f0c538185] Failed to parse 
> FlowFile[0,197280066272777.mockFlowFile,422B] as a CEF message: it does not 
> conform to the CEF standard; routing to failure
> [pool-6-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
> com.fluenda.parcefone.event.CEFHandlingException: Error setting value to 
> field rt
> [pool-6-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
> ParseCEF[id=360ff998-772b-4686-9bf5-4f14b187c41a] Failed to parse 
> FlowFile[0,197280073146699.mockFlowFile,529B] as a CEF message: it does not 
> conform to the CEF standard; routing to failure
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3555) UpdateAttribute on filename adds extra space

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3555:
-

[~uwegeercken] Hi! The expression , input and output sample doesn't match, may 
be underscores {noformat}'_'{noformat} before and after the "fragment" literal 
got lost during saving the ticket. 
Please provide correct expression and here goes my scenario, which is working 
correctly:
{noformat}
Expression-->${fname:substringBefore('.'):append('_fragment_'):append(${fragment.index}):append('_details.csv')}<--
Original fname-->allCountries_100.txt<--
Updated fname-->allCountries_100_fragment_33_details.csv<--
{noformat}

> UpdateAttribute on filename adds extra space
> 
>
> Key: NIFI-3555
> URL: https://issues.apache.org/jira/browse/NIFI-3555
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core UI
>Affects Versions: 1.1.1
> Environment: Linux, Fedora 25, Nifi 1.1.1
>Reporter: Uwe Geercken
>Priority: Minor
>
> I have used the GetFile and then SplitText processors to split a csv file 
> into rows.
> Here is the original filename:
> allCountries_100.txt
> Then I have created an Expression in the UpdateAttribute processor:
> ${filename:substringBefore('.'):append('_fragment_'):append(${fragment.index}):append('_details.csv')}
>  
> It creates a new filename by using the original filename plus the fragment 
> number from the SplitText processor and adds a string at the end.
> In the output of the PutFile processor all files have an extra space at the 
> end behing the ".csv".
> here is an example:
> allCountries_100_fragment_35.csv 
> please note the extra space at the end.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

Hi [~mosermw]! 
The ./content_repository actually exists, but NIO based implementation thinks 
that it doesn't, whereas the io based implementation calculates the size 
correctly .
Can you please run the sample code that I have share here.
Here goes my output:
{quote}
==>c:\Users\puspendu
190.77246GB
190.77246GB
==>D:\workspace\nifi
98.96289GB
java.nio.file.NoSuchFileException: D:\workspace\nifi
{quote}

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3587) Nifi build fails for CEF Parser when Language is not English

[Puspendu Banerjee (JIRA)]

Puspendu Banerjee created NIFI-3587:
---

 Summary: Nifi build fails for CEF Parser when Language is not 
English
 Key: NIFI-3587
 URL: https://issues.apache.org/jira/browse/NIFI-3587
 Project: Apache NiFi
  Issue Type: Bug
Affects Versions: 1.2.0
 Environment: Junit
Reporter: Puspendu Banerjee


Nifi build fails for CEF Parser when Language is not English. The issue in 
ParCEFone library has been fixed at version 1.2.1-SNAPSHOT at 
[GitHub|https://github.com/fluenda/ParCEFone/commit/45d97c1002f2dfcbdc2ddf32e682f8b6a5f30e34]
[~trixpan] as ParCEFone is your creation, please release a new version and 
incorporate.

{quote}
[pool-1-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
ParseCEF[id=94d0782a-389f-4830-aff7-5ca1a5df0997] Failed to parse 
FlowFile[0,197280016436937.mockFlowFile,25B] as a CEF message: it does not 
conform to the CEF standard; routing to failure
[pool-2-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
com.fluenda.parcefone.event.CEFHandlingException: Error setting value to field 
rt
[pool-2-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
ParseCEF[id=5cbfd906-9933-461a-9ea8-5acb57eda4d8] Failed to parse 
FlowFile[0,197280050157962.mockFlowFile,422B] as a CEF message: it does not 
conform to the CEF standard; routing to failure
[pool-3-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
com.fluenda.parcefone.event.CEFHandlingException: Error setting value to field 
rt
[pool-3-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
ParseCEF[id=ff52d793-ee5b-497e-95a6-422bd27fc3fb] Failed to parse 
FlowFile[0,197280060692476.mockFlowFile,422B] as a CEF message: it does not 
conform to the CEF standard; routing to failure
[pool-4-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
com.fluenda.parcefone.event.CEFHandlingException: Error setting value to field 
rt
[pool-4-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
ParseCEF[id=83c6c134-04f2-4344-8978-534ef603dfb6] Failed to parse 
FlowFile[0,197280063882911.mockFlowFile,422B] as a CEF message: it does not 
conform to the CEF standard; routing to failure
[pool-5-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
com.fluenda.parcefone.event.CEFHandlingException: Error setting value to field 
rt
[pool-5-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
ParseCEF[id=f3f25e5f-df5a-4958-831d-f76f0c538185] Failed to parse 
FlowFile[0,197280066272777.mockFlowFile,422B] as a CEF message: it does not 
conform to the CEF standard; routing to failure
[pool-6-thread-1] ERROR com.fluenda.parcefone.parser.CEFParser - 
com.fluenda.parcefone.event.CEFHandlingException: Error setting value to field 
rt
[pool-6-thread-1] ERROR org.apache.nifi.processors.standard.ParseCEF - 
ParseCEF[id=360ff998-772b-4686-9bf5-4f14b187c41a] Failed to parse 
FlowFile[0,197280073146699.mockFlowFile,529B] as a CEF message: it does not 
conform to the CEF standard; routing to failure
{quote}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3586) Nifi is not returning PID in Windows

[Puspendu Banerjee (JIRA)]

Puspendu Banerjee created NIFI-3586:
---

 Summary: Nifi is not returning PID in Windows
 Key: NIFI-3586
 URL: https://issues.apache.org/jira/browse/NIFI-3586
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.0.1, 1.1.1, 0.7.0, 0.6.0, 0.5.0, 1.0.0, 1.2.0
 Environment: Java <=8, Windows
Reporter: Puspendu Banerjee
Priority: Minor


Nifi PID is unavailable during startup under Windows



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3579 at 3/10/17 5:34 AM:
--

attached exception Log "app.log" . Search for "Caused by: 
java.nio.file.NoSuchFileException: .\content_repository"


was (Author: puspendu.baner...@gmail.com):
attached exception Log "app.log" 

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3579 at 3/10/17 5:34 AM:
--

[~joewitt] attached exception Log "app.log" . Search for "Caused by: 
java.nio.file.NoSuchFileException: .\content_repository"


was (Author: puspendu.baner...@gmail.com):
attached exception Log "app.log" . Search for "Caused by: 
java.nio.file.NoSuchFileException: .\content_repository"

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3579 at 3/10/17 5:33 AM:
--

[~joewitt] Attaching the Exception log and  PFB a little piece of that:
{quote}
org.apache.nifi.web.NiFiCoreException: Unable to start Flow Controller.
at 
org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:85)
 ~[na:na]
at 
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:837)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:533)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:810)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:345)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:231) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.Server.start(Server.java:411) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.Server.doStart(Server.java:378) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:736) 
[nifi-jetty-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
at org.apache.nifi.NiFi.(NiFi.java:157) 
[nifi-runtime-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
at org.apache.nifi.NiFi.main(NiFi.java:264) 
[nifi-runtime-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
Caused by: org.springframework.beans.factory.BeanCreationException: Error 
creating bean with name 'flowService': FactoryBean threw exception on object 
creation; nested exception is 
org.springframework.beans.factory.BeanCreationException: Error creating bean 
with name 'flowController': FactoryBean threw exception on object creation; 
nested exception is java.lang.RuntimeException: Unable to create Content 

[jira] [Comment Edited] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3579 at 3/10/17 5:30 AM:
--

attached exception Log "app.log" 


was (Author: puspendu.baner...@gmail.com):
Exception Log

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3579:

Attachment: nifi-app.log

Exception Log

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
> Attachments: nifi-app.log
>
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

[~joewitt] Attaching the Exception log and  PFB a little piece of that:
{quote}
2017-03-09 23:23:25,435 WARN [main] org.eclipse.jetty.webapp.WebAppContext 
Failed startup of context 
o.e.j.w.WebAppContext@6edb093f{/nifi-api,file:///D:/workspace/nifi/nifi-assembly/target/nifi-1.2.0-SNAPSHOT-bin/nifi-1.2.0-SNAPSHOT/work/jetty/nifi-web-api-1.2.0-SNAPSHOT.war/webapp/,UNAVAILABLE}{.\work\nar\framework\nifi-framework-nar-1.2.0-SNAPSHOT.nar-unpacked\META-INF\bundled-dependencies\nifi-web-api-1.2.0-SNAPSHOT.war}
org.apache.nifi.web.NiFiCoreException: Unable to start Flow Controller.
at 
org.apache.nifi.web.contextlistener.ApplicationStartupContextListener.contextInitialized(ApplicationStartupContextListener.java:85)
 ~[na:na]
at 
org.eclipse.jetty.server.handler.ContextHandler.callContextInitialized(ContextHandler.java:837)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.callContextInitialized(ServletContextHandler.java:533)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.ContextHandler.startContext(ContextHandler.java:810)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:345)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:772)
 ~[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:262)
 ~[jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520) 
~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:114)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:231) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle.java:132)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.Server.start(Server.java:411) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCycle.java:106)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:61)
 [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.eclipse.jetty.server.Server.doStart(Server.java:378) 
[jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
at 
org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:68)
 [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
at org.apache.nifi.web.server.JettyServer.start(JettyServer.java:736) 
[nifi-jetty-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
at org.apache.nifi.NiFi.(NiFi.java:157) 
[nifi-runtime-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
at org.apache.nifi.NiFi.main(NiFi.java:264) 
[nifi-runtime-1.2.0-SNAPSHOT.jar:1.2.0-SNAPSHOT]
{quote}


> Nifi Failed to 

[jira] [Commented] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3579:
-

Hi[~joewitt] & [~aldrin]!  Can you please find someone or review it.

> Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows
> --
>
> Key: NIFI-3579
> URL: https://issues.apache.org/jira/browse/NIFI-3579
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.2.0, 1.1.1
> Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: windows
>
> Nifi is failing to start due to IOException originating from 
> FileSystemRepository during calls to {code:java}
> Files.getFileStore(path).getTotalSpace();
> Files.getFileStore(path).getUsableSpace();
>  {code} with a read-access denied status.
> It looks like a buggy JDK implementation as on the other hand the following 
> code is yielding result:
> {code:java}
> path.toFile().getTotalSpace();
> path.toFile().getUsableSpace();
> {code}
> Interestingly, the both of the codes are yielding same results for C:\ or 
> System Drive.
> *sample*
> {code:java}
> import java.io.File;
> import java.io.IOException;
> import java.nio.file.Files;
> import java.nio.file.Path;
> import java.nio.file.Paths;
> import java.util.Arrays;
> import static java.lang.System.out;
> public class Blah {
> public static void main(String [] args) throws IOException{
> String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
> final float divisor=1024 * 1024 * 1024f;
> for(String _path : _paths) {
> try {
> Path path = Paths.get(_path);
> out.println(path.toFile().getTotalSpace() /divisor  + "GB");
> out.println(Files.getFileStore(path).getTotalSpace()/divisor 
> +"GB");
> }catch (Exception ex){
> ex.printStackTrace();
> }
> }
> }
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3320) Listen to SNMP Trap

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3320:
-

Hi [~balakrishna_r] ,
Are you working on this fix?

> Listen to SNMP Trap
> ---
>
> Key: NIFI-3320
> URL: https://issues.apache.org/jira/browse/NIFI-3320
> Project: Apache NiFi
>  Issue Type: New Feature
>Affects Versions: 1.1.1
>Reporter: Balakrishnan R
>  Labels: SNMP, Traps
>
> As part NIFI-1537 SNMP Get, Walk and Set were introduced. However SNMP Traps 
> sent to NIFI cannot be converted to a flowfile currently. This is a fairly 
> useful feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Issue Comment Deleted] (NIFI-3320) Listen to SNMP Trap

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3320:

Comment: was deleted

(was: Hi [~balakrishna_r] ,
Are you working on this fix?)

> Listen to SNMP Trap
> ---
>
> Key: NIFI-3320
> URL: https://issues.apache.org/jira/browse/NIFI-3320
> Project: Apache NiFi
>  Issue Type: New Feature
>Affects Versions: 1.1.1
>Reporter: Balakrishnan R
>  Labels: SNMP, Traps
>
> As part NIFI-1537 SNMP Get, Walk and Set were introduced. However SNMP Traps 
> sent to NIFI cannot be converted to a flowfile currently. This is a fairly 
> useful feature.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3448) Issues extracting/running on Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3448:
-

Hi [~aldrin]!
Got it. Same kind of windows problem persists in various places in NiFi. Would 
it be possible for you to  review 
https://issues.apache.org/jira/browse/NIFI-3579.

> Issues extracting/running on Windows
> 
>
> Key: NIFI-3448
> URL: https://issues.apache.org/jira/browse/NIFI-3448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.1.1
>Reporter: Aldrin Piri
>
> A user reported issues running on NiFi on Windows, with a class not being 
> found despite it being presented on the filesystem.
> {quote}
> I downloaded the windows version, extracted into the directory, following
> the 'book' I go to the bin directory and dbl-click run-nifi.bat
> Not being an apache developer, I don't have access to, or know where to
> report such an issue; the "community" has no apparent forum.
> It fails to start properly; the nifi-app.log shows a java class not being
> found:
> java.lang.ClassNotFoundException:
> org.apache.nifi.update.attributes.api.ObjectMapperResolver
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[na:1.8.0_92]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> ~[na:1.8.0_92]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ~[na:1.8.0_92]
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:
> 487) ~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:
> 428) ~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at org.eclipse.jetty.util.Loader.loadClass(Loader.java:86)
> ~[jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(Container
> Initializer.java:130) ~[jetty-plus-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(Se
> rvletContainerInitializersStarter.java:63)
> ~[jetty-annotations-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextH
> andler.java:330) [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:
> 772) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandle
> r.java:262) [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle
> .java:132) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCyc
> le.java:114) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.jav
> a:61) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle
> .java:132) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCyc
> le.java:106) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.jav
> a:61) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:2
> 31) 

[jira] [Commented] (NIFI-3576) QueryElasticsearchHttp should have a "Not Found"/"Zero results" relationship

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3576:
-

[~JPercivall] Shouldn't it still be a success with a blank flowfile?

> QueryElasticsearchHttp should have a "Not Found"/"Zero results" relationship
> 
>
> Key: NIFI-3576
> URL: https://issues.apache.org/jira/browse/NIFI-3576
> Project: Apache NiFi
>  Issue Type: Improvement
>Reporter: Joseph Percivall
>Priority: Minor
>
> In the event of a successful call, QueryElasticsearchHttp always drops the 
> incoming flowfile and then emits pages of results to the success 
> relationship. If the search returns no results then no pages of results are 
> emitted to the success relationship. 
> The processor should offer other options for handling when there are no 
> results returned.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Created] (NIFI-3579) Nifi Failed to Start: nio Files.getFileStore(Path) is buggy in Windows

[Puspendu Banerjee (JIRA)]

Puspendu Banerjee created NIFI-3579:
---

 Summary: Nifi Failed to Start: nio Files.getFileStore(Path) is 
buggy in Windows
 Key: NIFI-3579
 URL: https://issues.apache.org/jira/browse/NIFI-3579
 Project: Apache NiFi
  Issue Type: Bug
  Components: Core Framework
Affects Versions: 1.1.1, 1.2.0
 Environment: Win 10 with Oracle JDK 1.8.0_121 on NTFS
Reporter: Puspendu Banerjee
Assignee: Puspendu Banerjee
Priority: Critical


Nifi is failing to start due to IOException originating from 
FileSystemRepository during calls to {code:java}
Files.getFileStore(path).getTotalSpace();
Files.getFileStore(path).getUsableSpace();
 {code} with a read-access denied status.
It looks like a buggy JDK implementation as on the other hand the following 
code is yielding result:
{code:java}
path.toFile().getTotalSpace();
path.toFile().getUsableSpace();
{code}
Interestingly, the both of the codes are yielding same results for C:\ or 
System Drive.
*sample*
{code:java}
import java.io.File;
import java.io.IOException;
import java.nio.file.Files;
import java.nio.file.Path;
import java.nio.file.Paths;
import java.util.Arrays;
import static java.lang.System.out;
public class Blah {
public static void main(String [] args) throws IOException{
String [] _paths= {"D:\\workspace\\nifi", "c:\\Program Files"};
final float divisor=1024 * 1024 * 1024f;
for(String _path : _paths) {
try {
Path path = Paths.get(_path);
out.println(path.toFile().getTotalSpace() /divisor  + "GB");
out.println(Files.getFileStore(path).getTotalSpace()/divisor 
+"GB");
}catch (Exception ex){
ex.printStackTrace();
}
}

}
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3448) Issues extracting/running on Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3448:

Affects Version/s: 1.1.1

> Issues extracting/running on Windows
> 
>
> Key: NIFI-3448
> URL: https://issues.apache.org/jira/browse/NIFI-3448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.1.1
>Reporter: Aldrin Piri
>
> A user reported issues running on NiFi on Windows, with a class not being 
> found despite it being presented on the filesystem.
> {quote}
> I downloaded the windows version, extracted into the directory, following
> the 'book' I go to the bin directory and dbl-click run-nifi.bat
> Not being an apache developer, I don't have access to, or know where to
> report such an issue; the "community" has no apparent forum.
> It fails to start properly; the nifi-app.log shows a java class not being
> found:
> java.lang.ClassNotFoundException:
> org.apache.nifi.update.attributes.api.ObjectMapperResolver
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[na:1.8.0_92]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> ~[na:1.8.0_92]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ~[na:1.8.0_92]
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:
> 487) ~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:
> 428) ~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at org.eclipse.jetty.util.Loader.loadClass(Loader.java:86)
> ~[jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(Container
> Initializer.java:130) ~[jetty-plus-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(Se
> rvletContainerInitializersStarter.java:63)
> ~[jetty-annotations-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextH
> andler.java:330) [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:
> 772) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandle
> r.java:262) [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle
> .java:132) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCyc
> le.java:114) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.jav
> a:61) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle
> .java:132) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCyc
> le.java:106) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.jav
> a:61) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:2
> 31) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]

[jira] [Commented] (NIFI-3448) Issues extracting/running on Windows

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3448:
-

[~aldrin] Please provide Windows version, Java version, Administrative User or 
General user.

> Issues extracting/running on Windows
> 
>
> Key: NIFI-3448
> URL: https://issues.apache.org/jira/browse/NIFI-3448
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Aldrin Piri
>
> A user reported issues running on NiFi on Windows, with a class not being 
> found despite it being presented on the filesystem.
> {quote}
> I downloaded the windows version, extracted into the directory, following
> the 'book' I go to the bin directory and dbl-click run-nifi.bat
> Not being an apache developer, I don't have access to, or know where to
> report such an issue; the "community" has no apparent forum.
> It fails to start properly; the nifi-app.log shows a java class not being
> found:
> java.lang.ClassNotFoundException:
> org.apache.nifi.update.attributes.api.ObjectMapperResolver
> at
> java.net.URLClassLoader.findClass(URLClassLoader.java:381) ~[na:1.8.0_92]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> ~[na:1.8.0_92]
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> ~[na:1.8.0_92]
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:
> 487) ~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppClassLoader.loadClass(WebAppClassLoader.java:
> 428) ~[jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at org.eclipse.jetty.util.Loader.loadClass(Loader.java:86)
> ~[jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.plus.annotation.ContainerInitializer.callStartup(Container
> Initializer.java:130) ~[jetty-plus-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.annotations.ServletContainerInitializersStarter.doStart(Se
> rvletContainerInitializersStarter.java:63)
> ~[jetty-annotations-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextH
> andler.java:330) [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1404)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1366)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:
> 772) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandle
> r.java:262) [jetty-servlet-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:520)
> [jetty-webapp-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle
> .java:132) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCyc
> le.java:114) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.jav
> a:61) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.j
> ava:68) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.start(ContainerLifeCycle
> .java:132) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.util.component.ContainerLifeCycle.doStart(ContainerLifeCyc
> le.java:106) [jetty-util-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.jav
> a:61) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> org.eclipse.jetty.server.handler.gzip.GzipHandler.doStart(GzipHandler.java:2
> 31) [jetty-server-9.3.9.v20160517.jar:9.3.9.v20160517]
> at
> 

[jira] [Comment Edited] (NIFI-3512) issue with date in putsql

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3512 at 3/9/17 2:35 AM:
-

[~teja0312] Could you please create a sample flowfile to emulate the issue and 
share?
I assume you are passing one of Formats ex. ISO_LOCAL_DATE or 
"-MM-dd'T'HH:mm:ssXXX" etc.


was (Author: puspendu.baner...@gmail.com):
[~teja0312] Could you please create a sample flowfile to emulate the issue and 
share?
I assume you are passing one of Predefined Formatters ex. ISO_LOCAL_DATE etc.

> issue with date in putsql
> -
>
> Key: NIFI-3512
> URL: https://issues.apache.org/jira/browse/NIFI-3512
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.1.1
> Environment: windows
>Reporter: raviteja
>Assignee: Puspendu Banerjee
> Fix For: 1.1.1
>
> Attachments: NIFIdatepng.png
>
>
> Hi
> I'm trying to transfer DB to DB with data column (datatype) in it .
> I tried putting attribute " ${my.date.string:format('-MM-dd')} " in 
> update attribute got some error in PUTSQL, its not updating the value into 
> database.
> please find the image of my dataflow in the attachment
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NIFI-3512) issue with date in putsql

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3512 at 3/9/17 2:10 AM:
-

[~teja0312] Could you please create a sample flowfile to emulate the issue and 
share?
I assume you are passing one of Predefined Formatters ex. ISO_LOCAL_DATE etc.


was (Author: puspendu.baner...@gmail.com):
[~teja0312] Could you please create a sample flowfile to emulate the issue and 
share?

> issue with date in putsql
> -
>
> Key: NIFI-3512
> URL: https://issues.apache.org/jira/browse/NIFI-3512
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.1.1
> Environment: windows
>Reporter: raviteja
>Assignee: Puspendu Banerjee
> Fix For: 1.1.1
>
> Attachments: NIFIdatepng.png
>
>
> Hi
> I'm trying to transfer DB to DB with data column (datatype) in it .
> I tried putting attribute " ${my.date.string:format('-MM-dd')} " in 
> update attribute got some error in PUTSQL, its not updating the value into 
> database.
> please find the image of my dataflow in the attachment
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3512) issue with date in putsql

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3512:
-

[~teja0312] Could you please create a sample flowfile to emulate the issue and 
share?

> issue with date in putsql
> -
>
> Key: NIFI-3512
> URL: https://issues.apache.org/jira/browse/NIFI-3512
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.1.1
> Environment: windows
>Reporter: raviteja
>Assignee: Puspendu Banerjee
> Fix For: 1.1.1
>
> Attachments: NIFIdatepng.png
>
>
> Hi
> I'm trying to transfer DB to DB with data column (datatype) in it .
> I tried putting attribute " ${my.date.string:format('-MM-dd')} " in 
> update attribute got some error in PUTSQL, its not updating the value into 
> database.
> please find the image of my dataflow in the attachment
> Thanks



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Assigned] (NIFI-3535) Use keytab for local filesystem

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee reassigned NIFI-3535:
---

Assignee: Puspendu Banerjee

> Use keytab for local filesystem
> ---
>
> Key: NIFI-3535
> URL: https://issues.apache.org/jira/browse/NIFI-3535
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1, 1.0.1
> Environment: ie redhat
>Reporter: Sunile Manjee
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: authentication, kerbeos, security
>
> For enterprises which require strict access control to local file systems, 
> the requirement is to enable nifi processors which access local file system 
> to use keytab or another process to use user account which was used during 
> nifi authentication.   without such enforcement all users within a restricted 
> group have access to full local file system via nifi processor.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3535) Use keytab for local filesystem

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3535:
-

[~sunileman...@gmail.com] Could you please explain {quote}use user account 
which was used during nifi authentication{quote}.
If you have meant that the UI user, then someone must log-in to NiFi, which 
might not be the case for production/server boxes.
In stead of that, I would recommend you to run NiFi on Docker like container.


> Use keytab for local filesystem
> ---
>
> Key: NIFI-3535
> URL: https://issues.apache.org/jira/browse/NIFI-3535
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Core Framework
>Affects Versions: 1.1.1, 1.0.1
> Environment: ie redhat
>Reporter: Sunile Manjee
>Priority: Critical
>  Labels: authentication, kerbeos, security
>
> For enterprises which require strict access control to local file systems, 
> the requirement is to enable nifi processors which access local file system 
> to use keytab or another process to use user account which was used during 
> nifi authentication.   without such enforcement all users within a restricted 
> group have access to full local file system via nifi processor.  



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3562) Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3562:

Description: 
Whenever a component, build or test is running having Files.getFileStore, java 
is throwing exception and the process fails. PFB:
{code:java}
java> import java.nio.file.*;
Imported java.nio.file.*
java> Path p= 
FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
java> Files.getFileStore(p);
java.io.IOException: Mount point not found
{code}

An active bug is there on JDK side 
https://bugs.openjdk.java.net/browse/JDK-8165852.

The same issue is present with  *btrfs* .
For Nifi, either 
- we should halt support for Docker container unless that issue is getting 
fixed or 
- need to modify our code and use *java.io.File* wherever needed or
- we can just ignore assuming none else is using overlayfs2 :D or
- we can explicitly state it as a known issue and workaround could be using 
*aufs* as *storage driver* for Docker, in corresponding nifi user manual.

  was:
Whenever a component, build or test is running having Files.getFileStore, java 
is throwing exception and the process fails. PFB:
{code:java}
java> import java.nio.file.*;
Imported java.nio.file.*
java> Path p= 
FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
java> Files.getFileStore(p);
java.io.IOException: Mount point not found
{code}

An active bug is there on JDK side 
https://bugs.openjdk.java.net/browse/JDK-8165852.

The same issue is present with  *btrfs* .
For Nifi, either 
- we should halt support for Docker container unless that issue is getting 
fixed or 
- need to modify our code and use *java.io.File* wherever needed or
- we can just ignore assuming none else is using overlayfs2 :D or
- we can explicitly state it as a known issue in corresponding nifi user manual.


> Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS
> --
>
> Key: NIFI-3562
> URL: https://issues.apache.org/jira/browse/NIFI-3562
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Extensions, Tools and Build
>Affects Versions: 1.2.0
> Environment: CentOS 7 on Docker 17.03.0-ce-win1 (10296) with 
> overlayfs.
> Java build 1.8.0_121-b13, Oracle
>Reporter: Puspendu Banerjee
>  Labels: docker, overlayfs
>
> Whenever a component, build or test is running having Files.getFileStore, 
> java is throwing exception and the process fails. PFB:
> {code:java}
> java> import java.nio.file.*;
> Imported java.nio.file.*
> java> Path p= 
> FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
> java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
> java> Files.getFileStore(p);
> java.io.IOException: Mount point not found
> {code}
> An active bug is there on JDK side 
> https://bugs.openjdk.java.net/browse/JDK-8165852.
> The same issue is present with  *btrfs* .
> For Nifi, either 
> - we should halt support for Docker container unless that issue is getting 
> fixed or 
> - need to modify our code and use *java.io.File* wherever needed or
> - we can just ignore assuming none else is using overlayfs2 :D or
> - we can explicitly state it as a known issue and workaround could be using 
> *aufs* as *storage driver* for Docker, in corresponding nifi user manual.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Comment Edited] (NIFI-3562) Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee edited comment on NIFI-3562 at 3/7/17 8:36 AM:
-

just tested on AuFS and so far it looks good

{code:java}
java> Path p= FileSystems.getDefault().getPath("/tmp")
java.nio.file.Path p = /tmp
java> FileStore fst=Files.getFileStore(p);
java.nio.file.FileStore fst = / (none)
java> fst.getTotalSpace()
java.lang.Long res4 = 63143981056
{code}


was (Author: puspendu.baner...@gmail.com):
just tested on AuFS and so far it looks good

> Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS
> --
>
> Key: NIFI-3562
> URL: https://issues.apache.org/jira/browse/NIFI-3562
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Extensions, Tools and Build
>Affects Versions: 1.2.0
> Environment: CentOS 7 on Docker 17.03.0-ce-win1 (10296) with 
> overlayfs.
> Java build 1.8.0_121-b13, Oracle
>Reporter: Puspendu Banerjee
>  Labels: docker, overlayfs
>
> Whenever a component, build or test is running having Files.getFileStore, 
> java is throwing exception and the process fails. PFB:
> {code:java}
> java> import java.nio.file.*;
> Imported java.nio.file.*
> java> Path p= 
> FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
> java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
> java> Files.getFileStore(p);
> java.io.IOException: Mount point not found
> {code}
> An active bug is there on JDK side 
> https://bugs.openjdk.java.net/browse/JDK-8165852.
> The same issue is present with  *btrfs* .
> For Nifi, either 
> - we should halt support for Docker container unless that issue is getting 
> fixed or 
> - need to modify our code and use *java.io.File* wherever needed or
> - we can just ignore assuming none else is using overlayfs2 :D or
> - we can explicitly state it as a known issue in corresponding nifi user 
> manual.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-3562) Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-3562:
-

just tested on AuFS and so far it looks good

> Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS
> --
>
> Key: NIFI-3562
> URL: https://issues.apache.org/jira/browse/NIFI-3562
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Extensions, Tools and Build
>Affects Versions: 1.2.0
> Environment: CentOS 7 on Docker 17.03.0-ce-win1 (10296) with 
> overlayfs.
> Java build 1.8.0_121-b13, Oracle
>Reporter: Puspendu Banerjee
>  Labels: docker, overlayfs
>
> Whenever a component, build or test is running having Files.getFileStore, 
> java is throwing exception and the process fails. PFB:
> {code:java}
> java> import java.nio.file.*;
> Imported java.nio.file.*
> java> Path p= 
> FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
> java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
> java> Files.getFileStore(p);
> java.io.IOException: Mount point not found
> {code}
> An active bug is there on JDK side 
> https://bugs.openjdk.java.net/browse/JDK-8165852.
> The same issue is present with  *btrfs* .
> For Nifi, either 
> - we should halt support for Docker container unless that issue is getting 
> fixed or 
> - need to modify our code and use *java.io.File* wherever needed or
> - we can just ignore assuming none else is using overlayfs2 :D or
> - we can explicitly state it as a known issue in corresponding nifi user 
> manual.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Updated] (NIFI-3562) Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-3562:

Description: 
Whenever a component, build or test is running having Files.getFileStore, java 
is throwing exception and the process fails. PFB:
{code:java}
java> import java.nio.file.*;
Imported java.nio.file.*
java> Path p= 
FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
java> Files.getFileStore(p);
java.io.IOException: Mount point not found
{code}

An active bug is there on JDK side 
https://bugs.openjdk.java.net/browse/JDK-8165852.

The same issue is present with  *btrfs* .
For Nifi, either 
- we should halt support for Docker container unless that issue is getting 
fixed or 
- need to modify our code and use *java.io.File* wherever needed or
- we can just ignore assuming none else is using overlayfs2 :D or
- we can explicitly state it as a known issue in corresponding nifi user manual.

  was:
Whenever a component, build or test is running having Files.getFileStore, java 
is throwing exception and the process fails. PFB:
{code:java}
java> import java.nio.file.*;
Imported java.nio.file.*
java> Path p= 
FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
java> Files.getFileStore(p);
java.io.IOException: Mount point not found
{code}

An active bug is there on JDK side 
https://bugs.openjdk.java.net/browse/JDK-8165852.

The same issue is present with  *btrfs* and possibly AuFS.
For Nifi, either 
- we should halt support for Docker container unless that issue is getting 
fixed or 
- need to modify our code and use *java.io.File* wherever needed or
- we can just ignore assuming none complained :D


> Nifi on Docker fails due to use of NIO Files.getFileStore on OverlayFS
> --
>
> Key: NIFI-3562
> URL: https://issues.apache.org/jira/browse/NIFI-3562
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework, Extensions, Tools and Build
>Affects Versions: 1.2.0
> Environment: CentOS 7 on Docker 17.03.0-ce-win1 (10296) with 
> overlayfs.
> Java build 1.8.0_121-b13, Oracle
>Reporter: Puspendu Banerjee
>  Labels: docker, overlayfs
>
> Whenever a component, build or test is running having Files.getFileStore, 
> java is throwing exception and the process fails. PFB:
> {code:java}
> java> import java.nio.file.*;
> Imported java.nio.file.*
> java> Path p= 
> FileSystems.getDefault().getPath("/home/puspendu/src/nifi","LICENSE")
> java.nio.file.Path p = /home/puspendu/src/nifi/LICENSE
> java> Files.getFileStore(p);
> java.io.IOException: Mount point not found
> {code}
> An active bug is there on JDK side 
> https://bugs.openjdk.java.net/browse/JDK-8165852.
> The same issue is present with  *btrfs* .
> For Nifi, either 
> - we should halt support for Docker container unless that issue is getting 
> fixed or 
> - need to modify our code and use *java.io.File* wherever needed or
> - we can just ignore assuming none else is using overlayfs2 :D or
> - we can explicitly state it as a known issue in corresponding nifi user 
> manual.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

[jira] [Commented] (NIFI-1977) Property descriptors without explicit validators are not recognized

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1977:
-

As per documentation, validation should happen:
https://github.com/apache/nifi/blob/master/nifi-api/src/main/java/org/apache/nifi/components/PropertyDescriptor.java#L90


> Property descriptors without explicit validators are not recognized
> ---
>
> Key: NIFI-1977
> URL: https://issues.apache.org/jira/browse/NIFI-1977
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.6.1
>Reporter: Andrew Grande
>
> Looks like a bug in a testing framework.
> I have a simple test case like this one:
> {code:java}
> @Test
> public void customHeader() {
> final TestRunner runner = 
> TestRunners.newTestRunner(ParseCSVRecord.class);
> runner.setProperty(PROP_CUSTOM_HEADER, "Column 1,Column 2");
> runner.enqueue("row1col1,row1col2\nrow2col1, row2col2");
> runner.run();
> {code}
> When a property is declared without an explicit validator, the test runner 
> fails complaining that Custom Header is not a supported property (yes, I've 
> added it to the descriptors list).
> {code:java}
> public static final PropertyDescriptor PROP_CUSTOM_HEADER = new 
> PropertyDescriptor.Builder()
> .name("Custom Header")
> .description("Use this header (delimited according to set rules) instead of 
> auto-discovering it from schema")
> .required(false)  
>   .expressionLanguageSupported(true)
> .build();
> {code}
> The intent here is to not have a validator declared, but rather implement 
> more complex logic in the customValidate() callback, but the test never gets 
> to that point.



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

[~evega] Any chance to review it again?

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-1977) Property descriptors without explicit validators are not recognized

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1977:
-

Let me look through it tonight.

> Property descriptors without explicit validators are not recognized
> ---
>
> Key: NIFI-1977
> URL: https://issues.apache.org/jira/browse/NIFI-1977
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.6.1
>Reporter: Andrew Grande
>
> Looks like a bug in a testing framework.
> I have a simple test case like this one:
> {code:java}
> @Test
> public void customHeader() {
> final TestRunner runner = 
> TestRunners.newTestRunner(ParseCSVRecord.class);
> runner.setProperty(PROP_CUSTOM_HEADER, "Column 1,Column 2");
> runner.enqueue("row1col1,row1col2\nrow2col1, row2col2");
> runner.run();
> {code}
> When a property is declared without an explicit validator, the test runner 
> fails complaining that Custom Header is not a supported property (yes, I've 
> added it to the descriptors list).
> {code:java}
> public static final PropertyDescriptor PROP_CUSTOM_HEADER = new 
> PropertyDescriptor.Builder()
> .name("Custom Header")
> .description("Use this header (delimited according to set rules) instead of 
> auto-discovering it from schema")
> .required(false)  
>   .expressionLanguageSupported(true)
> .build();
> {code}
> The intent here is to not have a validator declared, but rather implement 
> more complex logic in the customValidate() callback, but the test never gets 
> to that point.



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

Understood.. Looks like I had modified it based on old 0.x release.
So, re-oped a PR for 1.x. at https://github.com/apache/nifi/pull/675
Please review. I shall test it on a box at my side as well.


Thanks & Regards,
Puspendu Banerjee

On Tue, Jul 19, 2016 at 9:55 AM, ASF GitHub Bot (JIRA) 



> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

If you use "nifi.sh install" it will be installed as a service.Then you can 
call "status" action.
Correct me, if we are not on same page.

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

Before using from init.d, you need to install it as a service

Thanks & Regards,
Puspendu Banerjee




> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Updated] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-2163:

Attachment: (was: 670.patch)

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Updated] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-2163:

Fix Version/s: (was: 1.0.0)
   Status: In Progress  (was: Patch Available)

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 0.7.0, 1.0.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Updated] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee updated NIFI-2163:

Attachment: 670.patch

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
> Fix For: 1.0.0
>
> Attachments: 670.patch
>
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

[~evega] Please review the patch for status.

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 1.0.0, 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>  Labels: platform-consistency
> Fix For: 1.0.0
>
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

[~evega] I shall  touch-base with you for review, sometime next week.


> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Assignee: Puspendu Banerjee
>Priority: Critical
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Closed] (NIFI-1989) Need to align commons-io artifact group as per MVNCENTRAL-244

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee closed NIFI-1989.
---

Closing as resolved

> Need to align commons-io artifact group as per MVNCENTRAL-244
> -
>
> Key: NIFI-1989
> URL: https://issues.apache.org/jira/browse/NIFI-1989
> Project: Apache NiFi
>  Issue Type: Improvement
>  Components: Tools and Build
>Affects Versions: 1.0.0
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
>Priority: Minor
>  Labels: artifact, dependency, maven
> Fix For: 1.0.0
>
>
> [WARNING] While downloading org.apache.commons:commons-io:1.3.2
>   This artifact has been relocated to commons-io:commons-io:1.3.2.
>   https://issues.sonatype.org/browse/MVNCENTRAL-244



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

Thanks.
I shall look into the following statement from LSB "start, stop, restart,
force-reload, and status actions shall be supported by all init scripts;
the reload and the try-restart actions are optional."

Will that satisfy your need?

Thanks & Regards,
Puspendu Banerjee
On Jul 13, 2016 7:30 PM, "Edgardo Vega (JIRA)"  wrote:


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

Edgardo Vega commented on NIFI-2163:


[~puspendu.baner...@gmail.com] Ansible and puppet for starters.

Here is the link to the service module for ansible:
https://github.com/ansible/ansible-modules-core/blob/devel/system/service.py#L582
Here the link to the service type for puppet:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/type/service.rb#L135

they do not follow the spec for services, whcih causes some configuration
tools not to work as they use the return codes to determine if things are
running, dead, or stopped.
http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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


> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Priority: Critical
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-1638) Unable to TAR a file that is larger than 8GB

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1638:
-

[~john5634] Please share more details, e.g. exact error log etc.

> Unable to TAR a file that is larger than 8GB
> 
>
> Key: NIFI-1638
> URL: https://issues.apache.org/jira/browse/NIFI-1638
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Extensions
>Affects Versions: 0.4.0, 0.5.1
> Environment: RHEL 7, Dell 730xd server
>Reporter: John Teabo
>
> I get an error when trying to create a flow file tar v1 of a file that is 
> larger than 8GB. Is there a way to allow the tarring of files larger than 
> 8GB. Due to the nature of our project we need the attributes of split files 
> and their parent files to be kept. I have been tarring all files that come in 
> NiFi and then splitting the packages then taring the splits for 
> reconstitution after being written to a directory on the server, then 
> processed by another application, then the next instance of NiFi Takes over. 
> unpacks the splits and reconstitutes the original package file with its 
> attributes since I packaged it in a flowfile tar v1.
> Any help will be greatly appreciated!



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

[jira] [Commented] (NIFI-1977) Property descriptors without explicit validators are not recognized

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1977:
-

[~aperepel] May be, you have already done it, but trying to re-confirm that you 
have included that in getter for PropertyDescriptors.

> Property descriptors without explicit validators are not recognized
> ---
>
> Key: NIFI-1977
> URL: https://issues.apache.org/jira/browse/NIFI-1977
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 0.6.1
>Reporter: Andrew Grande
>
> Looks like a bug in a testing framework.
> I have a simple test case like this one:
> {code:java}
> @Test
> public void customHeader() {
> final TestRunner runner = 
> TestRunners.newTestRunner(ParseCSVRecord.class);
> runner.setProperty(PROP_CUSTOM_HEADER, "Column 1,Column 2");
> runner.enqueue("row1col1,row1col2\nrow2col1, row2col2");
> runner.run();
> {code}
> When a property is declared without an explicit validator, the test runner 
> fails complaining that Custom Header is not a supported property (yes, I've 
> added it to the descriptors list).
> {code:java}
> public static final PropertyDescriptor PROP_CUSTOM_HEADER = new 
> PropertyDescriptor.Builder()
> .name("Custom Header")
> .description("Use this header (delimited according to set rules) instead of 
> auto-discovering it from schema")
> .required(false)  
>   .expressionLanguageSupported(true)
> .build();
> {code}
> The intent here is to not have a validator declared, but rather implement 
> more complex logic in the customValidate() callback, but the test never gets 
> to that point.



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

[jira] [Commented] (NIFI-2034) NiFi is always loading a specific version of httpcore to classpath

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2034:
-

It looks pretty interesting. 
[~asanka] Can you please share your code-base if possible. Looks like, somehow 
it's not the correct classloader that is being used.

> NiFi is always loading a specific version of httpcore to classpath
> --
>
> Key: NIFI-2034
> URL: https://issues.apache.org/jira/browse/NIFI-2034
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 0.5.1, 0.6.1
>Reporter: asanka sanjaya
>
> We have written a custom nifi processor to connect to microsoft exchange 
> server and get emails. It runs perfectly as a standalone application. But 
> nifi always loads httpcore-4.4.1.jar and httpclient-4.4.1.jar to classpath 
> even though the nar file contains httpcore-4.4.4.jar and httpclient-4.5.2.jar.
> Because of that, it throws this error.
> 016-06-15 18:57:17,086 WARN [Timer-Driven Process Thread-4] 
> o.a.n.c.t.ContinuallyRunProcessorTask Administratively Yielding 
> NiFiJournalJob[id=52616329-d64c-4e14-bcb1-4c799891682a] due to uncaught 
> Exception: java.lang.NoSuchFieldError: INSTANCE
> 2016-06-15 18:57:17,091 WARN [Timer-Driven Process Thread-4] 
> o.a.n.c.t.ContinuallyRunProcessorTask 
> java.lang.NoSuchFieldError: INSTANCE
>   at 
> org.apache.http.impl.io.DefaultHttpRequestWriterFactory.(DefaultHttpRequestWriterFactory.java:52)
>  ~[httpcore-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.io.DefaultHttpRequestWriterFactory.(DefaultHttpRequestWriterFactory.java:56)
>  ~[httpcore-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.io.DefaultHttpRequestWriterFactory.(DefaultHttpRequestWriterFactory.java:46)
>  ~[httpcore-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:82)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:95)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:104)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.ManagedHttpClientConnectionFactory.(ManagedHttpClientConnectionFactory.java:62)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.BasicHttpClientConnectionManager.(BasicHttpClientConnectionManager.java:142)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.BasicHttpClientConnectionManager.(BasicHttpClientConnectionManager.java:128)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> org.apache.http.impl.conn.BasicHttpClientConnectionManager.(BasicHttpClientConnectionManager.java:157)
>  ~[httpclient-4.4.1.jar:4.4.1]
>   at 
> microsoft.exchange.webservices.data.core.ExchangeServiceBase.initializeHttpClient(ExchangeServiceBase.java:199)
>  ~[na:na]
>   at 
> microsoft.exchange.webservices.data.core.ExchangeServiceBase.(ExchangeServiceBase.java:174)
>  ~[na:na]
>   at 
> microsoft.exchange.webservices.data.core.ExchangeServiceBase.(ExchangeServiceBase.java:179)
>  ~[na:na]
>   at 
> microsoft.exchange.webservices.data.core.ExchangeService.(ExchangeService.java:3729)
>  ~[na:na]
>   



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

[jira] [Commented] (NIFI-2079) Cannot insert ISO dates correctly

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2079:
-

[~asanka] can you please check it with latest version or mainline 1.0. 
If you can share a test-case that will be great.

> Cannot insert ISO dates correctly
> -
>
> Key: NIFI-2079
> URL: https://issues.apache.org/jira/browse/NIFI-2079
> Project: Apache NiFi
>  Issue Type: Bug
>Affects Versions: 0.6.1
>Reporter: asanka sanjaya
>
> When try to insert an ISO date to a mongo collection, it always saved as a 
> String instead of ISODate object.



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

[jira] [Commented] (NIFI-2163) Nifi Service does not follow LSB Sevice Spec

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-2163:
-

[~evega] Please put more detail on tools those can not detect status of the 
service.

> Nifi Service does not follow LSB Sevice Spec
> 
>
> Key: NIFI-2163
> URL: https://issues.apache.org/jira/browse/NIFI-2163
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Configuration
>Affects Versions: 0.7.0
> Environment: Centos
>Reporter: Edgardo Vega
>Priority: Critical
>
> Trying to use the lastest off master with nifi.sh and nifi-env.sh and they do 
> not follow the spec for services, whcih causes some configuration tools not 
> to work as they use the return codes to determine if things are running, 
> dead, or stopped.
> http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptact.html



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

[jira] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1152:
-

[~markap14] I think, you may close the ticket.

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



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

[jira] [Commented] (NIFI-1152) StandardProcessSession and MockProcessSession should handle transfer to unregistered relationship correctly

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1152:
-

Sorry for delay in reply. It's all good.

> StandardProcessSession and MockProcessSession should handle transfer to 
> unregistered relationship correctly
> ---
>
> Key: NIFI-1152
> URL: https://issues.apache.org/jira/browse/NIFI-1152
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Tools and Build
>Affects Versions: 1.0.0, 0.6.0, 0.7.0, 0.6.1
>Reporter: Mark Payne
>Assignee: Joseph Witt
>  Labels: beginner, newbie
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> If a processor calls ProcessSession.transfer(flowFile, 
> NON_EXISTENT_RELATIONSHIP) the NiFi framework will throw a 
> FlowFileHandlingException. However, the Mock Framework simply allows it and 
> does not throw any sort of Exception. This needs to be addressed so that the 
> Mock framework functions the same way as the normal NiFi framework.



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

[jira] [Closed] (NIFI-2117) Implementation gap of relationships in Script Processor

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee closed NIFI-2117.
---

Closing as resolved as part of 1152

> Implementation gap of relationships in Script Processor
> ---
>
> Key: NIFI-2117
> URL: https://issues.apache.org/jira/browse/NIFI-2117
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.6.0, 0.7.0
>Reporter: Puspendu Banerjee
>Assignee: Puspendu Banerjee
> Fix For: 1.0.0
>
>
> Javadoc/Contract for invoke scripted processor says t {quote} * Returns the 
> valid relationships for this processor. SUCCESS and FAILURE are always 
> returned, and if the script
>  * processor has defined additional relationships, those will be added as 
> well.{quote}
> but does not return defaults if additional relationships have been added.



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

[jira] [Commented] (NIFI-1838) Groovy Test Scripts will require refactoring if we implement NIFI-1152

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1838:
-

Agreed. At the same time I think, that PR can be merged into apache/nifi
repo.
After that we can go ahead to fix/re-walk related implementation gaps.


Thanks & Regards,
Puspendu Banerjee




> Groovy Test Scripts will require refactoring if we implement NIFI-1152
> --
>
> Key: NIFI-1838
> URL: https://issues.apache.org/jira/browse/NIFI-1838
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.6.1
>Reporter: Puspendu Banerjee
>  Labels: patch
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> Groovy Test Scripts will require refractoring we implement NIFI-1152 as they 
> don't define Relationships properly



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

[jira] [Commented] (NIFI-1838) Groovy Test Scripts will require refactoring if we implement NIFI-1152

[Puspendu Banerjee (JIRA)]

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

Puspendu Banerjee commented on NIFI-1838:
-

My thought process was that the way, these 3 Jira tickets are related are
highly cohesive.


Thanks & Regards,
Puspendu Banerjee

On Tue, Jul 12, 2016 at 1:42 PM, ASF GitHub Bot (JIRA) 



> Groovy Test Scripts will require refactoring if we implement NIFI-1152
> --
>
> Key: NIFI-1838
> URL: https://issues.apache.org/jira/browse/NIFI-1838
> Project: Apache NiFi
>  Issue Type: Bug
>  Components: Core Framework
>Affects Versions: 1.0.0, 0.6.1
>Reporter: Puspendu Banerjee
>  Labels: patch
> Fix For: 1.0.0
>
> Attachments: 
> 0001-Fix-for-NIFI-1838-NIFI-1152-Code-modification-for-ty.patch
>
>
> Groovy Test Scripts will require refractoring we implement NIFI-1152 as they 
> don't define Relationships properly



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