Re: [DISCUSS] On HBase client retries (NIFI-6197)
We could certainly implement some kind of "sanity check" via HBase code,
but I think the thing that is missing is the logical way to validate
this in NiFi itself.
Something like...
```
Configuration conf = HBaseConfiguration.create();
conf.setInt("hbase.rpc.timeout", 5000);
try (Connection conn = ConnectionFactory.create(conf)) {
// do sanity check
}
Configuration conf2 = new Configuration(conf);
conf2.setInt("hbase.rpc.timeout", 25000);
try (Connection conn = ConnectionFactory.create(conf2)) {
// do real hbase-y stuff
}
```
Maybe instead of requiring an implicit way to do this (requiring NiFi
code changes), we could solve the problem at the "human level": create
docs that walk people through how to push a dummy record through the
service/processor with the low configuration of timeouts and retries?
Make the "sanity check" a human operation and just expose the ability to
set timeout/retries via the controller service?
On 2/18/20 4:36 PM, Lars Francke wrote:
Hi,
Josh, thanks for bringing it up here again.
I'm happy to revive the PR with whatever the outcome of this thread is.
It came up today because another client complained about how "unstable"
HBase is on NiFi.
@Josh: As the whole issue is only the initial connect can we have a
different timeout setting there? I have to admit I don't know.
Cheers,
Lars
On Tue, Feb 18, 2020 at 8:11 PM Pierre Villard
wrote:
Good point, I don't think we can do that on a controller service.
Le mar. 18 févr. 2020 à 11:06, Bryan Bende a écrit :
That could make it a little better, but I can't remember, can we
terminate on a controller service?
The issue here would be on first time enabling the the HBase client
service, so before even getting to a processor.
On Tue, Feb 18, 2020 at 2:00 PM Pierre Villard
wrote:
Bryan,
I didn't follow the whole discussion so I apologize if I'm saying
something
stupid here. Now that we have the possibility to terminate threads in a
processor, would that solve the issue?
Pierre
Le mar. 18 févr. 2020 à 10:52, Bryan Bende a écrit
:
Hi Josh,
The problem isn't so much about the retries within the flow, its more
about setting up the service for the first time.
A common scenario for users was the following:
- Create a new HBase client service
- Enter some config that wasn't quite correct, possibly hostnames
that
weren't reachable from nifi as one example
- Enable service and enter retry loop
- Attempt to disable service to fix config, but have to wait 5+ mins
for the retries to finish
Maybe a lazy initialization of the connection on our side would help
here, although it would just be moving the problem until later (i.e.
service immediately enables because nothing is happening, then they
find out about config problems later when a flow file hits an hbase
processor).
I guess the ideal scenario would be to have different logic for
initializing the connection vs. using it, so that there wouldn't be
retries during initialization.
-Bryan
On Tue, Feb 18, 2020 at 1:21 PM Josh Elser
wrote:
Hiya!
LarsF brought this up in the apache-hbase slack account and it
caught my
eye. Sending a note here since the PR is closed where this was
being
discussed before[1].
I understand Bryan's concerns that misconfiguration of an HBase
processor with a high number of retries and back-off can create a
situation in which the processing of a single FlowFile will take a
very
long time to hit the onFailure state.
However, as an HBase developer, I can confidently state that
hbase.client.retries=1 will create scenarios in which you'll be
pushing
a FlowFile through a retry loop inside of NiFi for things which
should
be implicitly retried inside of the HBase client.
For example, if a Region is being moved between two RegionServers
and an
HBase processor is trying to read/write to that Region, the client
will
see an exception. This is a "retriable" exception in HBase-parlance
which means that HBase client code would automatically re-process
that
request (looking for the new location of that Region first). In
most
cases, the subsequent RPC would succeed and the caller is
non-the-wiser
and the whole retry logic took 1's of milliseconds.
My first idea was also what Lars' had suggested -- can we come up
with a
sanity check to validate "correct" configuration for the processor
before we throw the waterfall of data at it? I can respect if
processors
don't have a "good" hook to do such a check.
What _would_ be the ideal semantics from NiFi's? perspective? We
have
the ability to implicitly retry operations and also control the
retry
backoff values. Is there something more we could do from the HBase
side,
given what y'all have seen from the battlefield?
Thanks!
- Josh
[1] https://github.com/apache/nifi/pull/3425
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
+1 (non-binding) Verified signature, checksum Built, started. Created a flow, sent and processed flowfiles via S2S. On Tue, Feb 18, 2020 at 11:47 PM Joey Frazee wrote: > +1 (non-binding) > Verified checksums, signatures, and commit hash > Ran build and all tests on OpenJDK 1.8.0_242 on Linux and OS X > Created small cluster and ran some flows including load balancing > On Feb 18, 2020, 12:28 PM -0800, Robert Fellows , > wrote: > +1 (non-binding) > > * verified sigs and hashes > * full build on java 11 > * tested a few processors, basic functionality. > > Thanks for RM'ing, Joe! > > > > On Tue, Feb 18, 2020 at 2:31 PM Matt Gilman > wrote: > > +1 (binding) > > - Check signatures and hashes > - Full build > - Verified some of the JIRAs addressed in this release > > Thanks for RMing Joe! > > On Tue, Feb 18, 2020 at 2:01 PM Matt Burgess wrote: > > +1 (binding) ran through release helper and various flows. Thanks Joe > for RM'ing! > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > Hello, > > I am pleased to be calling this vote for the source release of Apache > NiFi > 1.11.2. > > The source zip, including signatures, digests, etc. can be found at: > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > The source being voted upon and the convenience binaries can be found > at: > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > A helpful reminder on how the release candidate verification process > works: > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > The Git tag is nifi-1.11.2-RC1 > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > Checksums of nifi-1.11.2-source-release.zip: > SHA256: > 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > SHA512: > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > Release artifacts are signed with the following key: > https://people.apache.org/keys/committer/joewitt.asc > > KEYS file available here: > https://dist.apache.org/repos/dist/release/nifi/KEYS > > 14 issues were closed/resolved for this release: > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > Release note highlights can be found here: > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > 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-1.11.2 > [ ] +0 no opinion > [ ] -1 Do not release this package because... > > > > > -- > --- > Rob Fellows >
Re: NIFI Flow Design System
I will email glenn directly as i dont think he is on the list... On Tue, Feb 18, 2020 at 4:27 PM Glenn Barnard wrote: > Second email > > -- Forwarded message - > From: Glenn Barnard > Date: Sat, Feb 15, 2020 at 7:17 AM > Subject: NIFI Flow Design System > To: > > > Hi, I recently had the pleasure of using NIFI at DXC Technology and was > wondering if the FDS component was available to use in my own applications. > I wrote a BPM Workflow engine, but the XML is becoming unmanageable. So, > I'm looking for a tool I can insert into my web apps to help me in this > development. > > My primary app is Job Manager, which can already perform a series of tasks, > but Iit needs better flow control that is easy to create, store and test. > > Please advise if the Flow Design System would be a good fit for my purposes > and what I'd have to do to download it. > > Thank you so much! >
Fwd: NIFI Flow Design System
Second email -- Forwarded message - From: Glenn Barnard Date: Sat, Feb 15, 2020 at 7:17 AM Subject: NIFI Flow Design System To: Hi, I recently had the pleasure of using NIFI at DXC Technology and was wondering if the FDS component was available to use in my own applications. I wrote a BPM Workflow engine, but the XML is becoming unmanageable. So, I'm looking for a tool I can insert into my web apps to help me in this development. My primary app is Job Manager, which can already perform a series of tasks, but Iit needs better flow control that is easy to create, store and test. Please advise if the Flow Design System would be a good fit for my purposes and what I'd have to do to download it. Thank you so much!
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
+1 (non-binding) * verified sigs and hashes * full build on java 11 * tested a few processors, basic functionality. Thanks for RM'ing, Joe! On Tue, Feb 18, 2020 at 2:31 PM Matt Gilman wrote: > +1 (binding) > > - Check signatures and hashes > - Full build > - Verified some of the JIRAs addressed in this release > > Thanks for RMing Joe! > > On Tue, Feb 18, 2020 at 2:01 PM Matt Burgess wrote: > > > +1 (binding) ran through release helper and various flows. Thanks Joe > > for RM'ing! > > > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > > > > > Hello, > > > > > > I am pleased to be calling this vote for the source release of Apache > > NiFi > > > 1.11.2. > > > > > > The source zip, including signatures, digests, etc. can be found at: > > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > > > The source being voted upon and the convenience binaries can be found > at: > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > > > A helpful reminder on how the release candidate verification process > > works: > > > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > > > The Git tag is nifi-1.11.2-RC1 > > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > Checksums of nifi-1.11.2-source-release.zip: > > > SHA256: > 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > > SHA512: > > > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > > > Release artifacts are signed with the following key: > > > https://people.apache.org/keys/committer/joewitt.asc > > > > > > KEYS file available here: > > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > > > 14 issues were closed/resolved for this release: > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > > > Release note highlights can be found here: > > > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > > > 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-1.11.2 > > > [ ] +0 no opinion > > > [ ] -1 Do not release this package because... > > > -- --- Rob Fellows
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
+1 (binding) - Check signatures and hashes - Full build - Verified some of the JIRAs addressed in this release Thanks for RMing Joe! On Tue, Feb 18, 2020 at 2:01 PM Matt Burgess wrote: > +1 (binding) ran through release helper and various flows. Thanks Joe > for RM'ing! > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > > > Hello, > > > > I am pleased to be calling this vote for the source release of Apache > NiFi > > 1.11.2. > > > > The source zip, including signatures, digests, etc. can be found at: > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > The source being voted upon and the convenience binaries can be found at: > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > A helpful reminder on how the release candidate verification process > works: > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > The Git tag is nifi-1.11.2-RC1 > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > Checksums of nifi-1.11.2-source-release.zip: > > SHA256: 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > SHA512: > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > Release artifacts are signed with the following key: > > https://people.apache.org/keys/committer/joewitt.asc > > > > KEYS file available here: > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > 14 issues were closed/resolved for this release: > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > Release note highlights can be found here: > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > 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-1.11.2 > > [ ] +0 no opinion > > [ ] -1 Do not release this package because... >
Re: [DISCUSS] On HBase client retries (NIFI-6197)
Good point, I don't think we can do that on a controller service. Le mar. 18 févr. 2020 à 11:06, Bryan Bende a écrit : > That could make it a little better, but I can't remember, can we > terminate on a controller service? > > The issue here would be on first time enabling the the HBase client > service, so before even getting to a processor. > > On Tue, Feb 18, 2020 at 2:00 PM Pierre Villard > wrote: > > > > Bryan, > > > > I didn't follow the whole discussion so I apologize if I'm saying > something > > stupid here. Now that we have the possibility to terminate threads in a > > processor, would that solve the issue? > > > > Pierre > > > > Le mar. 18 févr. 2020 à 10:52, Bryan Bende a écrit : > > > > > Hi Josh, > > > > > > The problem isn't so much about the retries within the flow, its more > > > about setting up the service for the first time. > > > > > > A common scenario for users was the following: > > > > > > - Create a new HBase client service > > > - Enter some config that wasn't quite correct, possibly hostnames that > > > weren't reachable from nifi as one example > > > - Enable service and enter retry loop > > > - Attempt to disable service to fix config, but have to wait 5+ mins > > > for the retries to finish > > > > > > Maybe a lazy initialization of the connection on our side would help > > > here, although it would just be moving the problem until later (i.e. > > > service immediately enables because nothing is happening, then they > > > find out about config problems later when a flow file hits an hbase > > > processor). > > > > > > I guess the ideal scenario would be to have different logic for > > > initializing the connection vs. using it, so that there wouldn't be > > > retries during initialization. > > > > > > -Bryan > > > > > > > > > > > > On Tue, Feb 18, 2020 at 1:21 PM Josh Elser > wrote: > > > > > > > > Hiya! > > > > > > > > LarsF brought this up in the apache-hbase slack account and it > caught my > > > > eye. Sending a note here since the PR is closed where this was being > > > > discussed before[1]. > > > > > > > > I understand Bryan's concerns that misconfiguration of an HBase > > > > processor with a high number of retries and back-off can create a > > > > situation in which the processing of a single FlowFile will take a > very > > > > long time to hit the onFailure state. > > > > > > > > However, as an HBase developer, I can confidently state that > > > > hbase.client.retries=1 will create scenarios in which you'll be > pushing > > > > a FlowFile through a retry loop inside of NiFi for things which > should > > > > be implicitly retried inside of the HBase client. > > > > > > > > For example, if a Region is being moved between two RegionServers > and an > > > > HBase processor is trying to read/write to that Region, the client > will > > > > see an exception. This is a "retriable" exception in HBase-parlance > > > > which means that HBase client code would automatically re-process > that > > > > request (looking for the new location of that Region first). In most > > > > cases, the subsequent RPC would succeed and the caller is > non-the-wiser > > > > and the whole retry logic took 1's of milliseconds. > > > > > > > > My first idea was also what Lars' had suggested -- can we come up > with a > > > > sanity check to validate "correct" configuration for the processor > > > > before we throw the waterfall of data at it? I can respect if > processors > > > > don't have a "good" hook to do such a check. > > > > > > > > What _would_ be the ideal semantics from NiFi's? perspective? We have > > > > the ability to implicitly retry operations and also control the retry > > > > backoff values. Is there something more we could do from the HBase > side, > > > > given what y'all have seen from the battlefield? > > > > > > > > Thanks! > > > > > > > > - Josh > > > > > > > > [1] https://github.com/apache/nifi/pull/3425 > > > >
Re: [DISCUSS] On HBase client retries (NIFI-6197)
Bryan, I didn't follow the whole discussion so I apologize if I'm saying something stupid here. Now that we have the possibility to terminate threads in a processor, would that solve the issue? Pierre Le mar. 18 févr. 2020 à 10:52, Bryan Bende a écrit : > Hi Josh, > > The problem isn't so much about the retries within the flow, its more > about setting up the service for the first time. > > A common scenario for users was the following: > > - Create a new HBase client service > - Enter some config that wasn't quite correct, possibly hostnames that > weren't reachable from nifi as one example > - Enable service and enter retry loop > - Attempt to disable service to fix config, but have to wait 5+ mins > for the retries to finish > > Maybe a lazy initialization of the connection on our side would help > here, although it would just be moving the problem until later (i.e. > service immediately enables because nothing is happening, then they > find out about config problems later when a flow file hits an hbase > processor). > > I guess the ideal scenario would be to have different logic for > initializing the connection vs. using it, so that there wouldn't be > retries during initialization. > > -Bryan > > > > On Tue, Feb 18, 2020 at 1:21 PM Josh Elser wrote: > > > > Hiya! > > > > LarsF brought this up in the apache-hbase slack account and it caught my > > eye. Sending a note here since the PR is closed where this was being > > discussed before[1]. > > > > I understand Bryan's concerns that misconfiguration of an HBase > > processor with a high number of retries and back-off can create a > > situation in which the processing of a single FlowFile will take a very > > long time to hit the onFailure state. > > > > However, as an HBase developer, I can confidently state that > > hbase.client.retries=1 will create scenarios in which you'll be pushing > > a FlowFile through a retry loop inside of NiFi for things which should > > be implicitly retried inside of the HBase client. > > > > For example, if a Region is being moved between two RegionServers and an > > HBase processor is trying to read/write to that Region, the client will > > see an exception. This is a "retriable" exception in HBase-parlance > > which means that HBase client code would automatically re-process that > > request (looking for the new location of that Region first). In most > > cases, the subsequent RPC would succeed and the caller is non-the-wiser > > and the whole retry logic took 1's of milliseconds. > > > > My first idea was also what Lars' had suggested -- can we come up with a > > sanity check to validate "correct" configuration for the processor > > before we throw the waterfall of data at it? I can respect if processors > > don't have a "good" hook to do such a check. > > > > What _would_ be the ideal semantics from NiFi's? perspective? We have > > the ability to implicitly retry operations and also control the retry > > backoff values. Is there something more we could do from the HBase side, > > given what y'all have seen from the battlefield? > > > > Thanks! > > > > - Josh > > > > [1] https://github.com/apache/nifi/pull/3425 >
Re: [DISCUSS] On HBase client retries (NIFI-6197)
Hi Josh, The problem isn't so much about the retries within the flow, its more about setting up the service for the first time. A common scenario for users was the following: - Create a new HBase client service - Enter some config that wasn't quite correct, possibly hostnames that weren't reachable from nifi as one example - Enable service and enter retry loop - Attempt to disable service to fix config, but have to wait 5+ mins for the retries to finish Maybe a lazy initialization of the connection on our side would help here, although it would just be moving the problem until later (i.e. service immediately enables because nothing is happening, then they find out about config problems later when a flow file hits an hbase processor). I guess the ideal scenario would be to have different logic for initializing the connection vs. using it, so that there wouldn't be retries during initialization. -Bryan On Tue, Feb 18, 2020 at 1:21 PM Josh Elser wrote: > > Hiya! > > LarsF brought this up in the apache-hbase slack account and it caught my > eye. Sending a note here since the PR is closed where this was being > discussed before[1]. > > I understand Bryan's concerns that misconfiguration of an HBase > processor with a high number of retries and back-off can create a > situation in which the processing of a single FlowFile will take a very > long time to hit the onFailure state. > > However, as an HBase developer, I can confidently state that > hbase.client.retries=1 will create scenarios in which you'll be pushing > a FlowFile through a retry loop inside of NiFi for things which should > be implicitly retried inside of the HBase client. > > For example, if a Region is being moved between two RegionServers and an > HBase processor is trying to read/write to that Region, the client will > see an exception. This is a "retriable" exception in HBase-parlance > which means that HBase client code would automatically re-process that > request (looking for the new location of that Region first). In most > cases, the subsequent RPC would succeed and the caller is non-the-wiser > and the whole retry logic took 1's of milliseconds. > > My first idea was also what Lars' had suggested -- can we come up with a > sanity check to validate "correct" configuration for the processor > before we throw the waterfall of data at it? I can respect if processors > don't have a "good" hook to do such a check. > > What _would_ be the ideal semantics from NiFi's? perspective? We have > the ability to implicitly retry operations and also control the retry > backoff values. Is there something more we could do from the HBase side, > given what y'all have seen from the battlefield? > > Thanks! > > - Josh > > [1] https://github.com/apache/nifi/pull/3425
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
+1 (non-binding) -Ran full build -Created 10-node cluster on Azure, deployed flow. -Verified basic functionality Looks good. Thanks! On Tue, Feb 18, 2020 at 10:02 AM Bryan Bende wrote: > +1 (binding) > > - Verified signatures/hashes & LICENSES/NOTICES > - Ran full build > - Ran secure cluster with load balanced connections > > Looks good, thanks! > > On Tue, Feb 18, 2020 at 11:56 AM Pierre Villard > wrote: > > > > +1, binding > > > > Verified signatures, built and deployed a secured cluster on GCP, ran > some > > flows to verify the load balanced connections. LGTM. > > > > Thanks Joe for taking care of this! > > > > Le mar. 18 févr. 2020 à 08:09, Chad Zobrisky a > écrit : > > > > > Ran over the release document and checked everything off. Looks good, > ran a > > > few basic flows to test normal functionality. > > > > > > +1 non-binding > > > > > > Chad > > > > > > On Tue, Feb 18, 2020 at 11:02 AM Joe Witt wrote: > > > > > > > The release vote remains open for Rc1 as of now. > > > > > > > > On Tue, Feb 18, 2020 at 9:45 AM Marc Parisi > wrote: > > > > > > > > > ran this over the weekend but forgot to respond. > > > > > > > > > > I saw the other chain, which reminded me to respond. Sorry about > > > that... > > > > > > > > > > Ran my typical release build following the helper guide. Used my > > > typical > > > > > test flow. > > > > > > > > > > +1 if we can extend the vote, otherwise I'll jump on RC2. > > > > > > > > > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt > wrote: > > > > > > > > > > > Hello, > > > > > > > > > > > > I am pleased to be calling this vote for the source release of > Apache > > > > > NiFi > > > > > > 1.11.2. > > > > > > > > > > > > The source zip, including signatures, digests, etc. can be found > at: > > > > > > > > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > > > > > > > > > The source being voted upon and the convenience binaries can be > found > > > > at: > > > > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > > > > > > > > > A helpful reminder on how the release candidate verification > process > > > > > works: > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > > > > > > > > > The Git tag is nifi-1.11.2-RC1 > > > > > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > > > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > > > > > Checksums of nifi-1.11.2-source-release.zip: > > > > > > SHA256: > > > > 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > > > > > SHA512: > > > > > > > > > > > > > > > > > > > > > > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > > > > > > > > > Release artifacts are signed with the following key: > > > > > > https://people.apache.org/keys/committer/joewitt.asc > > > > > > > > > > > > KEYS file available here: > > > > > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > > > > > > > > > 14 issues were closed/resolved for this release: > > > > > > > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > > > > > > > > > Release note highlights can be found here: > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > > > > > > > > > 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-1.11.2 > > > > > > [ ] +0 no opinion > > > > > > [ ] -1 Do not release this package because... > > > > > > > > > > > > > > > > > > >
[DISCUSS] On HBase client retries (NIFI-6197)
Hiya! LarsF brought this up in the apache-hbase slack account and it caught my eye. Sending a note here since the PR is closed where this was being discussed before[1]. I understand Bryan's concerns that misconfiguration of an HBase processor with a high number of retries and back-off can create a situation in which the processing of a single FlowFile will take a very long time to hit the onFailure state. However, as an HBase developer, I can confidently state that hbase.client.retries=1 will create scenarios in which you'll be pushing a FlowFile through a retry loop inside of NiFi for things which should be implicitly retried inside of the HBase client. For example, if a Region is being moved between two RegionServers and an HBase processor is trying to read/write to that Region, the client will see an exception. This is a "retriable" exception in HBase-parlance which means that HBase client code would automatically re-process that request (looking for the new location of that Region first). In most cases, the subsequent RPC would succeed and the caller is non-the-wiser and the whole retry logic took 1's of milliseconds. My first idea was also what Lars' had suggested -- can we come up with a sanity check to validate "correct" configuration for the processor before we throw the waterfall of data at it? I can respect if processors don't have a "good" hook to do such a check. What _would_ be the ideal semantics from NiFi's? perspective? We have the ability to implicitly retry operations and also control the retry backoff values. Is there something more we could do from the HBase side, given what y'all have seen from the battlefield? Thanks! - Josh [1] https://github.com/apache/nifi/pull/3425
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
+1 (binding) - Verified signatures/hashes & LICENSES/NOTICES - Ran full build - Ran secure cluster with load balanced connections Looks good, thanks! On Tue, Feb 18, 2020 at 11:56 AM Pierre Villard wrote: > > +1, binding > > Verified signatures, built and deployed a secured cluster on GCP, ran some > flows to verify the load balanced connections. LGTM. > > Thanks Joe for taking care of this! > > Le mar. 18 févr. 2020 à 08:09, Chad Zobrisky a écrit : > > > Ran over the release document and checked everything off. Looks good, ran a > > few basic flows to test normal functionality. > > > > +1 non-binding > > > > Chad > > > > On Tue, Feb 18, 2020 at 11:02 AM Joe Witt wrote: > > > > > The release vote remains open for Rc1 as of now. > > > > > > On Tue, Feb 18, 2020 at 9:45 AM Marc Parisi wrote: > > > > > > > ran this over the weekend but forgot to respond. > > > > > > > > I saw the other chain, which reminded me to respond. Sorry about > > that... > > > > > > > > Ran my typical release build following the helper guide. Used my > > typical > > > > test flow. > > > > > > > > +1 if we can extend the vote, otherwise I'll jump on RC2. > > > > > > > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > > > > > > > > Hello, > > > > > > > > > > I am pleased to be calling this vote for the source release of Apache > > > > NiFi > > > > > 1.11.2. > > > > > > > > > > The source zip, including signatures, digests, etc. can be found at: > > > > > > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > > > > > > > The source being voted upon and the convenience binaries can be found > > > at: > > > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > > > > > > > A helpful reminder on how the release candidate verification process > > > > works: > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > > > > > > > The Git tag is nifi-1.11.2-RC1 > > > > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > > > Checksums of nifi-1.11.2-source-release.zip: > > > > > SHA256: > > > 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > > > > SHA512: > > > > > > > > > > > > > > > > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > > > > > > > Release artifacts are signed with the following key: > > > > > https://people.apache.org/keys/committer/joewitt.asc > > > > > > > > > > KEYS file available here: > > > > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > > > > > > > 14 issues were closed/resolved for this release: > > > > > > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > > > > > > > Release note highlights can be found here: > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > > > > > > > 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-1.11.2 > > > > > [ ] +0 no opinion > > > > > [ ] -1 Do not release this package because... > > > > > > > > > > > > > >
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
Verified signatures, built and deployed a complex flow running over the weekend with no issues. +1 non-binding Henry On 2020/02/15 03:15:18, Joe Witt wrote: > Hello,> > > I am pleased to be calling this vote for the source release of Apache NiFi> > 1.11.2.> > > The source zip, including signatures, digests, etc. can be found at:> > https://repository.apache.org/content/repositories/orgapachenifi-1157> > > The source being voted upon and the convenience binaries can be found at:> > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/> > > A helpful reminder on how the release candidate verification process works:> > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > The Git tag is nifi-1.11.2-RC1> > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52> > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > Checksums of nifi-1.11.2-source-release.zip:> > SHA256: 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610> > SHA512:> > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527> > > Release artifacts are signed with the following key:> > https://people.apache.org/keys/committer/joewitt.asc> > > KEYS file available here:> > https://dist.apache.org/repos/dist/release/nifi/KEYS> > > 14 issues were closed/resolved for this release:> > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > Release note highlights can be found here:> > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > 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-1.11.2> > [ ] +0 no opinion> > [ ] -1 Do not release this package because...> >
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
+1, binding Verified signatures, built and deployed a secured cluster on GCP, ran some flows to verify the load balanced connections. LGTM. Thanks Joe for taking care of this! Le mar. 18 févr. 2020 à 08:09, Chad Zobrisky a écrit : > Ran over the release document and checked everything off. Looks good, ran a > few basic flows to test normal functionality. > > +1 non-binding > > Chad > > On Tue, Feb 18, 2020 at 11:02 AM Joe Witt wrote: > > > The release vote remains open for Rc1 as of now. > > > > On Tue, Feb 18, 2020 at 9:45 AM Marc Parisi wrote: > > > > > ran this over the weekend but forgot to respond. > > > > > > I saw the other chain, which reminded me to respond. Sorry about > that... > > > > > > Ran my typical release build following the helper guide. Used my > typical > > > test flow. > > > > > > +1 if we can extend the vote, otherwise I'll jump on RC2. > > > > > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > > > > > > Hello, > > > > > > > > I am pleased to be calling this vote for the source release of Apache > > > NiFi > > > > 1.11.2. > > > > > > > > The source zip, including signatures, digests, etc. can be found at: > > > > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > > > > > The source being voted upon and the convenience binaries can be found > > at: > > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > > > > > A helpful reminder on how the release candidate verification process > > > works: > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > > > > > The Git tag is nifi-1.11.2-RC1 > > > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > > > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > Checksums of nifi-1.11.2-source-release.zip: > > > > SHA256: > > 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > > > SHA512: > > > > > > > > > > > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > > > > > Release artifacts are signed with the following key: > > > > https://people.apache.org/keys/committer/joewitt.asc > > > > > > > > KEYS file available here: > > > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > > > > > 14 issues were closed/resolved for this release: > > > > > > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > > > > > Release note highlights can be found here: > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > > > > > 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-1.11.2 > > > > [ ] +0 no opinion > > > > [ ] -1 Do not release this package because... > > > > > > > > > >
Re: Release candidate verification question
Ok, Thank you Joe and Bryan for the clarification and options. On Tue, Feb 18, 2020 at 11:27 AM Bryan Bende wrote: > If you want to compare the actual content of the source, you could do > something like: > > git clone https://git-wip-us.apache.org/repos/asf/nifi.git > git -C nifi checkout > diff --brief -r nifi-rc-source nifi > > On Tue, Feb 18, 2020 at 11:18 AM Joe Witt wrote: > > > > Chad, > > > > You basically want to ensure that a given release tag matches what we'd > > expect. In this case we're doing a 1.11.2 release so you'd want it to be > > 1.11.1 plus updates. > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=log;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > That link and the resulting history shows that it is based off a certain > > commit from master that resulted in 1.11.0 and then a support branch for > > 1.11.x which resulted in 1.11.1 plus some new commits which is now > 1.11.2. > > You can also verify that the content of the previous commit before the > > actual release tag is present in the release as well by comparing the > diff > > to the source itself. > > > > Thanks > > > > > > On Tue, Feb 18, 2020 at 11:13 AM Chad Zobrisky > wrote: > > > > > I was going through the guide over the weekend and hit the step about > > > verifying the RC was branched off the correct git commit. Is this done > just > > > via looking in git at the commit for the tag and that the release vote > > > email has the same commit hash in it , or is the commit hash put > somewhere > > > in the source/build to verify there? > > > > > > Hope that makes sense. > > > > > > Thanks, > > > Chad > > > >
Re: Release candidate verification question
If you want to compare the actual content of the source, you could do something like: git clone https://git-wip-us.apache.org/repos/asf/nifi.git git -C nifi checkout diff --brief -r nifi-rc-source nifi On Tue, Feb 18, 2020 at 11:18 AM Joe Witt wrote: > > Chad, > > You basically want to ensure that a given release tag matches what we'd > expect. In this case we're doing a 1.11.2 release so you'd want it to be > 1.11.1 plus updates. > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=log;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > That link and the resulting history shows that it is based off a certain > commit from master that resulted in 1.11.0 and then a support branch for > 1.11.x which resulted in 1.11.1 plus some new commits which is now 1.11.2. > You can also verify that the content of the previous commit before the > actual release tag is present in the release as well by comparing the diff > to the source itself. > > Thanks > > > On Tue, Feb 18, 2020 at 11:13 AM Chad Zobrisky wrote: > > > I was going through the guide over the weekend and hit the step about > > verifying the RC was branched off the correct git commit. Is this done just > > via looking in git at the commit for the tag and that the release vote > > email has the same commit hash in it , or is the commit hash put somewhere > > in the source/build to verify there? > > > > Hope that makes sense. > > > > Thanks, > > Chad > >
Re: Release candidate verification question
Chad, You basically want to ensure that a given release tag matches what we'd expect. In this case we're doing a 1.11.2 release so you'd want it to be 1.11.1 plus updates. https://gitbox.apache.org/repos/asf?p=nifi.git;a=log;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 That link and the resulting history shows that it is based off a certain commit from master that resulted in 1.11.0 and then a support branch for 1.11.x which resulted in 1.11.1 plus some new commits which is now 1.11.2. You can also verify that the content of the previous commit before the actual release tag is present in the release as well by comparing the diff to the source itself. Thanks On Tue, Feb 18, 2020 at 11:13 AM Chad Zobrisky wrote: > I was going through the guide over the weekend and hit the step about > verifying the RC was branched off the correct git commit. Is this done just > via looking in git at the commit for the tag and that the release vote > email has the same commit hash in it , or is the commit hash put somewhere > in the source/build to verify there? > > Hope that makes sense. > > Thanks, > Chad >
Release candidate verification question
I was going through the guide over the weekend and hit the step about verifying the RC was branched off the correct git commit. Is this done just via looking in git at the commit for the tag and that the release vote email has the same commit hash in it , or is the commit hash put somewhere in the source/build to verify there? Hope that makes sense. Thanks, Chad
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
Ran over the release document and checked everything off. Looks good, ran a few basic flows to test normal functionality. +1 non-binding Chad On Tue, Feb 18, 2020 at 11:02 AM Joe Witt wrote: > The release vote remains open for Rc1 as of now. > > On Tue, Feb 18, 2020 at 9:45 AM Marc Parisi wrote: > > > ran this over the weekend but forgot to respond. > > > > I saw the other chain, which reminded me to respond. Sorry about that... > > > > Ran my typical release build following the helper guide. Used my typical > > test flow. > > > > +1 if we can extend the vote, otherwise I'll jump on RC2. > > > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > > > > Hello, > > > > > > I am pleased to be calling this vote for the source release of Apache > > NiFi > > > 1.11.2. > > > > > > The source zip, including signatures, digests, etc. can be found at: > > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > > > The source being voted upon and the convenience binaries can be found > at: > > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > > > A helpful reminder on how the release candidate verification process > > works: > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > > > The Git tag is nifi-1.11.2-RC1 > > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > > Checksums of nifi-1.11.2-source-release.zip: > > > SHA256: > 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > > SHA512: > > > > > > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > > > Release artifacts are signed with the following key: > > > https://people.apache.org/keys/committer/joewitt.asc > > > > > > KEYS file available here: > > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > > > 14 issues were closed/resolved for this release: > > > > > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > > > Release note highlights can be found here: > > > > > > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > > > 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-1.11.2 > > > [ ] +0 no opinion > > > [ ] -1 Do not release this package because... > > > > > >
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
The release vote remains open for Rc1 as of now. On Tue, Feb 18, 2020 at 9:45 AM Marc Parisi wrote: > ran this over the weekend but forgot to respond. > > I saw the other chain, which reminded me to respond. Sorry about that... > > Ran my typical release build following the helper guide. Used my typical > test flow. > > +1 if we can extend the vote, otherwise I'll jump on RC2. > > On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > > > Hello, > > > > I am pleased to be calling this vote for the source release of Apache > NiFi > > 1.11.2. > > > > The source zip, including signatures, digests, etc. can be found at: > > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > > > The source being voted upon and the convenience binaries can be found at: > > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > > > A helpful reminder on how the release candidate verification process > works: > > > > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > > > The Git tag is nifi-1.11.2-RC1 > > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > > > Checksums of nifi-1.11.2-source-release.zip: > > SHA256: 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > > SHA512: > > > > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > > > Release artifacts are signed with the following key: > > https://people.apache.org/keys/committer/joewitt.asc > > > > KEYS file available here: > > https://dist.apache.org/repos/dist/release/nifi/KEYS > > > > 14 issues were closed/resolved for this release: > > > > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > > > Release note highlights can be found here: > > > > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > > > 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-1.11.2 > > [ ] +0 no opinion > > [ ] -1 Do not release this package because... > > >
Re: [VOTE] Release Apache NiFi 1.11.2 (rc1)
ran this over the weekend but forgot to respond. I saw the other chain, which reminded me to respond. Sorry about that... Ran my typical release build following the helper guide. Used my typical test flow. +1 if we can extend the vote, otherwise I'll jump on RC2. On Fri, Feb 14, 2020 at 10:15 PM Joe Witt wrote: > Hello, > > I am pleased to be calling this vote for the source release of Apache NiFi > 1.11.2. > > The source zip, including signatures, digests, etc. can be found at: > https://repository.apache.org/content/repositories/orgapachenifi-1157 > > The source being voted upon and the convenience binaries can be found at: > https://dist.apache.org/repos/dist/dev/nifi/nifi-1.11.2/ > > A helpful reminder on how the release candidate verification process works: > > https://cwiki.apache.org/confluence/display/NIFI/How+to+help+verify+an+Apache+NiFi+release+candidate > > The Git tag is nifi-1.11.2-RC1 > The Git commit ID is 6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > https://gitbox.apache.org/repos/asf?p=nifi.git;a=commit;h=6d2ec87c8a46d5d39f3b4683e4ea9dec91138d52 > > Checksums of nifi-1.11.2-source-release.zip: > SHA256: 2a030956a7cc9578e616195dd4cf8a853976e17eb040a7b216f844ae2ce9a610 > SHA512: > > 135101f3f9b37b559e850e79c89bad36d707126fcea559fa4f6846c4cb21c17ab51c119c5005df359a4d3a066c66611b00816c2f7586b24d34f0f418d4b5c527 > > Release artifacts are signed with the following key: > https://people.apache.org/keys/committer/joewitt.asc > > KEYS file available here: > https://dist.apache.org/repos/dist/release/nifi/KEYS > > 14 issues were closed/resolved for this release: > > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020=12346972 > > Release note highlights can be found here: > > https://cwiki.apache.org/confluence/display/NIFI/Release+Notes#ReleaseNotes-Version1.11.2 > > 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-1.11.2 > [ ] +0 no opinion > [ ] -1 Do not release this package because... >
Re: NIFI Flow Design System
Glenn, Thanks for your comments. The canvas you've experienced unfortunately has not landed in the Flow Design System yet. It is ultimately destined for there but currently, only the NiFi Registry uses FDS. In time, NiFi will be updated to also use it. At that time, the NiFi canvas should be a component that FDS offers. When completed that worked would likely land in the next major version of NiFi. Currently, the canvas in NiFi is implemented directly in the NiFi codebase and is not designed to be a reusable component. Hope this helps clarify things. On Sat, Feb 15, 2020 at 7:19 AM Glenn Barnard wrote: > Hi, I recently had the pleasure of using NIFI at DXC Technology and was > wondering if the FDS component was available to use in my own applications. > I wrote a BPM Workflow engine, but the XML is becoming unmanageable. So, > I'm looking for a tool I can insert into my web apps to help me in this > development. > > My primary app is Job Manager, which can already perform a series of tasks, > but Iit needs better flow control that is easy to create, store and test. > > Please advise if the Flow Design System would be a good fit for my purposes > and what I'd have to do to download it. > > Thank you so much! >
Merging NIFI-7007: Add update functionality to PutCassandraRecord processor
Hi all, I've spent some time extending the PutCassandraRecord processor so that it can also generate UPDATE statements. This is especially useful in the context of Counter types, which can only be updated using these statements. I've had a quite a bit of back-and-forth with reviewers and hope that, perhaps with some additional review, we can get this PR merged. Jira ticket: https://issues.apache.org/jira/browse/NIFI-7007 Github PR: https://github.com/apache/nifi/pull/3977 Instructions to "setup" cassandra using docker and a Nifi template: https://wbdv.nl/assets/nifi/ I'm looking forward to receiving your feedback. Best regards, Wouter
