+1 (non-binding)
- Verified signatures and hashes of [
https://dist.apache.org/repos/dist/dev/nifi/nifi-2.0.0-M3/] binaries
- Build of source successful (macOS 14 / Zulu21.28+85-CA (build 21+35))
- Configuration of three node dev cluster (Manual Keystore Generation)
- Application startup successfu
>
> Kafka 2.6 parity concern - Can you share more on what is missing?
> Obviously supporting Kafka users within NiFi is quite important but I think
> we're making the right steps here. Whatever gap we have now let's identify
> and see who can knock it out.
I cited a few in the PR description [1]
Is this by chance a virtual machine you are on?
https://www.exoscale.com/syslog/random-numbers-generation-in-virtual-machines/
TL;DR: try installing haveged
On Mon, Jul 29, 2024 at 9:29 AM Dan S wrote:
> So I see the problem line is
> at
>
> org.apache.nifi.processors.elasticsearch.PutElastic
se, a refactor of the test would probably be a better
alternative. Your observation on behavior in your environment with haveged
will help inform that decision.
On Mon, Jul 29, 2024 at 10:14 AM Dan S wrote:
> Yes I have a VM on an EC2 instance in AWS.
>
> On Mon, Jul 29, 2024 at 10:1
at make them prone to
> > entropy starvation will hinder, if not defeat, HAVEGE (or the quality —
> > randomness — of the entropy it will gather).
>
>
> On Mon, Jul 29, 2024 at 10:43 AM Paul Grey wrote:
>
> > In the past, I've observed application testing inf
e a reasonable candidate to investigate.
On Mon, Jul 29, 2024 at 12:59 PM Paul Grey wrote:
> Sure. I'm suggesting that to diagnose your situation. Depletion of
> entropy may not be the problem. Here's another way to evaluate that:
>
> https://major.io/p/check-a
e randomness does not seem especially important in this
context (a unit test). Whereas, when it comes to generating cryptography
keys, it is _very_ important.
:)
On Mon, Jul 29, 2024 at 1:12 PM Paul Grey wrote:
> > If it returns anything less than 100-200, you have a problem. Try
> ins
27;t
> have to install haveged. It is interesting to note in the setup method of
> org.apache.nifi.minifi.commons.service.StandardFlowPropertyEncryptorTest,
> the method org.apache.commons.lang3.RandomStringUtils.randomAlphabetic is
> used and that does not seem to cause an issue.
>
> On Mon, Jul 29, 2024 at 1:17
arsers handle large input,
> but there’s no real need for it to be randomised, so any method of
> generating a long string would suffice.
>
>
> Cheers,
>
> ---
> Chris Sampson
> IT Consultant
> chris.samp...@naimuri.com
>
>
> > On 29 Jul 2024, at 19:21, Pa
Jira username: pgrey
+1 (non-binding)
- Verified signatures and hashes of [
https://dist.apache.org/repos/dist/dev/nifi/nifi-1.16.2/] binaries
- Build of source successful (macOS 12 / Azul Java 1.8.0_322)
- Application startup successful (set-single-user-credentials, five node
dev cluster)
- Verified successful flow o
+1 (non-binding)
- Verified signatures and hashes of [
https://dist.apache.org/repos/dist/dev/nifi/nifi-1.17.0/] binaries
- Build of source successful (macOS 12 / Azul Java 1.8.0_322)
- Application startup successful (set-single-user-credentials, three node
dev cluster)
- Verified successful flow
Looks like the PR build ran successfully; I see that the unit tests ran in
the build output.
https://github.com/apache/nifi/actions/runs/3386010384
You may be looking for automation runs here?
https://github.com/shawnweeks/nifi/actions
This is something that is disabled by default, but you can en
+1 (non-binding)
- Verified signatures and hashes of [
https://dist.apache.org/repos/dist/dev/nifi/nifi-1.21.0/] binaries
- Build of source successful (macOS 12 / Azul Java 1.8.0_322)
- Application startup successful
- Verified successful flow of data using known good flows (Kafka, PutSlack)
- ve
This issue sounds similar to this one:
- https://issues.apache.org/jira/browse/NIFI-10143
Are you able to share OS/JRE details for the FTP server and for the NiFi
instance?
On Wed, Aug 16, 2023 at 12:37 PM Ravinder Singh <
ravinder.si...@energisme.com> wrote:
> Hello,
>
>
>
> First of all, I wo
I spent a bit of time working on a draft of the needed openssl commands to
generate equivalent keystores / truststores. Was not able to finish this
draft before I got side tracked.
https://github.com/greyp9/nifi-tidbits/blob/main/cluster/tls-toolkit-via-openssl/cluster-certs.md
If you're still o
Matthew,
Thanks much for identifying this issue with the documentation. I see the
same error message when running step 8. I've created a JIRA and a pull
request to correct the documentation.
https://issues.apache.org/jira/browse/NIFI-12814
https://github.com/apache/nifi/pull/8424
On Fri, Feb 1
+1 (non-binding)
- verified signatures and hashes of [
https://dist.apache.org/repos/dist/dev/nifi/nifi-2.0.0/] binaries
- build of source successful (macOS 14 / Zulu21.28+85-CA (build 21+35))
- application startup successful (set-single-user-credentials)
- verify GitHubFlowRegistryClient function
+1 (non-binding)
- verified signatures and hashes of [
https://dist.apache.org/repos/dist/dev/nifi/nifi-2.0.0/] binaries
- build of source successful (macOS 14 / Zulu21.28+85-CA (build 21+35))
- application startup successful (set-single-user-credentials)
- verify GitHubFlowRegistryClient function
+1 non-binding
On Wed, Nov 13, 2024 at 3:41 PM David Handermann <
exceptionfact...@apache.org> wrote:
> Team,
>
> Following a discussion of future support for the NiFi version 1 series
> [1], I am calling for a vote on the following proposal:
>
> 1. Declare NiFi version 1 as End of Support on Dec
Apologies to all. After doing a review of the PR for this JIRA, I
attempted to commit it using the Github UI. I'm familiar with the "Squash"
workflow from working with other Github repositories, but this repo is set
up differently, so it went in as a merge commit.
In the past, I've squashed NiFi
21 matches
Mail list logo
