[ANNOUNCE] Apache NiFi MiNiFi 0.0.1 release

[Aldrin Piri]

Hello!

The Apache NiFi team would like to announce the release of Apache NiFi - MiNiFi 
0.0.1.

MiNiFi is a subproject of Apache NiFi.  MiNiFi provides a complementary data 
collection approach that supplements the core tenets of NiFi in dataflow 
management, focusing on the collection of data at the source of its creation.

More details on Apache NiFi MiNiFi can be found here:
http://nifi.apache.org/minifi

The release artifacts can be downloaded from here:
http://nifi.apache.org/minifi/download.html

Maven artifacts have been made available here:
https://repository.apache.org/content/repositories/releases/org/apache/nifi/minifi

Issues closed/resolved for this list can be found here:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12335481

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

Thank you!
The Apache NiFi team


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [VOTE] Release Apache NiFi 0.7.0 (RC2)

[Joe Witt]

+1 (binding).



On Sun, Jul 10, 2016 at 1:26 AM, Andy LoPresto  wrote:
> +1 (binding)
>
> Verified key signature and all hash digests.
>
> Verified build with contrib-check.
>
> Deployed in a single, standalone, unsecured instance and a secure 2-node
> cluster.
>
> Andy LoPresto
> alopre...@apache.org
> alopresto.apa...@gmail.com
> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>
> On Jul 9, 2016, at 11:47 AM, Joe Percivall 
> wrote:
>
> Hello Apache NiFi Community,
>
> I am pleased to be calling this vote for the source release of Apache NiFi,
> nifi-0.7.0.
>
> The source zip, including signatures, digests, etc. can be found at:
> https://repository.apache.org/content/repositories/orgapachenifi-1088/
> The Git tag is nifi-0.7.0-RC2
> The Git commit hash is f5629062c5e2a6c55fb62255aee74c4f25d93e7b
> *
> https://git-wip-us.apache.org/repos/asf?p=nifi.git;a=commit;h=f5629062c5e2a6c55fb62255aee74c4f25d93e7b
> *
> https://github.com/apache/nifi/commit/f5629062c5e2a6c55fb62255aee74c4f25d93e7b
>
> Checksums of nifi-0.7.0-source-release.zip:
> MD5: 3a6af39c481fb0ad3eab5a4ea1a954fd
> SHA1: 33e16b0a73242ddda91f89591c82aa5d6e9c8d21
> SHA256: 56ab3132c1fef31dcf50b716b8e08272075f92e476849360280822e0cdc3e993
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/jpercivall
> KEYS file available here:
> https://dist.apache.org/repos/dist/release/nifi/KEYS
>
> 138 issues were closed/resolved for this release:
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12335078
> Release note highlights can be found here:
> https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version0.7.0
>
> The vote will be open for 72 hours.
> Please download the release candidate and evaluate the necessary items
> including checking hashes, signatures, build from source, and test. Then
> please vote:
>
> [ ] +1 Release this package as nifi-0.7.0
> [ ] +0 no opinion
> [ ] -1 Do not release this package because...
>
> Thanks!
>
>

Re: State sharing

[Sumanth Chinthagunta]

Thanks Bryan.
Would be nice if we get support for state sharing across diffrent processors in 
the future.
-Sumo 

Sent from my iPhone

> On Jul 10, 2016, at 7:39 PM, Bryan Bende  wrote:
> 
> Sumo,
> 
> Two different processor instances (different UUIDs) can not share state
> that is stored through the state manager. For something like this you would
> likely use the distributed map cache.
> 
> As Andrew mentioned, the state is accessible across the cluster, so a
> given processor can access the state from any node because the processor
> will have the same UUID on each node.
> 
> -Bryan
> 
>> On Sunday, July 10, 2016, Andrew Grande  wrote:
>> 
>> Sumo,
>> 
>> IIRC there's a node one selects when setting state. If you invoke with a
>> cluster mode, the state will be set to a ZK by default. Otherwise just
>> local to this processor node.
>> 
>> Andrew
>> 
>> On Sun, Jul 10, 2016, 10:17 PM Sumanth Chinthagunta > >
>> wrote:
>> 
>>> If I set state from one ExecuteScript processor via stateManager , can I
>>> access same state from other processor ?
>>> Thanks
>>> Sumo
>>> 
>>> Sent from my iPhone
> 
> 
> -- 
> Sent from Gmail Mobile

Re: State sharing

[Sumanth Chinthagunta]

Andrew,
If I use cluster mode, if one processor writes state, a diffrent processor can 
read it ?
I understand that same processor on multiple nodes in the cluster can share 
state. 
Thanks
Sumo 

Sent from my iPhone

> On Jul 10, 2016, at 7:23 PM, Andrew Grande  wrote:
> 
> Sumo,
> 
> IIRC there's a node one selects when setting state. If you invoke with a
> cluster mode, the state will be set to a ZK by default. Otherwise just
> local to this processor node.
> 
> Andrew
> 
> On Sun, Jul 10, 2016, 10:17 PM Sumanth Chinthagunta 
> wrote:
> 
>> If I set state from one ExecuteScript processor via stateManager , can I
>> access same state from other processor ?
>> Thanks
>> Sumo
>> 
>> Sent from my iPhone

Re: State sharing

[Bryan Bende]

Sumo,

Two different processor instances (different UUIDs) can not share state
that is stored through the state manager. For something like this you would
likely use the distributed map cache.

As Andrew mentioned, the state is accessible across the cluster, so a
given processor can access the state from any node because the processor
will have the same UUID on each node.

-Bryan

On Sunday, July 10, 2016, Andrew Grande  wrote:

> Sumo,
>
> IIRC there's a node one selects when setting state. If you invoke with a
> cluster mode, the state will be set to a ZK by default. Otherwise just
> local to this processor node.
>
> Andrew
>
> On Sun, Jul 10, 2016, 10:17 PM Sumanth Chinthagunta  >
> wrote:
>
> > If I set state from one ExecuteScript processor via stateManager , can I
> > access same state from other processor ?
> > Thanks
> > Sumo
> >
> > Sent from my iPhone
>


-- 
Sent from Gmail Mobile

Re: State sharing

[Andrew Grande]

Sumo,

IIRC there's a node one selects when setting state. If you invoke with a
cluster mode, the state will be set to a ZK by default. Otherwise just
local to this processor node.

Andrew

On Sun, Jul 10, 2016, 10:17 PM Sumanth Chinthagunta 
wrote:

> If I set state from one ExecuteScript processor via stateManager , can I
> access same state from other processor ?
> Thanks
> Sumo
>
> Sent from my iPhone

State sharing

[Sumanth Chinthagunta]

If I set state from one ExecuteScript processor via stateManager , can I access 
same state from other processor ? 
Thanks
Sumo 

Sent from my iPhone