Bryan, I can not oversee the difficulty of implementing that.
I could have a try myself but I'm afraid I can not correctly estimate the
implications of such a change on other processors. It may fix this and
break other stuff?
Perhaps it can also be fixed in processors of just this type. Maybe by
us
Here is the existing JIRA:
https://issues.apache.org/jira/browse/NIFI-2592
If we implemented that then the OnScheduled of ListenUDP would never
get called on the non-primary nodes, which would then never start the
listener.
On Wed, Jun 5, 2019 at 12:33 PM Joe Witt wrote:
>
> ...this feels like
...this feels like a bug to me. I think Erik-Jan's expectation that
nothing would have begun for ListenUDP given primary node only config is
fair. I also think our current position of 'just not calling onTrigger' is
fair too but less intuitive for users.
What do ya'll think?
On Wed, Jun 5, 2019
This is what I do basically. I want a highly available setup with a minimum
of components since each component can (and will) fail. Traffic reaches all
nodes but only a single node should read it.
Op wo 5 jun. 2019 18:07 schreef James Srinivasan :
> In our case the stream is UDP broadcast, so av
In our case the stream is UDP broadcast, so available to all nodes anyway.
I've been meaning to test UDP multicast but not got round to it yet.
On Wed, 5 Jun 2019, 17:03 Bryan Bende, wrote:
> That is probably a valid point, but how about putting a load balancer
> in front to handle that?
>
> On
That is probably a valid point, but how about putting a load balancer
in front to handle that?
On Wed, Jun 5, 2019 at 11:30 AM James Srinivasan
wrote:
>
> Presumably you'd want to mirror the stream to all nodes for when the primary
> node changes?
>
> On Wed, 5 Jun 2019, 13:46 Bryan Bende, wrot
Presumably you'd want to mirror the stream to all nodes for when the
primary node changes?
On Wed, 5 Jun 2019, 13:46 Bryan Bende, wrote:
> The processor is started on all nodes, but onTrigger method is only
> executed on the primary node.
>
> This is something we've discussed trying to improve b
The processor is started on all nodes, but onTrigger method is only
executed on the primary node.
This is something we've discussed trying to improve before, but the
real question is why are you sending data to the other nodes if you
don't expect the processor to execute there?
On Wed, Jun 5, 201
I figured it out after further testing. The processor runs on all nodes,
despite the explicit "run on primary node only" option that I selected. But
only on the primary node the queue is processed. On the other nodes the
queue gets filled until the max is reached after which the error message
start
Hi Bryan,
Yes I have considerably increased the numbers in the controller settings.
I don't mind getting my hands dirty, increasing the timeout is worth a try.
The errors seems to appear after quite a while. Usually I see these
messages the next morning so testing and experimenting with this erro
Hi Erik,
It sounds like you have tried most of the common tuning options that
can be done. I would have expected batching + increasing concurrent
tasks from 1 to 3-5 to be the biggest improvement.
Have you increased the number of threads in your overall thread pool
according to your hardware? (fr
Hi,
I'm experimenting with a locally installed 3 node nifi cluster. This
cluster receives UDP packets on the primary node.
These nodes are pretty powerful, have a good network connection, have lots
of memory and SSD disks. I gave nifi 24G of java heap (xms and xmx).
I have configured a ListenUDP
12 matches
Mail list logo
