Re: java.lang.UnsatisfiedLinkError in PutHDFS with snappy compression.

[Jeremy Dyer]

Shweta,

Looks like your missing the snappy native library. I have seen this several
times before. Assuming your on a linux machine you have 2 options. You can
copy the libsnappy.so native library to your JAVA_HOME/jre/lib native
directory. Or you can set LD_LIBRARY_PATH to point to where your
libsnappy.so native library is located on the machine.

I believe if you closely examine the files that are being written to HDFS
with a .snappy extension you will see that in fact that are not actually
snappy compressed.

Jeremy Dyer

On Sat, Feb 6, 2016 at 1:04 PM, Joe Witt  wrote:

> Can you show what is in your core-site.xml and the proc properties.
> Also can you show the full log output?
>
> Thanks
> Joe
>
> On Sat, Feb 6, 2016 at 9:11 AM, shweta  wrote:
> > Hi All,
> >
> > I'm getting a java.lang.UnsatisfiedLinkError while adding data into
> PutHDFS
> > processor with compression codec as snappy. The error message says
> "Failed
> > to write to HDFS due to
> > org.apache.hadoop.util.NativeCodeloader.build.SupportsSnappy()Z.
> >
> > Inspite of this error, .snappy files are being written in my Hdfs.
> >
> > Has anyone faced a similar issue before or can provide any pointers.
> >
> > Thanks,
> > Shweta
> >
> >
> >
> > --
> > View this message in context:
> http://apache-nifi-developer-list.39713.n7.nabble.com/java-lang-UnsatisfiedLinkError-in-PutHDFS-with-snappy-compression-tp7182.html
> > Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>

Re: [GitHub] nifi pull request: NIFI-865 added initial support for AMQP publish...

[Oleg Zhurakousky]

David

Thank you so much for reaching out.
The reason why I am using RabbitMQ client library is because I am familiar with 
it, but as you aware AMQP is a protocol-based specification therefore it 
doesn’t mater which client library is used as long as they are compliant with 
the protocol version and current implementation is based on AMQP 0.9.1. 
Also, you are mentioning QPID client libraries. Do you have an opinion which 
one is better since as I mentioned I just went with the one I know?. As far as 
QPID JMS, are you saying that you are using QPID JMS layer to make AMQP look 
like JMS? If so in my experience layering JMS over AMQP while possible brings a 
lot of limitations of JMS. In any event would be nice to hear your thoughts on 
that.
As far as your processor implementation. Sorry I didn’t have a chance to look 
at them at the time of writing this response (will look later on), but do you 
look at them as QPID specific (i.e., QPID vs RabbitMQ)? And if so what is in 
them that is specific to QPID? The reason why I am asking (and you can see it 
from discussion on JIRA) is that with this effort we are aiming for processors 
that are compliment with specific protocol regardless of the broker 
implementation used, so it must be neutral. 

Thanks for reaching out once again.
Cheers
Oleg

> On Feb 6, 2016, at 5:19 PM, DAVID SMITH  wrote:
> 
> Hi Guys
> || This email has been sent from a virus-free computer protected by 
> Avast. 
> www.avast.com  |
> 
> 
> As you may remember I have developed some processors that publish/subscribe 
> to AMQP brokers, but I was having problems writing Junit tests for these 
> processors. I was interested to see that you have been working on NiFi Pull 
> Request 865. I have looked at your code for these processors, we are both 
> using different property descriptors to allow messages to be published and 
> pulled. I also noticed that you are using RabbitMQ libraries to connect to 
> the broker, whereas I connect to the AMQP broker using the QPID JMS 
> libraries. I can still see a use for my processors and I would still be 
> interested getting my processors uploaded to run alongside yours in a future 
> release of NiFi.I have tidied up my code and pushed it back to github:
> https://github.com/helicopterman22/nifi_amqp_processors.git
> I would appreciate your feedback Dave
> 
> 
> 
>On Wednesday, 3 February 2016, 2:05, asfgit  wrote:
> 
> 
> Github user asfgit closed the pull request at:
> 
> https://github.com/apache/nifi/pull/200
> 
> 
> ---
> If your project is set up for it, you can reply to this email and have your
> reply appear on GitHub as well. If your project does not have this feature
> enabled and wishes so, or if the feature is enabled but not working, please
> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
> with INFRA.
> ---
> 
> 

Re: [GitHub] nifi pull request: NIFI-865 added initial support for AMQP publish...

[Oleg Zhurakousky]

I hate spell checker. The last sentence in previous response should read 
compliant instead of compliment.

Sent from my iPhone

> On Feb 6, 2016, at 17:46, Oleg Zhurakousky  
> wrote:
> 
> David
> 
> Thank you so much for reaching out.
> The reason why I am using RabbitMQ client library is because I am familiar 
> with it, but as you aware AMQP is a protocol-based specification therefore it 
> doesn’t mater which client library is used as long as they are compliant with 
> the protocol version and current implementation is based on AMQP 0.9.1. 
> Also, you are mentioning QPID client libraries. Do you have an opinion which 
> one is better since as I mentioned I just went with the one I know?. As far 
> as QPID JMS, are you saying that you are using QPID JMS layer to make AMQP 
> look like JMS? If so in my experience layering JMS over AMQP while possible 
> brings a lot of limitations of JMS. In any event would be nice to hear your 
> thoughts on that.
> As far as your processor implementation. Sorry I didn’t have a chance to look 
> at them at the time of writing this response (will look later on), but do you 
> look at them as QPID specific (i.e., QPID vs RabbitMQ)? And if so what is in 
> them that is specific to QPID? The reason why I am asking (and you can see it 
> from discussion on JIRA) is that with this effort we are aiming for 
> processors that are compliment with specific protocol regardless of the 
> broker implementation used, so it must be neutral. 
> 
> Thanks for reaching out once again.
> Cheers
> Oleg
> 
>> On Feb 6, 2016, at 5:19 PM, DAVID SMITH  wrote:
>> 
>> Hi Guys
>> || This email has been sent from a virus-free computer protected by 
>> Avast. 
>> www.avast.com  |
>> 
>> 
>> As you may remember I have developed some processors that publish/subscribe 
>> to AMQP brokers, but I was having problems writing Junit tests for these 
>> processors. I was interested to see that you have been working on NiFi Pull 
>> Request 865. I have looked at your code for these processors, we are both 
>> using different property descriptors to allow messages to be published and 
>> pulled. I also noticed that you are using RabbitMQ libraries to connect to 
>> the broker, whereas I connect to the AMQP broker using the QPID JMS 
>> libraries. I can still see a use for my processors and I would still be 
>> interested getting my processors uploaded to run alongside yours in a future 
>> release of NiFi.I have tidied up my code and pushed it back to github:
>> https://github.com/helicopterman22/nifi_amqp_processors.git
>> I would appreciate your feedback Dave
>> 
>> 
>> 
>>   On Wednesday, 3 February 2016, 2:05, asfgit  wrote:
>> 
>> 
>> Github user asfgit closed the pull request at:
>> 
>>https://github.com/apache/nifi/pull/200
>> 
>> 
>> ---
>> If your project is set up for it, you can reply to this email and have your
>> reply appear on GitHub as well. If your project does not have this feature
>> enabled and wishes so, or if the feature is enabled but not working, please
>> contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
>> with INFRA.
>> ---
> 

[DISCUSS] Apache NiFi 0.5.0 RC1

[Tony Kurc]

Hello
We put together the RC1 for nifi-0.5.0. Because we found some early bugs,
as already mentioned on this list, we will not be holding a vote, but
wanted to have some community feedback and testing before putting together
another release candidate.

The source zip, including signatures, digests, etc. can be found at:
https://repository.apache.org/content/repositories/orgapachenifi-1071

The Git tag is NIFI-1379-RC1
The Git commit ID is c0c7024ffdcb77267ae60942012c7999085e4b3f
https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=c0c7024ffdcb77267ae60942012c7999085e4b3f

Checksums of nifi-0.5.0-source-release.zip:
MD5: 6ed99039e0e98e607139c37887d3d35c
SHA1: e64f72a97a5bd484d606af3d12caa41ca531c322

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/tkurc.asc

KEYS file available here:
https://dist.apache.org/repos/dist/dev/nifi/KEYS

103 issues were closed/resolved for this release:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12334158

Release note highlights can be found here:
https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version0.5.0

Please download the release candidate and evaluate, especially the ability
to build from source, and test.

Thanks,

Tony

[GitHub] nifi pull request: NIFI-1483 - ListFile warns of unable to delete ...

[apiri]

GitHub user apiri opened a pull request:

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

NIFI-1483 - ListFile warns of unable to delete old state when there was none

Correcting logic in terms of when local persistence files are removed 
during the migration process.

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

$ git pull https://github.com/apiri/incubator-nifi nifi-1483

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

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

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #206


commit 869c9a04ee11725ef22c23b69d7df0309ec71b36
Author: Aldrin Piri 
Date:   2016-02-06T23:38:00Z

NIFI-1483 Correcting logic in terms of when local persistence files are 
removed during the migration process.




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

Re: [GitHub] nifi pull request: NIFI-865 added initial support for AMQP publish...

[DAVID SMITH]

Hi Guys
|| This email has been sent from a virus-free computer protected by Avast. 
www.avast.com  |


As you may remember I have developed some processors that publish/subscribe to 
AMQP brokers, but I was having problems writing Junit tests for these 
processors. I was interested to see that you have been working on NiFi Pull 
Request 865. I have looked at your code for these processors, we are both using 
different property descriptors to allow messages to be published and pulled. I 
also noticed that you are using RabbitMQ libraries to connect to the broker, 
whereas I connect to the AMQP broker using the QPID JMS libraries. I can still 
see a use for my processors and I would still be interested getting my 
processors uploaded to run alongside yours in a future release of NiFi.I have 
tidied up my code and pushed it back to github:
https://github.com/helicopterman22/nifi_amqp_processors.git
I would appreciate your feedback Dave

 

On Wednesday, 3 February 2016, 2:05, asfgit  wrote:
 

 Github user asfgit closed the pull request at:

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


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


  

java.lang.UnsatisfiedLinkError in PutHDFS with snappy compression.

[shweta]

Hi All,

I'm getting a java.lang.UnsatisfiedLinkError while adding data into PutHDFS
processor with compression codec as snappy. The error message says "Failed
to write to HDFS due to
org.apache.hadoop.util.NativeCodeloader.build.SupportsSnappy()Z.

Inspite of this error, .snappy files are being written in my Hdfs.

Has anyone faced a similar issue before or can provide any pointers.

Thanks,
Shweta



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/java-lang-UnsatisfiedLinkError-in-PutHDFS-with-snappy-compression-tp7182.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: planning for apache nifi 0.5.0

[Joe Witt]

Hello

Would like some input/advice on
https://issues.apache.org/jira/browse/NIFI-1484.  In my initial
testing of this I would consider it worthy of getting resolved right
away.  But perhaps I'm overthinking it.  Related, but far less urgent,
is https://issues.apache.org/jira/browse/NIFI-1483.  That one is
simply an irritation but could cause pause for every user that sees
it.

Thanks
Joe

On Sat, Feb 6, 2016 at 3:41 AM, Tony Kurc  wrote:
> Awesome! I will start working on the rc
> On Feb 6, 2016 12:34 AM, "Aldrin Piri"  wrote:
>
>> All,
>>
>> Just wanted to follow up that the members of the community had completed
>> their testing against NIFI-259 and I performed the merge of that branch
>> into master.
>>
>> In that time, there were a few other issues that had some added bits of
>> functionality and improvements which were also folded in and incorporated
>> into the codebase.
>>
>> At this time, all issues exclusive of the actual release process for 0.5.0
>> have been incorporated and resolved.  Congrats on all the effort to tie
>> these items up on both the contrib and review efforts.  Looking forward to
>> the community's involvement of the upcoming RC during our release
>> evaluation and voting process.
>>
>> Thanks!
>> --aldrin
>>
>> On Thu, Feb 4, 2016 at 10:33 PM, Aldrin Piri  wrote:
>>
>> > All,
>> >
>> > Just as an update on some of the remaining items.  I have been doing some
>> > review work to help close out some of these final issues.  Finished
>> review
>> > and merged 1257 and 1259 which brings a lot of great security and
>> > encryption functions that will help a long way for providing a nice
>> > foundation for additional support across the entirety of the project.
>> >
>> > Along with several of the members of the community, I have been reviewing
>> > and providing feedback 259 along with several other members of the
>> > community and its incorporated tickets of 1223, 1379.  We are doing some
>> > final testing particularly surrounding its interactions and utilization
>> of
>> > Kerberos.  Once that wraps up, we will be able to merge that in, closing
>> > the last of the items scheduled for this release.
>> >
>> > Thanks!
>> > Aldrin
>> >
>> > On Thu, Feb 4, 2016 at 9:53 AM, Joe Witt  wrote:
>> >
>> >> Tony
>> >>
>> >> Agreed.  I will work through these as well and try to ensure the
>> >> wording accurately reflect what happened.  The release notes are a
>> >> really important piece of communication we need to get right.
>> >>
>> >> Thanks
>> >> Joe
>> >>
>> >> On Thu, Feb 4, 2016 at 6:04 AM, Tony Kurc  wrote:
>> >> > I am prepping for the release, going through the jiras that have been
>> >> > closed, I think several have a description that does not match. Good
>> >> > example is:
>> >> >
>> >> > https://issues.apache.org/jira/browse/NIFI-1325
>> >> >
>> >> > I believe the final scope of the patch surpassed the original
>> >> description.
>> >> > Should this be adjusted for people perusing the JIRA report we link to
>> >> in
>> >> > our release notes? I'd say yes. I made a couple small edits to some
>> >> tickets
>> >> > already for increased readability. One change I wanted to make was
>> >> change
>> >> > NIFI-259 to "New Feature" rather than subtask, but I was concerned
>> about
>> >> > this disrupting folks.
>> >> >
>> >> > I think a quick consistency and spell check would be good - I've had
>> >> > several people mention out of band that prior release notes had a
>> couple
>> >> > errors. Apparently people love the release notes page on the JIRA
>> >> > NIFI-1107 is done, just needs a merge, which I'll do tonight.
>> >> >
>> >> > On Wed, Feb 3, 2016 at 4:32 PM, Joe Witt  wrote:
>> >> >
>> >> >> Latest update for all
>> >> >>
>> >> >> You can see the current status here [1].
>> >> >>
>> >> >> Looks like several tickets but really it is three efforts:
>> >> >> 1) Improve encryption options in EncryptContent NIFI-1257,1259
>> >> >> 2) Provide state management as a framework function
>> NIFI-259,1223,1339
>> >> >> 3) Support multi-part S3 uploads NIFI-1107
>> >> >>
>> >> >> Based on comments on each they are just in very late stage/detailed
>> >> >> review.  So we're close.
>> >> >>
>> >> >> Thanks
>> >> >> Joe
>> >> >>
>> >> >> [1]
>> >> >>
>> >>
>> https://issues.apache.org/jira/browse/NIFI-1339?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.5.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>> >> >>
>> >> >> On Thu, Jan 21, 2016 at 12:55 AM, Joe Witt 
>> wrote:
>> >> >> > Team
>> >> >> >
>> >> >> > Did a full round of 050 JIRA cleanup this evening.  Great progress
>> is
>> >> >> > being made.
>> >> >> >
>> >> >> > For the proposed NiFi 050 release schedule above we have about 10
>> >> days
>> >> >> > of code time left.  There is a pretty large backlog of patch
>> awaiting
>> >> >> 

Does Nifi-ambari reporting supports Ambari version 2.1.1

[shweta]

Hi all,

We are facing issue in setting up nifi service in Ambari (version 2.1.1).
Getting following exception
"unsupported or invalid service in stack". 
Just want to make sure that it is or not due to version incompatibility.

Thanks,
Shweta



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Does-Nifi-ambari-reporting-supports-Ambari-version-2-1-1-tp7178.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Does Nifi-ambari reporting supports Ambari version 2.1.1

[shweta]

Yes Joe, we followed that same document.


Regards,
Shweta



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Does-Nifi-ambari-reporting-supports-Ambari-version-2-1-1-tp7178p7180.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: java.lang.UnsatisfiedLinkError in PutHDFS with snappy compression.

[Joe Witt]

Can you show what is in your core-site.xml and the proc properties.
Also can you show the full log output?

Thanks
Joe

On Sat, Feb 6, 2016 at 9:11 AM, shweta  wrote:
> Hi All,
>
> I'm getting a java.lang.UnsatisfiedLinkError while adding data into PutHDFS
> processor with compression codec as snappy. The error message says "Failed
> to write to HDFS due to
> org.apache.hadoop.util.NativeCodeloader.build.SupportsSnappy()Z.
>
> Inspite of this error, .snappy files are being written in my Hdfs.
>
> Has anyone faced a similar issue before or can provide any pointers.
>
> Thanks,
> Shweta
>
>
>
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/java-lang-UnsatisfiedLinkError-in-PutHDFS-with-snappy-compression-tp7182.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Does Nifi-ambari reporting supports Ambari version 2.1.1

[shweta]

Thanks Bryan !! that worked.

Regards,
Shweta



--
View this message in context: 
http://apache-nifi-developer-list.39713.n7.nabble.com/Does-Nifi-ambari-reporting-supports-Ambari-version-2-1-1-tp7178p7184.html
Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Does Nifi-ambari reporting supports Ambari version 2.1.1

[Joe Witt]

Shweta,

Have you had a chance to run through the instructions here
https://cwiki.apache.org/confluence/display/NIFI/Ambari+Metrics?

I also am not sure which version we support.  We definitely should
have that documented but it wasn't immediately obvious if we do.
Bryan?

Thanks
Joe

On Sat, Feb 6, 2016 at 7:36 AM, shweta  wrote:
> Hi all,
>
> We are facing issue in setting up nifi service in Ambari (version 2.1.1).
> Getting following exception
> "unsupported or invalid service in stack".
> Just want to make sure that it is or not due to version incompatibility.
>
> Thanks,
> Shweta
>
>
>
> --
> View this message in context: 
> http://apache-nifi-developer-list.39713.n7.nabble.com/Does-Nifi-ambari-reporting-supports-Ambari-version-2-1-1-tp7178.html
> Sent from the Apache NiFi Developer List mailing list archive at Nabble.com.

Re: Does Nifi-ambari reporting supports Ambari version 2.1.1

[Bryan Bende]

Joe/Shweta,

I view the Ambari stuff as two different pieces... the AmbariReportingTask
in NiFi which was developed against Ambari 2.1, but I believe should work
against any 2.X version because the Ambari Metrics Service was introduced
in 2.0.0. The reporting task can send over metrics independent of the
service definition, there does not even need to be a NiFi service installed
in Ambari for the metrics to be sent over.

The service definition is what installs the service in Ambari and gives you
the dashboard so you can see the metrics. The service definition that is
provided on the Wiki page is an example service that works only with HDP
2.3. The directory structure would have to be modified for a different
version. It may be as simple as changing "stacks/HDP/2.3" to
"stacks/HDP/".

-Bryan


On Sat, Feb 6, 2016 at 11:11 AM, shweta  wrote:

> Yes Joe, we followed that same document.
>
>
> Regards,
> Shweta
>
>
>
> --
> View this message in context:
> http://apache-nifi-developer-list.39713.n7.nabble.com/Does-Nifi-ambari-reporting-supports-Ambari-version-2-1-1-tp7178p7180.html
> Sent from the Apache NiFi Developer List mailing list archive at
> Nabble.com.
>

[GitHub] nifi pull request: NIFI-1483 - ListFile warns of unable to delete ...

[trkurc]

Github user trkurc commented on the pull request:

https://github.com/apache/nifi/pull/206#issuecomment-180928291
  
@apiri - +1, works great. Only bit of weirdness, if the old state file was 
chmod 0400'ed (i.e., only read access) when I launched nifi, it was still 
deleted after migration. chattr +i'ing the file kept it from being deleted 
though. may be something for the migration guide.


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

[GitHub] nifi pull request: NIFI-1483 - ListFile warns of unable to delete ...

[trkurc]

Github user trkurc commented on the pull request:

https://github.com/apache/nifi/pull/206#issuecomment-180922873
  
logic looks like it should cover all conditions, tests are reasonable, 
doing some tests


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

Re: java.lang.UnsatisfiedLinkError in PutHDFS with snappy compression.

[Matt Burgess]

To add to Jeremy's last point, even after the library is present, the files 
must be greater than the HDFS block size (default is 64 MB I think?) or 
Hadoop-snappy will also not compress them.

Sent from my iPhone

> On Feb 6, 2016, at 5:41 PM, Jeremy Dyer  wrote:
> 
> Shweta,
> 
> Looks like your missing the snappy native library. I have seen this several
> times before. Assuming your on a linux machine you have 2 options. You can
> copy the libsnappy.so native library to your JAVA_HOME/jre/lib native
> directory. Or you can set LD_LIBRARY_PATH to point to where your
> libsnappy.so native library is located on the machine.
> 
> I believe if you closely examine the files that are being written to HDFS
> with a .snappy extension you will see that in fact that are not actually
> snappy compressed.
> 
> Jeremy Dyer
> 
>> On Sat, Feb 6, 2016 at 1:04 PM, Joe Witt  wrote:
>> 
>> Can you show what is in your core-site.xml and the proc properties.
>> Also can you show the full log output?
>> 
>> Thanks
>> Joe
>> 
>>> On Sat, Feb 6, 2016 at 9:11 AM, shweta  wrote:
>>> Hi All,
>>> 
>>> I'm getting a java.lang.UnsatisfiedLinkError while adding data into
>> PutHDFS
>>> processor with compression codec as snappy. The error message says
>> "Failed
>>> to write to HDFS due to
>>> org.apache.hadoop.util.NativeCodeloader.build.SupportsSnappy()Z.
>>> 
>>> Inspite of this error, .snappy files are being written in my Hdfs.
>>> 
>>> Has anyone faced a similar issue before or can provide any pointers.
>>> 
>>> Thanks,
>>> Shweta
>>> 
>>> 
>>> 
>>> --
>>> View this message in context:
>> http://apache-nifi-developer-list.39713.n7.nabble.com/java-lang-UnsatisfiedLinkError-in-PutHDFS-with-snappy-compression-tp7182.html
>>> Sent from the Apache NiFi Developer List mailing list archive at
>> Nabble.com.
>> 

Re: planning for apache nifi 0.5.0

[Tony Kurc]

Awesome! I will start working on the rc
On Feb 6, 2016 12:34 AM, "Aldrin Piri"  wrote:

> All,
>
> Just wanted to follow up that the members of the community had completed
> their testing against NIFI-259 and I performed the merge of that branch
> into master.
>
> In that time, there were a few other issues that had some added bits of
> functionality and improvements which were also folded in and incorporated
> into the codebase.
>
> At this time, all issues exclusive of the actual release process for 0.5.0
> have been incorporated and resolved.  Congrats on all the effort to tie
> these items up on both the contrib and review efforts.  Looking forward to
> the community's involvement of the upcoming RC during our release
> evaluation and voting process.
>
> Thanks!
> --aldrin
>
> On Thu, Feb 4, 2016 at 10:33 PM, Aldrin Piri  wrote:
>
> > All,
> >
> > Just as an update on some of the remaining items.  I have been doing some
> > review work to help close out some of these final issues.  Finished
> review
> > and merged 1257 and 1259 which brings a lot of great security and
> > encryption functions that will help a long way for providing a nice
> > foundation for additional support across the entirety of the project.
> >
> > Along with several of the members of the community, I have been reviewing
> > and providing feedback 259 along with several other members of the
> > community and its incorporated tickets of 1223, 1379.  We are doing some
> > final testing particularly surrounding its interactions and utilization
> of
> > Kerberos.  Once that wraps up, we will be able to merge that in, closing
> > the last of the items scheduled for this release.
> >
> > Thanks!
> > Aldrin
> >
> > On Thu, Feb 4, 2016 at 9:53 AM, Joe Witt  wrote:
> >
> >> Tony
> >>
> >> Agreed.  I will work through these as well and try to ensure the
> >> wording accurately reflect what happened.  The release notes are a
> >> really important piece of communication we need to get right.
> >>
> >> Thanks
> >> Joe
> >>
> >> On Thu, Feb 4, 2016 at 6:04 AM, Tony Kurc  wrote:
> >> > I am prepping for the release, going through the jiras that have been
> >> > closed, I think several have a description that does not match. Good
> >> > example is:
> >> >
> >> > https://issues.apache.org/jira/browse/NIFI-1325
> >> >
> >> > I believe the final scope of the patch surpassed the original
> >> description.
> >> > Should this be adjusted for people perusing the JIRA report we link to
> >> in
> >> > our release notes? I'd say yes. I made a couple small edits to some
> >> tickets
> >> > already for increased readability. One change I wanted to make was
> >> change
> >> > NIFI-259 to "New Feature" rather than subtask, but I was concerned
> about
> >> > this disrupting folks.
> >> >
> >> > I think a quick consistency and spell check would be good - I've had
> >> > several people mention out of band that prior release notes had a
> couple
> >> > errors. Apparently people love the release notes page on the JIRA
> >> > NIFI-1107 is done, just needs a merge, which I'll do tonight.
> >> >
> >> > On Wed, Feb 3, 2016 at 4:32 PM, Joe Witt  wrote:
> >> >
> >> >> Latest update for all
> >> >>
> >> >> You can see the current status here [1].
> >> >>
> >> >> Looks like several tickets but really it is three efforts:
> >> >> 1) Improve encryption options in EncryptContent NIFI-1257,1259
> >> >> 2) Provide state management as a framework function
> NIFI-259,1223,1339
> >> >> 3) Support multi-part S3 uploads NIFI-1107
> >> >>
> >> >> Based on comments on each they are just in very late stage/detailed
> >> >> review.  So we're close.
> >> >>
> >> >> Thanks
> >> >> Joe
> >> >>
> >> >> [1]
> >> >>
> >>
> https://issues.apache.org/jira/browse/NIFI-1339?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.5.0%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >> >>
> >> >> On Thu, Jan 21, 2016 at 12:55 AM, Joe Witt 
> wrote:
> >> >> > Team
> >> >> >
> >> >> > Did a full round of 050 JIRA cleanup this evening.  Great progress
> is
> >> >> > being made.
> >> >> >
> >> >> > For the proposed NiFi 050 release schedule above we have about 10
> >> days
> >> >> > of code time left.  There is a pretty large backlog of patch
> awaiting
> >> >> > items currently showing as aligned to 050.  See here [1].
> >> >> >
> >> >> > Also there are 25 (as of this writing) open tickets.  See here [2].
> >> >> >
> >> >> > For the proposed goals of the release as listed previous in this
> >> >> > thread it appears the following are likely to occur in 050:
> >> >> >   Improved encryption handling: NIFI-1324,1314,1259,
> >> >> >   Improved Hive/Kite interaction: NIFI-1193
> >> >> >   Interactive Queue Management: NIFI-108
> >> >> >   Support for numerous scripting/languages: NIFI-210
> >> >> >   Support for state management: