We have been using Nifi for over a year and we just turned up a new cluster.
We move around 6TB a day of small to large files. We are having an issue
of the ListSFTP missing files. I know this can happen if a file with an
older date is moved into the directory because the lister is
Joe,
The only new thing we can do is Matt can finish reviewing the PR for NIFI-5744,
which adds this as a feature to ExecuteSQL, as he was waiting for this
discussion to come to a close.
https://github.com/apache/nifi/pull/3107#issuecomment-433260483
But apart from that, nothing new to do now.
Peter
Ok cool. So i think we agree on the state of things. And for
processors you want to add more details in failure cases to you can do
so (provided we're not just bloating attributes all over). And we'll
recognize that this model is basically to help users and will likely
be abused and be
Joe,
Several different opinions have been expressed by Matt Burgess, Mark Payne and
Bryan Bende about whether we should be storing exception information in
attributes, and the pros and cons, in this thread. Those opinions generally
matched yours, which is that a well-defined relationship is
Peter,
I'm not clear on what you're are asking be done precisely and how far
it be carried.
You're right there are many processors which store exception/log
details as attributes on flowfiles before they route them
(success,failure, etc..). This is fine and can be documented with the
A one week bump on this thread. --Peter
-Original Message-
From: Peter Wicks (pwicks)
Sent: Friday, November 2, 2018 11:54 AM
To: dev@nifi.apache.org
Subject: RE: [EXT] Re: New Standard Pattern - Put Exception that caused failure
in an attribute
Dev Team,
I don’t think we've reached a
Hi Lars,
I think as long as the following are true (it sounds like they are from what
you have looked at):
1. the proposed endpoint does not require adding any additional Authorizable or
policy to protect, and
2. the proposed endpoint does not expose any information that the authenticated
I've just tried implementing my new resource and it seems to work fine and
as I expect it to. Also in regards to authorization. Users cannot see
anything that they are not allowed to do anyway.
Regarding your other comments: I agree that it's probably not a super
common use case.
Either way I'd
Andy,
that's a good question. I have to admit that I thought about it and then
saw that there is already an Authorizable for this scenario so I assumed
that part was already taken care of. So whoever has the permission to view
"access all policies" would also be able to use the API? Were you
