Clay
Have you evaluated whether InvokeHTTP will give you the desired behavior
for your case - in particular with a long timeout perhaps? If you have and
it doesn't do the job do you mean something which initiates a request to an
HTTP server then assumes the response will remain open and it
Is there a reason each ListenHTTP has a unique SSLContextService if they're
all using the same certificates?
If it were me, I'd use a single shared SSLContextService, and when I needed
to update the certificate in the keystore/truststore, I would change it on
disk by renaming the old file and
Right makes sense. They're waiting for the completion of the response as
the payload to pass on. If we need incremental handling of the response
body then we need to factor that into a given processor. InvokeHttp or
something like it is a good candidate. Almost a sort of 'InvokeHttpRecord'
Thanks Joe for the pointers.
On Wed, Oct 14, 2020 at 3:31 PM Joe Witt wrote:
> Right makes sense. They're waiting for the completion of the response as
> the payload to pass on. If we need incremental handling of the response
> body then we need to factor that into a given processor.
Hello,
I tried both getHTTP and invokeHTTP (but didn't try all options). What I
need is to deal with the cases, such as SSE (Server Sent Events) which
works with long polling. Meaning the client initiates a connection (via a
HTTP request) to the SSE server, the server keeps the connection open
Micron Confidential
I agree Nathan. I believe the situation I ran into came about due to bad
planning. Users started independently hosting services, and it was only later
that we realized that a centralized service or variables would be a better
solution.
It would probably be easier to just
Yes, this is for a secured cluster deployed as a Kubernetes stateful set. The
certificate parameters are apparently not needed to just get the status of the
nodes using the command below.
From: Sushil Kumar
Sent: Tuesday, October 13, 2020 4:01 PM
To:
That makes sense. It must be reading the keystore/truststore specified in the
nifi.properties file then?
From: Bryan Bende
Sent: Wednesday, October 14, 2020 9:59 AM
To: users@nifi.apache.org
Subject: Re: Clustered nifi issues
The get-nodes command calls the
The get-nodes command calls the REST resource /controller/cluster which
authorizes against READ on /controller [1], so there is no way you can call
this in a secure environment without authenticating somehow, which from the
CLI means specifying a keystore/truststore.
[1]
The CLI does not use nifi.properties, there are several ways of passing in
config...
https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#property-argument-handling
On Wed, Oct 14, 2020 at 10:01 AM Wyll Ingersoll <
wyllys.ingers...@keepertech.com> wrote:
> That makes sense. It must
Copy flow.xml.gz from both and either write a script or find a tool
that can look for the processor references. That file is essentially
the master state of what you see on the canvas.
On Tue, Oct 13, 2020 at 5:44 PM Alberto Dominguez
wrote:
>
> Hello,
>
> I have two environments and one NiFi
I see what's happening. The container sets up a /root/.nifi-cli.config file
that has the required security parameters so that the user doesn't have to
supply them on the command line.
From: Bryan Bende
Sent: Wednesday, October 14, 2020 10:45 AM
To:
Hi All,
I am facing one issue during the nifi cluster upgrade to 1.12 version from
1.8 version.
I have a *custom processor for AWSCredentialsProviderControllerService
controller service. this has been build on top of 1.8* version . the
structure for custom processor in flow.xml.gz file is:
i have a nifi server with several listenhttp modules on different
ports. each one has an sslcontext within it that uses the same certs
as the main 443 instance.
sadly i changed the cert when expired on the 443 port, but failed to
change the sslcontext on the ports. is there a way to tell the
I think the issue is that the way the logic works, it takes the class
name from flow.xml and then looks to see which bundles contain that
class name.
In your case, there are two bundles containing
org.apache.nifi.processors.aws.credentials.provider.service.AWSCredentialsProviderControllerService
Michael,
There is not any specific way supported or intended to combine the context
used by NiFi's own HTTP server with those that would be used by processors
within the flow.
However, using parameter contexts here is a great way to ensure you have
only a single place to update for flow
ah, okay that sounds like maybe a step in a good direction, but
doesn't necessarily solve my problem. What I'm trying to alleviate is
the need to go into nifi to change the certs when they expire.
i'll have to look up parameter contexts, that should at least make it
so there's only one place to
Micron Confidential
I've found this annoying in the past as well. I would not be opposed to an
additional implementation of the SSLContext that uses the NiFi certs by
default, though... if it uses the client certificate as well you'd have to make
it restricted, so as to prevent users from
18 matches
Mail list logo
