It is also possible that Extract grok should be @depricated and noted as
such in it’s documentation, with the GrokReader being refactored to have
all the same
levers to tune.
But I would suggest that that would or should be done after the upgrade to
0.1.9 ( latest ), and after the follow on and
I would add a test for putting in the defaults as a file when they are
added by the processor as well.
=or=
I could expose a new property to turn it on. But really, by rule of least
surprise, I would expect the core groks to always
exist and to be able to overwrite if necessary. We do that in
I think so, the way that java-grok works ( refactored for 0.1.9 ) is that
you register
sets of patterns with the compiler, and the compiler produces the Grok
object.
When registering things with the same name, the last one in wins, so I
think if an existing
user had put a pattern file in the
You're probably not missing anything. ExtractGrok came before the
record reader/writer enlightenment phase.
If you think ExtractGrok is useful and want to improve it as you
suggest I think you're good to go provided you do so in a way that
doesn't break existing flows (change their behavior
I’m working on upgrading java-grok to the new 0.1.9 release. While going
through the GrokReader the the ExtractGrok components I noticed that they
differ in a very important way grok wise.
The reader loads the default patterns ( which are a copy of the ubiquitous
default patterns in java-grok
We have a 6-node cluster using external ZooKeeper. It is heavily loaded,
and we are attempting to tune some of the properties to alleviate some
observed issues. By "heavily loaded" I mean the graph is large (approx.
3,000 processors) and there is a lot of data in process (approx. 2M
Brajendra,
The NiFi API is typically called from external clients, not from within a
flow. With that said, as far as I understand your use case I don't think
it's going to work out that well for you. What you seem to want to do here
is programatically create new processors to handle new
Jonathan,
I think the issue is with how you apply the overrides in the properties
file. I've removed the trailing comments from the overriden lines and it
seems to be working.
Peter
On Fri, Apr 20, 2018 at 11:01 AM, Peter Wilcsinszky <
peterwilcsins...@gmail.com> wrote:
> Hi,
>
> I've tested
https://github.com/apache/nifi/pull/2687
-Original Message-
From: Joe Witt [mailto:joe.w...@gmail.com]
Sent: Friday, May 04, 2018 21:19
To: dev@nifi.apache.org
Subject: [EXT] Re: ReplaceText Flow File Processing Count
Bryan's guess on the history is probably right but more to the point
