Re: How to get a processGroup in a ReportingTask
Pierre, I have 3 levels of process group and although the group path contains the name chain, the name of the PG level 1 may change and I need to show the updated name, that's why I wanted to save the PG id of level 1. I built a ReportingTask that persists Bulleting in a database table because my requirement is to keep it for at least 7 days. I appreciate any recommendation On Wed, Oct 27, 2021 at 4:16 AM Pierre Villard wrote: > Hi, > > What information do you need on the parent? What's the intent? > The bulletin provides the group path with the chain of all the process > groups leading to the component where the bulletin is generated. > > Thanks, > Pierre > > Le mer. 27 oct. 2021 à 03:49, Jairo Henao a > écrit : > > > Hello community, > > > > Is it possible to obtain a ProcessGroup without using the REST-API > within a > > ReportingTask? > > > > I need to get the parent of a "bulletin.getGroupId()", but I see that it > > could only be done if I have the 'flowController' or the 'flowManager' > but > > they are not available. > > > > Thoughts? > > > > -- > > Jairo Henao > > @jairohenaorojas > > > -- Jairo Henao @jairohenaorojas
Re: PR's needing some attention
Probably best to put these responses directly on the PRs or JIRAs so the context doesn't get lost (apologies if that was done - didn't check). On Wed, Oct 27, 2021 at 8:13 AM Mark Payne wrote: > > Mark, > > I’ll take a look at the first one - NIFI-8962. Seems like a reasonable > improvement. > > While NIFI-8917 should definitely be reviewed and helpful, I will note that > it only affects builds. I.e., whether it makes it into 1.15.0 or not isn’t > really relevant. Whenver it makes its way to the “main” branch it’ll be > available. So I’d say it’s perhaps not as high a priority to review for me > personally from the respect. > > For NIFI-9072: Not sure that I agree this should be supported. Attributes are > intended to always be very small - like a couple hundred characters or less. > It is very much an anti-pattern to put things like XML and JSON in > attributes, and it’s really something that we should not encourage. Creating > large attributes can have a hugely detrimental effect on nifi performance > (due to having to write lots of attributes to both the flowfile repository > and provenance repository, plus using up available heap, and it drastically > slows down startup times) as well as node stability and cluster stability > (due to garbage collection, out of memory errors, heap exhaustion, etc.) > > Thanks > -Mark > > > > On Oct 27, 2021, at 10:00 AM, Mark Bean wrote: > > > > I am requesting assistance with three PR's, two of which have had comments > > and do not have any outstanding issues currently. Unless new issues arise, > > they are ready to be accepted. > > > > NIFI-8962: Adds an 'overflow' strategy to the DistributeLoad processor > > allowing an additional distribution capability effectively prioritizing > > relationships. > > https://issues.apache.org/jira/browse/NIFI-8962 > > https://github.com/apache/nifi/pull/5267 > > > > NIFI-8917: Adds profiles to the project-level pom.xml so that non-required > > modules such as nifi-registry, nifi-toolkit and minifi can be excluded from > > a build. This is beneficial for test/development build cycles to reduce > > overall build time. > > https://issues.apache.org/jira/browse/NIFI-8917 > > https://github.com/apache/nifi/pull/5307 > > > > There is a third PR which has not been reviewed yet. > > NIFI-9072: Improves ValidateXML by allowing the XML to be in the flowfile > > content or in a flowfile attribute. Also, the XSD schema is now optional. > > If the schema is not provided, basic validation is performed simply to > > ensure the XML is well-formed. > > https://issues.apache.org/jira/browse/NIFI-9072 > > https://github.com/apache/nifi/pull/5324 > > > > Thanks! >
Re: PR's needing some attention
Mark, I’ll take a look at the first one - NIFI-8962. Seems like a reasonable improvement. While NIFI-8917 should definitely be reviewed and helpful, I will note that it only affects builds. I.e., whether it makes it into 1.15.0 or not isn’t really relevant. Whenver it makes its way to the “main” branch it’ll be available. So I’d say it’s perhaps not as high a priority to review for me personally from the respect. For NIFI-9072: Not sure that I agree this should be supported. Attributes are intended to always be very small - like a couple hundred characters or less. It is very much an anti-pattern to put things like XML and JSON in attributes, and it’s really something that we should not encourage. Creating large attributes can have a hugely detrimental effect on nifi performance (due to having to write lots of attributes to both the flowfile repository and provenance repository, plus using up available heap, and it drastically slows down startup times) as well as node stability and cluster stability (due to garbage collection, out of memory errors, heap exhaustion, etc.) Thanks -Mark > On Oct 27, 2021, at 10:00 AM, Mark Bean wrote: > > I am requesting assistance with three PR's, two of which have had comments > and do not have any outstanding issues currently. Unless new issues arise, > they are ready to be accepted. > > NIFI-8962: Adds an 'overflow' strategy to the DistributeLoad processor > allowing an additional distribution capability effectively prioritizing > relationships. > https://issues.apache.org/jira/browse/NIFI-8962 > https://github.com/apache/nifi/pull/5267 > > NIFI-8917: Adds profiles to the project-level pom.xml so that non-required > modules such as nifi-registry, nifi-toolkit and minifi can be excluded from > a build. This is beneficial for test/development build cycles to reduce > overall build time. > https://issues.apache.org/jira/browse/NIFI-8917 > https://github.com/apache/nifi/pull/5307 > > There is a third PR which has not been reviewed yet. > NIFI-9072: Improves ValidateXML by allowing the XML to be in the flowfile > content or in a flowfile attribute. Also, the XSD schema is now optional. > If the schema is not provided, basic validation is performed simply to > ensure the XML is well-formed. > https://issues.apache.org/jira/browse/NIFI-9072 > https://github.com/apache/nifi/pull/5324 > > Thanks!
PR's needing some attention
I am requesting assistance with three PR's, two of which have had comments and do not have any outstanding issues currently. Unless new issues arise, they are ready to be accepted. NIFI-8962: Adds an 'overflow' strategy to the DistributeLoad processor allowing an additional distribution capability effectively prioritizing relationships. https://issues.apache.org/jira/browse/NIFI-8962 https://github.com/apache/nifi/pull/5267 NIFI-8917: Adds profiles to the project-level pom.xml so that non-required modules such as nifi-registry, nifi-toolkit and minifi can be excluded from a build. This is beneficial for test/development build cycles to reduce overall build time. https://issues.apache.org/jira/browse/NIFI-8917 https://github.com/apache/nifi/pull/5307 There is a third PR which has not been reviewed yet. NIFI-9072: Improves ValidateXML by allowing the XML to be in the flowfile content or in a flowfile attribute. Also, the XSD schema is now optional. If the schema is not provided, basic validation is performed simply to ensure the XML is well-formed. https://issues.apache.org/jira/browse/NIFI-9072 https://github.com/apache/nifi/pull/5324 Thanks!
Re: How to get a processGroup in a ReportingTask
Hi, What information do you need on the parent? What's the intent? The bulletin provides the group path with the chain of all the process groups leading to the component where the bulletin is generated. Thanks, Pierre Le mer. 27 oct. 2021 à 03:49, Jairo Henao a écrit : > Hello community, > > Is it possible to obtain a ProcessGroup without using the REST-API within a > ReportingTask? > > I need to get the parent of a "bulletin.getGroupId()", but I see that it > could only be done if I have the 'flowController' or the 'flowManager' but > they are not available. > > Thoughts? > > -- > Jairo Henao > @jairohenaorojas >
