Re: Handling incoming file names that contain embedded spaces

2016-12-14 Thread James McMahon
Yes indeed Joe, it appears from the logs that there are non-ASCII unicode
characters preceding and at end of the file name. The log shows them as odd
representations of "unprintables" - for example, small inverted question
marks in diamonds, etc etc. They are embedded in the file names by the
application that created the files. I copied and tried to paste and save
into a text file, and notepad directed me to switch to another encoding in
order to save the file name string. I was able to get it to save by
switching to Unicode encoding.

I can't send the logs from my system. I can only relay this in this way.
Would you expect that such character encoding would cause problems for
GetFile? What alternatives do I have to work around this problem? Thank you
once again.

On Wed, Dec 14, 2016 at 6:04 PM, Joe Witt  wrote:

> James,
>
> I suspect there is more to the issue than the spaces.  GetFile itself
> should be fine there.  Can you share logs showing what is happening
> with these files?  Can you share some sample filenames that it is
> struggling with?  You can also enable debug logging for that processor
> which could provide some interesting details as well.
>
> Thanks
> Joe
>
> On Wed, Dec 14, 2016 at 5:03 PM, James McMahon 
> wrote:
> > I am using NiFi 0.6.1. I am trying to use GetFile to read in a large
> series
> > of files I have preprocessed outside of NiFi from zip files using bash
> shell
> > commands. GetFile is throwing errors on many of these files because the
> > files contain embedded spaces. Is there a way to tell NiFi to handle each
> > such filename with surrounding single quotes? Are there other processor
> > options better suited to handle this challenge? Thank you.
>


Re: Handling incoming file names that contain embedded spaces

2016-12-14 Thread Joe Witt
James,

I suspect there is more to the issue than the spaces.  GetFile itself
should be fine there.  Can you share logs showing what is happening
with these files?  Can you share some sample filenames that it is
struggling with?  You can also enable debug logging for that processor
which could provide some interesting details as well.

Thanks
Joe

On Wed, Dec 14, 2016 at 5:03 PM, James McMahon  wrote:
> I am using NiFi 0.6.1. I am trying to use GetFile to read in a large series
> of files I have preprocessed outside of NiFi from zip files using bash shell
> commands. GetFile is throwing errors on many of these files because the
> files contain embedded spaces. Is there a way to tell NiFi to handle each
> such filename with surrounding single quotes? Are there other processor
> options better suited to handle this challenge? Thank you.


Handling incoming file names that contain embedded spaces

2016-12-14 Thread James McMahon
I am using NiFi 0.6.1. I am trying to use GetFile to read in a large series
of files I have preprocessed outside of NiFi from zip files using bash
shell commands. GetFile is throwing errors on many of these files because
the files contain embedded spaces. Is there a way to tell NiFi to handle
each such filename with surrounding single quotes? Are there other
processor options better suited to handle this challenge? Thank you.


Re: File causes unexpected stoppage in play

2016-12-14 Thread Oleg Zhurakousky
James

This article should help you get started 
https://cwiki.apache.org/confluence/display/NIFI/Maven+Projects+for+Extensions 
especially since you only have to go through the first part only “Maven 
Processor Archetype” (I am assuming you are familiar with maven).
Also, make sure that you pick the right NiFi version when executing 'mvn 
archetype. . .’  command. The current website example use 1.0.0. Change it to 
0.6.1 (see below).

$> mvn archetype:generate -DarchetypeGroupId=org.apache.nifi 
-DarchetypeArtifactId=nifi-processor-bundle-archetype -DarchetypeVersion=0.6.1 
-DnifiVersion=0.6.1

After that you may want to copy the UnpackContent into some package within he 
bundle, rename it, adjust the class path to ensure it compiles and build. Make 
sure you add/modify your processor’s name in 
src/main/resources/META-INF/services/org.apache.nifi.processor.Processor file.

Iet me know if you run into any issues.
Cheers
Oleg


On Dec 14, 2016, at 3:08 PM, James McMahon 
mailto:jsmcmah...@gmail.com>> wrote:

I've never tried to create and deploy my own custom bundle but would like to 
try #3 as you recommend Oleg. If you can offer guidance to that process let me 
try that. Thank you. -Jim

On Wed, Dec 14, 2016 at 2:57 PM, Oleg Zhurakousky 
mailto:ozhurakou...@hortonworks.com>> wrote:
James

Not sure what kind of liberties you have with your environment, but here is 
what you can do outside of full upgrade.

1. You can download and drop the bundle (NAR) from NiFi 0.7 release into 0.6 
release. That should work (just replace it in the ‘lib’ directory of NiFi 
home). However, this particular component is located in ’nifi-standard-nar’ 
which means it contains majority of the processors and controller services that 
come with NiFi. So while upgrading one component you will essentially upgrade 
almost all and I am not sure what it may lead to, but you can definitely try.

2.  You can certainly checkout the NiFi 0.6.1 source from the repo and apply 
the same patch on UpdateContent, build NAR and replace it as described in the 
step above, Even though you’ll still be replacing the entire NAR the changes 
are only going to be in that single component.

3.  You can create your own custom bundle (NAR), copy the UnpackContent code 
from 0.7 branch, rename the actual class to something different (e.g., 
UnzipContent) and then deploy it as your own custom bundle and use it in your 
flow.

4.  You can also apply patch through fixing the byte code in flight but that 
would require you to write javaagent and be familiar with byte code 
manipulations frameworks. Not advisable. . .

Honestly, aside from full upgrade the only viable option here is #3 since it 
gives you full control and complete isolation from every other component in 
NiFi.

Let me know what you think so we can guide you thru the process.

Cheers
Oleg

On Dec 14, 2016, at 2:18 PM, James McMahon 
mailto:jsmcmah...@gmail.com>> wrote:

Oleg, I am bound to NiFi 0.6.1 by enterprise application dependencies. So this 
fix will not be in my baseline if I understand you correctly. Let me ask you 
this: is there any way I can build this into my code baseline - either through 
a code mod and rebuild or as a custom plugin feature specific to my flow? 
Thanks very much for your help.

On Wed, Dec 14, 2016 at 10:59 AM, Oleg Zhurakousky 
mailto:ozhurakou...@hortonworks.com>> wrote:
James

Could you also let us know what version of NiFi you are using? The issue with 
properly handling InvalidPathException was fixed in NiFi 0.7.0 as part of 
https://issues.apache.org/jira/browse/NIFI-920
It essentially has this catch block:
} catch (final ProcessException | InvalidPathException e) {
 logger.error("Unable to unpack {} due to {}; routing to failure", new 
Object[]{flowFile, e});
 session.transfer(flowFile, REL_FAILURE);

So I am wondering if you are on the proviso release?
Cheers
Oleg

On Dec 14, 2016, at 10:49 AM, Joe Witt 
mailto:joe.w...@gmail.com>> wrote:

James,

Can you please share the full log entry for that failure.  It is
possible the processor is not catching the exception properly and
routing the data to failure.  It might simply be letting the exception
loose thus the framework detects the issue and rollsback the session
and yields the processor.

Likely an easy thing to fix in the processor but please do share the
full nifi-app.log entry for this.

Thanks
Joe

On Wed, Dec 14, 2016 at 10:47 AM, James McMahon 
mailto:jsmcmah...@gmail.com>> wrote:
Hello. Am wondering if anyone knows how to overcome a challenge with
unmappable file characters? I have used a GetFile processor to bring a large
number of zip files into a NiFi flow. All read in successfully. I try to
then use an UnpackContent processor to unzip the files to their individual
file members. Most work just fine. However there appears to be a file that
throws this error in UnpackContent:

failed to process session due to java.nio.file.InvalidPathException:
Malformed input or input contains unmappabl

Re: File causes unexpected stoppage in play

2016-12-14 Thread James McMahon
I've never tried to create and deploy my own custom bundle but would like
to try #3 as you recommend Oleg. If you can offer guidance to that process
let me try that. Thank you. -Jim

On Wed, Dec 14, 2016 at 2:57 PM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:

> James
>
> Not sure what kind of liberties you have with your environment, but here
> is what you can do outside of full upgrade.
>
> 1. You can download and drop the bundle (NAR) from NiFi 0.7 release into
> 0.6 release. That should work (just replace it in the ‘lib’ directory of
> NiFi home). However, this particular component is located in
> ’nifi-standard-nar’ which means it contains majority of the processors and
> controller services that come with NiFi. So while upgrading one component
> you will essentially upgrade almost all and I am not sure what it may lead
> to, but you can definitely try.
>
> 2.  You can certainly checkout the NiFi 0.6.1 source from the repo and
> apply the same patch on UpdateContent, build NAR and replace it as
> described in the step above, Even though you’ll still be replacing the
> entire NAR the changes are only going to be in that single component.
>
> 3.  You can create your own custom bundle (NAR), copy the UnpackContent
> code from 0.7 branch, rename the actual class to something different (e.g.,
> UnzipContent) and then deploy it as your own custom bundle and use it in
> your flow.
>
> 4.  You can also apply patch through fixing the byte code in flight but
> that would require you to write javaagent and be familiar with byte code
> manipulations frameworks. Not advisable. . .
>
> Honestly, aside from full upgrade the only viable option here is #3 since
> it gives you full control and complete isolation from every other component
> in NiFi.
>
> Let me know what you think so we can guide you thru the process.
>
> Cheers
> Oleg
>
> On Dec 14, 2016, at 2:18 PM, James McMahon  wrote:
>
> Oleg, I am bound to NiFi 0.6.1 by enterprise application dependencies. So
> this fix will not be in my baseline if I understand you correctly. Let me
> ask you this: is there any way I can build this into my code baseline -
> either through a code mod and rebuild or as a custom plugin feature
> specific to my flow? Thanks very much for your help.
>
> On Wed, Dec 14, 2016 at 10:59 AM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
>> James
>>
>> Could you also let us know what version of NiFi you are using? The issue
>> with properly handling InvalidPathException was fixed in NiFi 0.7.0 as part
>> of https://issues.apache.org/jira/browse/NIFI-920
>> It essentially has this catch block:
>> } catch (final ProcessException | InvalidPathException e) {
>>  logger.error("Unable to unpack {} due to {}; routing to failure",
>> new Object[]{flowFile, e});
>>  session.transfer(flowFile, REL_FAILURE);
>>
>> So I am wondering if you are on the proviso release?
>> Cheers
>> Oleg
>>
>> On Dec 14, 2016, at 10:49 AM, Joe Witt  wrote:
>>
>> James,
>>
>> Can you please share the full log entry for that failure.  It is
>> possible the processor is not catching the exception properly and
>> routing the data to failure.  It might simply be letting the exception
>> loose thus the framework detects the issue and rollsback the session
>> and yields the processor.
>>
>> Likely an easy thing to fix in the processor but please do share the
>> full nifi-app.log entry for this.
>>
>> Thanks
>> Joe
>>
>> On Wed, Dec 14, 2016 at 10:47 AM, James McMahon 
>> wrote:
>>
>> Hello. Am wondering if anyone knows how to overcome a challenge with
>> unmappable file characters? I have used a GetFile processor to bring a
>> large
>> number of zip files into a NiFi flow. All read in successfully. I try to
>> then use an UnpackContent processor to unzip the files to their individual
>> file members. Most work just fine. However there appears to be a file that
>> throws this error in UnpackContent:
>>
>> failed to process session due to java.nio.file.InvalidPathException:
>> Malformed input or input contains unmappable characters
>>
>> My processing stalls. Nothing else flows. What is the proper way to
>> configure the UnpackContent processor step so that it shuttle such files
>> off
>> to the side when it encounters them, and permits the other files waiting
>> in
>> queue to process? I do now have a "failure" path established for my
>> UnpackContent processor, but for some reason it does not send these
>> problem
>> files down that path. I suspect it may be because the zip files does
>> unpack
>> successfully but the underlying file(s) within the zip cause processing to
>> choke.
>>
>> How can I engineer a flow to overcome this challenge? Thanks in advance
>> for
>> your help.
>>
>>
>>
>>
>
>


Re: File causes unexpected stoppage in play

2016-12-14 Thread Oleg Zhurakousky
James

Not sure what kind of liberties you have with your environment, but here is 
what you can do outside of full upgrade.

1. You can download and drop the bundle (NAR) from NiFi 0.7 release into 0.6 
release. That should work (just replace it in the ‘lib’ directory of NiFi 
home). However, this particular component is located in ’nifi-standard-nar’ 
which means it contains majority of the processors and controller services that 
come with NiFi. So while upgrading one component you will essentially upgrade 
almost all and I am not sure what it may lead to, but you can definitely try.

2.  You can certainly checkout the NiFi 0.6.1 source from the repo and apply 
the same patch on UpdateContent, build NAR and replace it as described in the 
step above, Even though you’ll still be replacing the entire NAR the changes 
are only going to be in that single component.

3.  You can create your own custom bundle (NAR), copy the UnpackContent code 
from 0.7 branch, rename the actual class to something different (e.g., 
UnzipContent) and then deploy it as your own custom bundle and use it in your 
flow.

4.  You can also apply patch through fixing the byte code in flight but that 
would require you to write javaagent and be familiar with byte code 
manipulations frameworks. Not advisable. . .

Honestly, aside from full upgrade the only viable option here is #3 since it 
gives you full control and complete isolation from every other component in 
NiFi.

Let me know what you think so we can guide you thru the process.

Cheers
Oleg

On Dec 14, 2016, at 2:18 PM, James McMahon 
mailto:jsmcmah...@gmail.com>> wrote:

Oleg, I am bound to NiFi 0.6.1 by enterprise application dependencies. So this 
fix will not be in my baseline if I understand you correctly. Let me ask you 
this: is there any way I can build this into my code baseline - either through 
a code mod and rebuild or as a custom plugin feature specific to my flow? 
Thanks very much for your help.

On Wed, Dec 14, 2016 at 10:59 AM, Oleg Zhurakousky 
mailto:ozhurakou...@hortonworks.com>> wrote:
James

Could you also let us know what version of NiFi you are using? The issue with 
properly handling InvalidPathException was fixed in NiFi 0.7.0 as part of 
https://issues.apache.org/jira/browse/NIFI-920
It essentially has this catch block:
} catch (final ProcessException | InvalidPathException e) {
 logger.error("Unable to unpack {} due to {}; routing to failure", new 
Object[]{flowFile, e});
 session.transfer(flowFile, REL_FAILURE);

So I am wondering if you are on the proviso release?
Cheers
Oleg

On Dec 14, 2016, at 10:49 AM, Joe Witt 
mailto:joe.w...@gmail.com>> wrote:

James,

Can you please share the full log entry for that failure.  It is
possible the processor is not catching the exception properly and
routing the data to failure.  It might simply be letting the exception
loose thus the framework detects the issue and rollsback the session
and yields the processor.

Likely an easy thing to fix in the processor but please do share the
full nifi-app.log entry for this.

Thanks
Joe

On Wed, Dec 14, 2016 at 10:47 AM, James McMahon 
mailto:jsmcmah...@gmail.com>> wrote:
Hello. Am wondering if anyone knows how to overcome a challenge with
unmappable file characters? I have used a GetFile processor to bring a large
number of zip files into a NiFi flow. All read in successfully. I try to
then use an UnpackContent processor to unzip the files to their individual
file members. Most work just fine. However there appears to be a file that
throws this error in UnpackContent:

failed to process session due to java.nio.file.InvalidPathException:
Malformed input or input contains unmappable characters

My processing stalls. Nothing else flows. What is the proper way to
configure the UnpackContent processor step so that it shuttle such files off
to the side when it encounters them, and permits the other files waiting in
queue to process? I do now have a "failure" path established for my
UnpackContent processor, but for some reason it does not send these problem
files down that path. I suspect it may be because the zip files does unpack
successfully but the underlying file(s) within the zip cause processing to
choke.

How can I engineer a flow to overcome this challenge? Thanks in advance for
your help.






Re: File causes unexpected stoppage in play

2016-12-14 Thread James McMahon
Oleg, I am bound to NiFi 0.6.1 by enterprise application dependencies. So
this fix will not be in my baseline if I understand you correctly. Let me
ask you this: is there any way I can build this into my code baseline -
either through a code mod and rebuild or as a custom plugin feature
specific to my flow? Thanks very much for your help.

On Wed, Dec 14, 2016 at 10:59 AM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:

> James
>
> Could you also let us know what version of NiFi you are using? The issue
> with properly handling InvalidPathException was fixed in NiFi 0.7.0 as part
> of https://issues.apache.org/jira/browse/NIFI-920
> It essentially has this catch block:
> } catch (final ProcessException | InvalidPathException e) {
>  logger.error("Unable to unpack {} due to {}; routing to failure", new
> Object[]{flowFile, e});
>  session.transfer(flowFile, REL_FAILURE);
>
> So I am wondering if you are on the proviso release?
> Cheers
> Oleg
>
> On Dec 14, 2016, at 10:49 AM, Joe Witt  wrote:
>
> James,
>
> Can you please share the full log entry for that failure.  It is
> possible the processor is not catching the exception properly and
> routing the data to failure.  It might simply be letting the exception
> loose thus the framework detects the issue and rollsback the session
> and yields the processor.
>
> Likely an easy thing to fix in the processor but please do share the
> full nifi-app.log entry for this.
>
> Thanks
> Joe
>
> On Wed, Dec 14, 2016 at 10:47 AM, James McMahon 
> wrote:
>
> Hello. Am wondering if anyone knows how to overcome a challenge with
> unmappable file characters? I have used a GetFile processor to bring a
> large
> number of zip files into a NiFi flow. All read in successfully. I try to
> then use an UnpackContent processor to unzip the files to their individual
> file members. Most work just fine. However there appears to be a file that
> throws this error in UnpackContent:
>
> failed to process session due to java.nio.file.InvalidPathException:
> Malformed input or input contains unmappable characters
>
> My processing stalls. Nothing else flows. What is the proper way to
> configure the UnpackContent processor step so that it shuttle such files
> off
> to the side when it encounters them, and permits the other files waiting in
> queue to process? I do now have a "failure" path established for my
> UnpackContent processor, but for some reason it does not send these problem
> files down that path. I suspect it may be because the zip files does unpack
> successfully but the underlying file(s) within the zip cause processing to
> choke.
>
> How can I engineer a flow to overcome this challenge? Thanks in advance for
> your help.
>
>
>
>


Re: File causes unexpected stoppage in play

2016-12-14 Thread James McMahon
Thank you Joe. While I'm unable to export and share the nifi-app.log file,
I can tell you that the processor is throwing the error  "...failed to
process due to java.nio.file.InvalidPathException: Malformed input or input
contains unmappable characters: /dir/path//_?.jpg "

On Wed, Dec 14, 2016 at 10:49 AM, Joe Witt  wrote:

> James,
>
> Can you please share the full log entry for that failure.  It is
> possible the processor is not catching the exception properly and
> routing the data to failure.  It might simply be letting the exception
> loose thus the framework detects the issue and rollsback the session
> and yields the processor.
>
> Likely an easy thing to fix in the processor but please do share the
> full nifi-app.log entry for this.
>
> Thanks
> Joe
>
> On Wed, Dec 14, 2016 at 10:47 AM, James McMahon 
> wrote:
> > Hello. Am wondering if anyone knows how to overcome a challenge with
> > unmappable file characters? I have used a GetFile processor to bring a
> large
> > number of zip files into a NiFi flow. All read in successfully. I try to
> > then use an UnpackContent processor to unzip the files to their
> individual
> > file members. Most work just fine. However there appears to be a file
> that
> > throws this error in UnpackContent:
> >
> > failed to process session due to java.nio.file.InvalidPathException:
> > Malformed input or input contains unmappable characters
> >
> > My processing stalls. Nothing else flows. What is the proper way to
> > configure the UnpackContent processor step so that it shuttle such files
> off
> > to the side when it encounters them, and permits the other files waiting
> in
> > queue to process? I do now have a "failure" path established for my
> > UnpackContent processor, but for some reason it does not send these
> problem
> > files down that path. I suspect it may be because the zip files does
> unpack
> > successfully but the underlying file(s) within the zip cause processing
> to
> > choke.
> >
> > How can I engineer a flow to overcome this challenge? Thanks in advance
> for
> > your help.
>


Re: Apache Minifi questions

2016-12-14 Thread Aldrin Piri
Juan,

MiNiFi should be fine with 0.7.x in terms of generating a template to be
converted for usage in MiNiFi.  Sending data to a NiFi instance also works
across site to site to the same version.  Of course other transport
mechanisms across differing protocols are also fair game.

Currently, provenance is also provided across site to site, able to be
collected and stored for consumption and analysis.  There is currently no
functionality in NiFi to integrate MiNiFi provenance in the UI.


On Wed, Dec 14, 2016 at 1:43 PM, Juan Sequeiros  wrote:

> Hello all,
>
> Will latest MINIFI work with Apache NIFI 0.7?  In the sense that I build
> my dataflow and then deploy the dataflow to Apache MINIFI edge node to run?
>
> How does the provenance of Apache MINIFI work how can I view it, we will
> not have Apache NIFI 1 at the "lake"
>
>
> Thank you
>


Apache Minifi questions

2016-12-14 Thread Juan Sequeiros
Hello all,

Will latest MINIFI work with Apache NIFI 0.7?  In the sense that I build my
dataflow and then deploy the dataflow to Apache MINIFI edge node to run?

How does the provenance of Apache MINIFI work how can I view it, we will
not have Apache NIFI 1 at the "lake"


Thank you


Re: File causes unexpected stoppage in play

2016-12-14 Thread Oleg Zhurakousky
James

Could you also let us know what version of NiFi you are using? The issue with 
properly handling InvalidPathException was fixed in NiFi 0.7.0 as part of 
https://issues.apache.org/jira/browse/NIFI-920
It essentially has this catch block:
} catch (final ProcessException | InvalidPathException e) {
 logger.error("Unable to unpack {} due to {}; routing to failure", new 
Object[]{flowFile, e});
 session.transfer(flowFile, REL_FAILURE);

So I am wondering if you are on the proviso release?
Cheers
Oleg

On Dec 14, 2016, at 10:49 AM, Joe Witt 
mailto:joe.w...@gmail.com>> wrote:

James,

Can you please share the full log entry for that failure.  It is
possible the processor is not catching the exception properly and
routing the data to failure.  It might simply be letting the exception
loose thus the framework detects the issue and rollsback the session
and yields the processor.

Likely an easy thing to fix in the processor but please do share the
full nifi-app.log entry for this.

Thanks
Joe

On Wed, Dec 14, 2016 at 10:47 AM, James McMahon 
mailto:jsmcmah...@gmail.com>> wrote:
Hello. Am wondering if anyone knows how to overcome a challenge with
unmappable file characters? I have used a GetFile processor to bring a large
number of zip files into a NiFi flow. All read in successfully. I try to
then use an UnpackContent processor to unzip the files to their individual
file members. Most work just fine. However there appears to be a file that
throws this error in UnpackContent:

failed to process session due to java.nio.file.InvalidPathException:
Malformed input or input contains unmappable characters

My processing stalls. Nothing else flows. What is the proper way to
configure the UnpackContent processor step so that it shuttle such files off
to the side when it encounters them, and permits the other files waiting in
queue to process? I do now have a "failure" path established for my
UnpackContent processor, but for some reason it does not send these problem
files down that path. I suspect it may be because the zip files does unpack
successfully but the underlying file(s) within the zip cause processing to
choke.

How can I engineer a flow to overcome this challenge? Thanks in advance for
your help.




Re: File causes unexpected stoppage in play

2016-12-14 Thread Joe Witt
James,

Can you please share the full log entry for that failure.  It is
possible the processor is not catching the exception properly and
routing the data to failure.  It might simply be letting the exception
loose thus the framework detects the issue and rollsback the session
and yields the processor.

Likely an easy thing to fix in the processor but please do share the
full nifi-app.log entry for this.

Thanks
Joe

On Wed, Dec 14, 2016 at 10:47 AM, James McMahon  wrote:
> Hello. Am wondering if anyone knows how to overcome a challenge with
> unmappable file characters? I have used a GetFile processor to bring a large
> number of zip files into a NiFi flow. All read in successfully. I try to
> then use an UnpackContent processor to unzip the files to their individual
> file members. Most work just fine. However there appears to be a file that
> throws this error in UnpackContent:
>
> failed to process session due to java.nio.file.InvalidPathException:
> Malformed input or input contains unmappable characters
>
> My processing stalls. Nothing else flows. What is the proper way to
> configure the UnpackContent processor step so that it shuttle such files off
> to the side when it encounters them, and permits the other files waiting in
> queue to process? I do now have a "failure" path established for my
> UnpackContent processor, but for some reason it does not send these problem
> files down that path. I suspect it may be because the zip files does unpack
> successfully but the underlying file(s) within the zip cause processing to
> choke.
>
> How can I engineer a flow to overcome this challenge? Thanks in advance for
> your help.


File causes unexpected stoppage in play

2016-12-14 Thread James McMahon
Hello. Am wondering if anyone knows how to overcome a challenge with
unmappable file characters? I have used a GetFile processor to bring a
large number of zip files into a NiFi flow. All read in successfully. I try
to then use an UnpackContent processor to unzip the files to their
individual file members. Most work just fine. However there appears to be a
file that throws this error in UnpackContent:

failed to process session due to java.nio.file.InvalidPathException:
Malformed input or input contains unmappable characters

My processing stalls. Nothing else flows. What is the proper way to
configure the UnpackContent processor step so that it shuttle such
files off to the side when it encounters them, and permits the other files
waiting in queue to process? I do now have a "failure" path established for
my UnpackContent processor, but for some reason it does not send these
problem files down that path. I suspect it may be because the zip files
does unpack successfully but the underlying file(s) within the zip cause
processing to choke.

How can I engineer a flow to overcome this challenge? Thanks in advance for
your help.


Re: Failing Tests during Build

2016-12-14 Thread Joe Witt
Hello

Those tests rely on DNS which appears to be in a funky state.
However, to get the build working otherwise you can run

mvn -T C2 clean install -DskipTests

Thanks
joe

On Wed, Dec 14, 2016 at 10:07 AM, Pushkar  wrote:
> Hi,
>
> I tried to build NiFi on my linux machine using 'mvn -T 2.0C clean install'.
> However there seems to be a few tests failing which I don't seem to be able
> to fix. I have pasted the stacktrace below. Please let me know how I can fix
> this and get the build running.
>
> Please note, I haven't made any changes to the code. I pulled the master
> branch and attempted to build.
>
> Pushkar
>
> -
> nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster-protocol/target/surefire-reports/org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest-output.txt
>
> [main] INFO org.apache.nifi.io.socket.SocketListener - Now listening for
> connections from nodes on port 0
> [Process Cluster Protocol Request-1] WARN
> org.apache.nifi.cluster.protocol.impl.SocketProtocolListener - Failed
> processing protocol message from localhost.localdomain due to
> java.io.IOException: Failed reading protocol message due to malformed header
> java.io.IOException: Failed reading protocol message due to malformed header
> at
> org.apache.nifi.cluster.protocol.jaxb.JaxbProtocolContext$2.unmarshal(JaxbProtocolContext.java:115)
> at
> org.apache.nifi.cluster.protocol.impl.SocketProtocolListener.dispatchRequest(SocketProtocolListener.java:142)
> at
> org.apache.nifi.io.socket.SocketListener$2$1.run(SocketListener.java:136)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> [main] INFO org.apache.nifi.io.socket.SocketListener - Socket Listener has
> been terminated successfully.
> [Cluster Socket Listener] WARN org.apache.nifi.io.socket.SocketListener -
> Failed to communicate with Unknown Host due to java.net.SocketException:
> Socket closed
> java.net.SocketException: Socket closed
> at java.net.PlainSocketImpl.socketAccept(Native Method)
> at
> java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
> at java.net.ServerSocket.implAccept(ServerSocket.java:545)
> at java.net.ServerSocket.accept(ServerSocket.java:513)
> at
> org.apache.nifi.io.socket.SocketListener$2.run(SocketListener.java:112)
> at java.lang.Thread.run(Thread.java:745)
> [main] INFO org.apache.nifi.io.socket.SocketListener - Now listening for
> connections from nodes on port 0
> [Process Cluster Protocol Request-1] INFO
> org.apache.nifi.cluster.protocol.impl.SocketProtocolListener - Finished
> processing request a3e83b60-05ee-47a0-a636-d528bea91cd3 (type=PING,
> length=129 bytes) from localhost.localdomain in 3935 millis
> [main] INFO org.apache.nifi.io.socket.SocketListener - Socket Listener has
> been terminated successfully.
> [main] INFO org.apache.nifi.io.socket.SocketListener - Now listening for
> connections from nodes on port 0
> [Process Cluster Protocol Request-1] INFO
> org.apache.nifi.cluster.protocol.impl.SocketProtocolListener - Finished
> processing request 85ecda07-1d72-4109-84d5-f5f882194b76 (type=PING,
> length=129 bytes) from localhost.localdomain in 1 millis
> [main] INFO org.apache.nifi.io.socket.SocketListener - Socket Listener has
> been terminated successfully.
>
>
>
> -
> nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster-protocol/target/surefire-reports/org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest.txt
>
> ---
> Test set: org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest
> ---
> Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.767 sec
> <<< FAILURE! - in
> org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest
> testDelayedRequest(org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest)
> Time elapsed: 4.358 sec  <<< FAILURE!
> java.lang.AssertionError: expected:<1> but was:<0>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.junit.Assert.assertEquals(Assert.java:631)
> at
> org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest.testDelayedRequest(SocketProtocolListenerTest.java:128)
>
>


Failing Tests during Build

2016-12-14 Thread Pushkar

Hi,

I tried to build NiFi on my linux machine using 'mvn -T 2.0C clean 
install'. However there seems to be a few tests failing which I don't 
seem to be able to fix. I have pasted the stacktrace below. Please let 
me know how I can fix this and get the build running.


Please note, I haven't made any changes to the code. I pulled the master 
branch and attempted to build.


Pushkar

- 
nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster-protocol/target/surefire-reports/org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest-output.txt


[main] INFO org.apache.nifi.io.socket.SocketListener - Now listening for 
connections from nodes on port 0
[Process Cluster Protocol Request-1] WARN 
org.apache.nifi.cluster.protocol.impl.SocketProtocolListener - Failed 
processing protocol message from localhost.localdomain due to 
java.io.IOException: Failed reading protocol message due to malformed header
java.io.IOException: Failed reading protocol message due to malformed header
at 
org.apache.nifi.cluster.protocol.jaxb.JaxbProtocolContext$2.unmarshal(JaxbProtocolContext.java:115)
at 
org.apache.nifi.cluster.protocol.impl.SocketProtocolListener.dispatchRequest(SocketProtocolListener.java:142)
at 
org.apache.nifi.io.socket.SocketListener$2$1.run(SocketListener.java:136)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
[main] INFO org.apache.nifi.io.socket.SocketListener - Socket Listener has been 
terminated successfully.
[Cluster Socket Listener] WARN org.apache.nifi.io.socket.SocketListener - 
Failed to communicate with Unknown Host due to java.net.SocketException: Socket 
closed
java.net.SocketException: Socket closed
at java.net.PlainSocketImpl.socketAccept(Native Method)
at 
java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:409)
at java.net.ServerSocket.implAccept(ServerSocket.java:545)
at java.net.ServerSocket.accept(ServerSocket.java:513)
at 
org.apache.nifi.io.socket.SocketListener$2.run(SocketListener.java:112)
at java.lang.Thread.run(Thread.java:745)
[main] INFO org.apache.nifi.io.socket.SocketListener - Now listening for 
connections from nodes on port 0
[Process Cluster Protocol Request-1] INFO 
org.apache.nifi.cluster.protocol.impl.SocketProtocolListener - Finished 
processing request a3e83b60-05ee-47a0-a636-d528bea91cd3 (type=PING, length=129 
bytes) from localhost.localdomain in 3935 millis
[main] INFO org.apache.nifi.io.socket.SocketListener - Socket Listener has been 
terminated successfully.
[main] INFO org.apache.nifi.io.socket.SocketListener - Now listening for 
connections from nodes on port 0
[Process Cluster Protocol Request-1] INFO 
org.apache.nifi.cluster.protocol.impl.SocketProtocolListener - Finished 
processing request 85ecda07-1d72-4109-84d5-f5f882194b76 (type=PING, length=129 
bytes) from localhost.localdomain in 1 millis
[main] INFO org.apache.nifi.io.socket.SocketListener - Socket Listener has been 
terminated successfully.



- 
nifi/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-cluster-protocol/target/surefire-reports/org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest.txt

---
Test set: org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest
---
Tests run: 3, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.767 sec <<< 
FAILURE! - in org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest
testDelayedRequest(org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest)  
Time elapsed: 4.358 sec  <<< FAILURE!
java.lang.AssertionError: expected:<1> but was:<0>
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.failNotEquals(Assert.java:834)
at org.junit.Assert.assertEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:631)
at 
org.apache.nifi.cluster.protocol.impl.SocketProtocolListenerTest.testDelayedRequest(SocketProtocolListenerTest.java:128)




Re: Nifi "Hive" with CDH

2016-12-14 Thread Matt Burgess
Unfortunately I don't believe enabling the profile and setting the version
will work in this case, because there are API differences between Hive
1.0.0 (the one CDH 5.9 is based on) and Hive 1.2.1 (the one NiFi is based
on). These require code changes to get working.

Regards,
Matt

On Wed, Dec 14, 2016 at 5:26 AM, Andre  wrote:

> Nicolas,
>
> Have you tried building NiFi with the CDH libraries?
>
> The functionality is available out of the box and just requires you to
> enable to correct profile.
>
> Cheers
>
> On Wed, Dec 14, 2016 at 9:13 PM, Provenzano Nicolas <
> nicolas.provenz...@gfi.fr> wrote:
>
>> Hi all,
>>
>>
>>
>> We are currently working on NiFi Hive processors (selectHiveQL,
>> putHiveStreaming…).
>>
>>
>>
>> We are testing them with a CDH platform (and with a “Apache” platform).
>>
>>
>>
>> Hive 1.0.0 is deployed with the last releases of CDH (5.9) while Nifi is
>> built with Hive 1.2.1 libraries.
>>
>>
>>
>> We then have serious compatibility issues. The “simple” selectHiveQL
>> processor fails with “required client_protocol is unset” error message,
>> that seems to shows version mismatch between the hive client and the hive
>> server.
>>
>>
>>
>> Do you know if there are workarounds or solutions for those issues ? I
>> would like to avoid rebuilding NiFi with older libraries.
>>
>>
>>
>> Thanks in advance,
>>
>>
>>
>> BR
>>
>>
>>
>> Nicolas
>>
>>
>>
>>
>>
>> —
>> Gfi Informatique Telecom
>> *Nicolas Provenzano*
>>
>> BU Telecom / Customer Experience
>>
>> *nicolas.provenz...@gfi.fr *
>> —
>> 2 rue Andras Beck – 92360 Meudon La Forêt
>> Tél. : +33 (0)1 46 83 35 06
>> Mob. : +33 (0)6 82 07 19 21
>> www.gfi.world
>> —
>> [image: signature-img]
>>
>>
>>
>
>


Re: Processors on the fly for many sensor devices

2016-12-14 Thread Oleg Zhurakousky
Davy

Indeed it is andI am hoping that it will make it int o the next release (can’t 
see why).

Cheers
Oleg

On Dec 14, 2016, at 9:20 AM, Andrew Psaltis 
mailto:psaltis.and...@gmail.com>> wrote:

Davy,
Sorry for the delay in my response. I did see your comments on my P/R, 
appreciate them and meant to respond to those. The current state of GetTCP is 
that is it going to undergo refactoring and potentially a redesign to better 
align with NiFi best practices. I am not 100% of the timeline for that at this 
time.

Thanks,
Andrew

On Wed, Dec 14, 2016 at 3:31 AM, ddewaele 
mailto:ddewa...@gmail.com>> wrote:
Hi Andrew,

I noticed you've created a pull request to get this in the Nifi codebase and
that there were some review discussions going on.

I was wondering what the status is on the GetTCP processor.

I've also logged some issues in your Github repo and can create some PRs if
you like.




--
View this message in context: 
http://apache-nifi-users-list.2361937.n4.nabble.com/Re-Processors-on-the-fly-for-many-sensor-devices-tp47p427.html
Sent from the Apache NiFi Users List mailing list archive at 
Nabble.com.



--
Thanks,
Andrew

Subscribe to my book: Streaming Data
[https://static.licdn.com/scds/common/u/img/webpromo/btn_viewmy_160x25.png]
twiiter: @itmdata



Re: Processors on the fly for many sensor devices

2016-12-14 Thread Andrew Psaltis
Davy,
Sorry for the delay in my response. I did see your comments on my P/R,
appreciate them and meant to respond to those. The current state of GetTCP
is that is it going to undergo refactoring and potentially a redesign to
better align with NiFi best practices. I am not 100% of the timeline for
that at this time.

Thanks,
Andrew

On Wed, Dec 14, 2016 at 3:31 AM, ddewaele  wrote:

> Hi Andrew,
>
> I noticed you've created a pull request to get this in the Nifi codebase
> and
> that there were some review discussions going on.
>
> I was wondering what the status is on the GetTCP processor.
>
> I've also logged some issues in your Github repo and can create some PRs if
> you like.
>
>
>
>
> --
> View this message in context: http://apache-nifi-users-list.
> 2361937.n4.nabble.com/Re-Processors-on-the-fly-for-
> many-sensor-devices-tp47p427.html
> Sent from the Apache NiFi Users List mailing list archive at Nabble.com.
>



-- 
Thanks,
Andrew

Subscribe to my book: Streaming Data 

twiiter: @itmdata 


Re: NiFi PlublishAMQP using cert CN as username

2016-12-14 Thread Oleg Zhurakousky
Kiran

No problems. I’ve just assign it to myself. Will do our best to have it in next 
release.
Cheers
Oleg

On Dec 13, 2016, at 4:13 PM, Kiran 
mailto:b.deep.internatio...@gmail.com>> wrote:

Oleg,

Sorry for the delay, I've created the following JIRA ticket: 
https://issues.apache.org/jira/browse/NIFI-3193

If you need anything else added to the ticket give me a bell.

I'll attach my test application to the JIRA ticket this weekend.

Thanks,

Kiran

-- Original Message --
From: "Oleg Zhurakousky" 
mailto:ozhurakou...@hortonworks.com>>
To: "users@nifi.apache.org" 
mailto:users@nifi.apache.org>>; "Kiran" 
mailto:b.deep.internatio...@gmail.com>>
Sent: 10/12/2016 13:21:41
Subject: Re: NiFi PlublishAMQP using cert CN as username

Brian

Thank you for detailed explanation.
I don't believe you're doing anything wrong. We just need do add the feature 
you describe (pulling credentials from certificate).

Would you mind creating JIRA ticket and if at all possible attach the sample 
code that demonstrates exactly what you're trying to accomplish?

Cheers
Oleg


On Dec 10, 2016, at 03:52, Kiran 
mailto:b.deep.internatio...@gmail.com>> wrote:

Hello,

I'm having a bit of trouble getting NiFi to talk to RabbitMQ using SSL. I've 
created some certificates using the openssl and I have been successful in 
sending messages to RabbitMQ when I specific an SSL context and a 
username/password. In this scenario I can see a TLS 1.2 HTTPS connection form 
between NiFi and RabbitMQ and the username and password used to then 
authenticate successfully, so from this I know that the certs being used are 
valid.

What I'm trying to achieve is for the RabbitMQ username to be pulled out of the 
certificate COMMON_NAME so don't need to provide a username and password. I've 
created a quick test application to confirm that I can connect successfully to 
RabbitMQ using the certs I created and just the certificate CN name and this 
worked, which means it must be something I've done wrong within my NiFi 
processor configuration which is why I'm sending this email for help :)

The RabbitMQ configuration I'm using is:

  *   RabbitMQ 3.5.4
  *   Erlang 18.0
  *   rabbitmq_auth_mechanism_ssl plugin enabled
  *   Base OS is RHEL 6.5

My RabbitMQ.config contains the following:
[
  {rabbit, [
 {ssl_listeners, [5671]},
 {loopback_users, []},
 {auth_mechanisms, ['EXTERNAL', 'PLAIN']},
 {ssl_options, [{cacertfile,"/home/data/openssl/brian_testca/cacert.pem"},
{certfile,"/home/data/openssl/brian_server/cert.pem"},
{keyfile,"/home/data/openssl/brian_server/key.pem"},
{verify,verify_peer},
{versions, ['tlsv1.2']},
{password,  "MySecretPassword"},
{verify,verify_peer},
{ssl_cert_login_from, common_name},
{fail_if_no_peer_cert,true}]}
   ]}
].

The NiFi configuration I'm using is:

  *
NiFi 0.7.1 (We are in the process of updating to NiFi 1.1.0 but there are some 
dependencies on other projects so it will happen just not for a few months)
  *
2 Clusters each made up of 1 NCM and 3 Nodes
  *
In the PublishAMQP I've put the certificate CN name into the "username" field.

The client certificate I'm using to connect to RabbitMQ has a CN name of: 
"rabbitmq_client". There is an entry for it in the RabbitMQ users with NO 
PASSWORD set.

Error message in the rabbitmq log files:

=ERROR REPORT 7-Dec-2016::21:47:30 ===
closing AMQP connection <0.905.0> (192.168.137.1:54324 -> 192.168.137.128:5671):
{handshake_error,starting,0,
 {amqp_error,access_refused,
 "PLAIN login refused: user 'rabbitmq_client' - 
invalid credentials",
 'connection.start_ok'}}

Please can you tell me if there is something obvious that I'm missed out in my 
NiFi configuration?

I did have a very brief look at the code and I was thinking that because the 
USERNAME and PASSWORD were mandatory fields and always used to establish the 
connection it could be that RabbitMQ prioritises those fields before trying to 
pull out the CN name and using that for authentication. The reason I was 
thinking this was in the test app I created I didn't specify the username or 
password when setting up my ConnectionFactory but the RabbitMQ documentation 
says even if you don't specify the username and password they default to 
guest/guest so this could be a red herring.

Thanks in advance for the help,

Brian



Re: Data Provenance - Disk Full

2016-12-14 Thread Pablo Lopez
Hi,

I've deleted the files as suggested by James, but I would also like to fine
tune so this doesn't happen again.
However, I'm not sure what exactly happens with
parameter: nifi.provenance.repository.max.storage.size

I haven't changed the default (1 GB), so what would happen when the limit
is reached? Does NiFi stops storing the provenance and someone has to
manually delete the files or does it cycle again over the 1 GB overwriting
the existing files?

Thanks,
Pablo.

On Wed, Dec 14, 2016 at 5:31 PM, James Wing  wrote:

> Pablo,
>
> An extreme fix is to stop stop NiFi and completely delete the provenance
> repository directory.  You will get a new, empty provenance repository when
> you restart NiFi.  All data will be lost, but NiFi will work again.
>
> Obviously, Lee's advice is much better, but there are options if you need
> them.
>
> James
>
> On Tue, Dec 13, 2016 at 10:23 PM, Lee Laim  wrote:
>
>> Pablo,
>>
>> You can decrease the following attributes in conf/nifi.properties.
>>
>> nifi.provenance.repository.max.storage.time
>>
>> The maximum amount of time to keep data provenance information. The
>> default value is 24 hours.
>>
>> nifi.provenance.repository.max.storage.size
>>
>> The maximum amount of data provenance information to store at a time. The
>> default is 1 GB.
>> https://nifi.apache.org/docs/nifi-docs/html/administration-g
>> uide.html#flowfile-repository
>>
>>
>> Thanks,
>> Lee
>>
>>
>>
>> On Tue, Dec 13, 2016 at 10:43 PM, Pablo Lopez <
>> pablo.lo...@integrado.com.au> wrote:
>>
>>> Hi,
>>>
>>> We've been loading quite a few big files through NiFi, but now it looks
>>> that the file disk is full and we get this error in most places and nothing
>>> gets processed.
>>>
>>> "Failed to rollover Provenance Event Log due to java.io.IOException no
>>> space left on device"
>>>
>>> Is there a way to manually delete all the provenance entries from the
>>> repository so we can continue processing?
>>> Also, is there a way to disable data provenance for big files?
>>>
>>> Thanks for your help,
>>> Pablo.
>>>
>>
>>
>


-- 
Pablo Lopez.
Integration Architect
Integrado Pty Ltd
M: 044 84 52 479
pablo.lo...@integrado.com.au


Re: Nifi "Hive" with CDH

2016-12-14 Thread Andre
Nicolas,

Have you tried building NiFi with the CDH libraries?

The functionality is available out of the box and just requires you to
enable to correct profile.

Cheers

On Wed, Dec 14, 2016 at 9:13 PM, Provenzano Nicolas <
nicolas.provenz...@gfi.fr> wrote:

> Hi all,
>
>
>
> We are currently working on NiFi Hive processors (selectHiveQL,
> putHiveStreaming…).
>
>
>
> We are testing them with a CDH platform (and with a “Apache” platform).
>
>
>
> Hive 1.0.0 is deployed with the last releases of CDH (5.9) while Nifi is
> built with Hive 1.2.1 libraries.
>
>
>
> We then have serious compatibility issues. The “simple” selectHiveQL
> processor fails with “required client_protocol is unset” error message,
> that seems to shows version mismatch between the hive client and the hive
> server.
>
>
>
> Do you know if there are workarounds or solutions for those issues ? I
> would like to avoid rebuilding NiFi with older libraries.
>
>
>
> Thanks in advance,
>
>
>
> BR
>
>
>
> Nicolas
>
>
>
>
>
> —
> Gfi Informatique Telecom
> *Nicolas Provenzano*
>
> BU Telecom / Customer Experience
>
> *nicolas.provenz...@gfi.fr *
> —
> 2 rue Andras Beck – 92360 Meudon La Forêt
> Tél. : +33 (0)1 46 83 35 06
> Mob. : +33 (0)6 82 07 19 21
> www.gfi.world
> —
> [image: signature-img]
>
>
>


Nifi "Hive" with CDH

2016-12-14 Thread Provenzano Nicolas
Hi all,

We are currently working on NiFi Hive processors (selectHiveQL, 
putHiveStreaming...).

We are testing them with a CDH platform (and with a "Apache" platform).

Hive 1.0.0 is deployed with the last releases of CDH (5.9) while Nifi is built 
with Hive 1.2.1 libraries.

We then have serious compatibility issues. The "simple" selectHiveQL processor 
fails with "required client_protocol is unset" error message, that seems to 
shows version mismatch between the hive client and the hive server.

Do you know if there are workarounds or solutions for those issues ? I would 
like to avoid rebuilding NiFi with older libraries.

Thanks in advance,

BR

Nicolas


-
Gfi Informatique Telecom
Nicolas Provenzano
BU Telecom / Customer Experience
nicolas.provenz...@gfi.fr
-
2 rue Andras Beck - 92360 Meudon La Forêt
Tél. : +33 (0)1 46 83 35 06
Mob. : +33 (0)6 82 07 19 21
www.gfi.world
-
[signature-img]



Re: Processors on the fly for many sensor devices

2016-12-14 Thread ddewaele
Hi Andrew,

I noticed you've created a pull request to get this in the Nifi codebase and
that there were some review discussions going on. 

I was wondering what the status is on the GetTCP processor.

I've also logged some issues in your Github repo and can create some PRs if
you like.




--
View this message in context: 
http://apache-nifi-users-list.2361937.n4.nabble.com/Re-Processors-on-the-fly-for-many-sensor-devices-tp47p427.html
Sent from the Apache NiFi Users List mailing list archive at Nabble.com.