[GitHub] [nifi] ravinarayansingh commented on pull request #7604: NIFI-11946 Added preserveSourceProperties query parameter to create flow API
ravinarayansingh commented on PR #7604: URL: https://github.com/apache/nifi/pull/7604#issuecomment-1690738085 > Thanks @ravinarayansingh, making adjustments to only retain the created timestamp, but always update the modified timestamp, seems like the best way forward. I also noted a couple minor spacing adjustments, and a recommendation for how to handle checking for and passing down the existing created timestamp. hi @exceptionfactory I have made the changes please have a look thanks -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] markobean commented on pull request #7639: NIFI-11934 allow FlowFile filename to be transmitted in HTTP header f…
markobean commented on PR #7639: URL: https://github.com/apache/nifi/pull/7639#issuecomment-1690696282 Thanks @exceptionfactory. I pushed changes per recommendations. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] markobean commented on a diff in pull request #7639: NIFI-11934 allow FlowFile filename to be transmitted in HTTP header f…
markobean commented on code in PR #7639:
URL: https://github.com/apache/nifi/pull/7639#discussion_r1303579528
##
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java:
##
@@ -130,7 +130,8 @@
@Tags({"http", "https", "rest", "client"})
@InputRequirement(Requirement.INPUT_ALLOWED)
@CapabilityDescription("An HTTP client processor which can interact with a
configurable HTTP Endpoint. The destination URL and HTTP Method are
configurable."
-+ " FlowFile attributes are converted to HTTP headers and the FlowFile
contents are included as the body of the request (if the HTTP Method is PUT,
POST or PATCH).")
++ " When the HTTP Method is PUT, POST or PATCH, the FlowFile contents
are included as the body of the request and FlowFile attributes are converted"
++ " to HTTP headers (optionally, if configured to be sent via the
'Attributes to Send' property)")
Review Comment:
Oops, I missed that I used `.name` and not `.displayName`. Good catch. Also,
I prefer to keep the work "optionally", but made the reference to generic
"configuration properties" as suggested.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on a diff in pull request #7639: NIFI-11934 allow FlowFile filename to be transmitted in HTTP header f…
exceptionfactory commented on code in PR #7639:
URL: https://github.com/apache/nifi/pull/7639#discussion_r1303567399
##
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java:
##
@@ -391,10 +391,11 @@ public class InvokeHTTP extends AbstractProcessor {
public static final PropertyDescriptor REQUEST_HEADER_ATTRIBUTES_PATTERN =
new PropertyDescriptor.Builder()
.name("Attributes to Send")
.displayName("Request Header Attributes Pattern")
-.description("Regular expression that defines which attributes to
send as HTTP headers in the request. "
-+ "If not defined, no attributes are sent as headers.
Dynamic properties will be sent as headers. "
-+ "The dynamic property name will be the header key and
the dynamic property value will be interpreted as expression "
-+ "language will be the header value.")
+.description("Regular expression that defines which FlowFile
attribute(s) to send as HTTP headers in the request. "
Review Comment:
```suggestion
.description("Regular expression that defines which FlowFile
attributes to send as HTTP headers in the request. "
```
##
nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/InvokeHTTP.java:
##
@@ -130,7 +130,8 @@
@Tags({"http", "https", "rest", "client"})
@InputRequirement(Requirement.INPUT_ALLOWED)
@CapabilityDescription("An HTTP client processor which can interact with a
configurable HTTP Endpoint. The destination URL and HTTP Method are
configurable."
-+ " FlowFile attributes are converted to HTTP headers and the FlowFile
contents are included as the body of the request (if the HTTP Method is PUT,
POST or PATCH).")
++ " When the HTTP Method is PUT, POST or PATCH, the FlowFile contents
are included as the body of the request and FlowFile attributes are converted"
++ " to HTTP headers (optionally, if configured to be sent via the
'Attributes to Send' property)")
Review Comment:
It is worth noting that `Attributes to Send` is now different than the
display name `Request Header Attributes Pattern`. Perhaps just generalizing
this statement is the best approach.
```suggestion
+ " to HTTP headers based on configuration properties.")
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on pull request #7528: NIFI-11857 - CLI - recursively change version of processors
exceptionfactory commented on PR #7528: URL: https://github.com/apache/nifi/pull/7528#issuecomment-1690673788 Thanks for the reply @pvillard31, that's a very good point about Controller Services. It sounds like it is necessary to handle them separately, and thus calling them out in a separate command makes more sense. With that background, this approach looks good as it stands, and I can take a closer look soon. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-11912) Add to StandardOauth2AccessTokenProvider controller service the possibility to choose a Proxy Configuration Service
[ https://issues.apache.org/jira/browse/NIFI-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11912: Priority: Minor (was: Major) > Add to StandardOauth2AccessTokenProvider controller service the possibility > to choose a Proxy Configuration Service > > > Key: NIFI-11912 > URL: https://issues.apache.org/jira/browse/NIFI-11912 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Reporter: Andrea Molteni >Assignee: Nandor Soma Abonyi >Priority: Minor > Fix For: 1.latest, 2.latest > > Time Spent: 50m > Remaining Estimate: 0h > > Actually the StandardOauth2AccessTokenProvider is not able to use a Proxy > configuration service controller. > As a result connectivity when requesting a Token does not work and the > StandardOauth2AccessTokenProvider returns a timeout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11912) Add to StandardOauth2AccessTokenProvider controller service the possibility to choose a Proxy Configuration Service
[ https://issues.apache.org/jira/browse/NIFI-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11912: Affects Version/s: (was: 1.23.0) > Add to StandardOauth2AccessTokenProvider controller service the possibility > to choose a Proxy Configuration Service > > > Key: NIFI-11912 > URL: https://issues.apache.org/jira/browse/NIFI-11912 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Reporter: Andrea Molteni >Assignee: Nandor Soma Abonyi >Priority: Major > Fix For: 1.latest, 2.latest > > Time Spent: 50m > Remaining Estimate: 0h > > Actually the StandardOauth2AccessTokenProvider is not able to use a Proxy > configuration service controller. > As a result connectivity when requesting a Token does not work and the > StandardOauth2AccessTokenProvider returns a timeout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11912) Add to StandardOauth2AccessTokenProvider controller service the possibility to choose a Proxy Configuration Service
[ https://issues.apache.org/jira/browse/NIFI-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11912: Fix Version/s: 2.0.0 1.24.0 (was: 1.latest) (was: 2.latest) Resolution: Fixed Status: Resolved (was: Patch Available) > Add to StandardOauth2AccessTokenProvider controller service the possibility > to choose a Proxy Configuration Service > > > Key: NIFI-11912 > URL: https://issues.apache.org/jira/browse/NIFI-11912 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Andrea Molteni >Assignee: Nandor Soma Abonyi >Priority: Minor > Fix For: 2.0.0, 1.24.0 > > Time Spent: 50m > Remaining Estimate: 0h > > Actually the StandardOauth2AccessTokenProvider is not able to use a Proxy > configuration service controller. > As a result connectivity when requesting a Token does not work and the > StandardOauth2AccessTokenProvider returns a timeout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11912) Add to StandardOauth2AccessTokenProvider controller service the possibility to choose a Proxy Configuration Service
[ https://issues.apache.org/jira/browse/NIFI-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11912: Issue Type: Improvement (was: New Feature) > Add to StandardOauth2AccessTokenProvider controller service the possibility > to choose a Proxy Configuration Service > > > Key: NIFI-11912 > URL: https://issues.apache.org/jira/browse/NIFI-11912 > Project: Apache NiFi > Issue Type: Improvement > Components: Core Framework >Reporter: Andrea Molteni >Assignee: Nandor Soma Abonyi >Priority: Minor > Fix For: 1.latest, 2.latest > > Time Spent: 50m > Remaining Estimate: 0h > > Actually the StandardOauth2AccessTokenProvider is not able to use a Proxy > configuration service controller. > As a result connectivity when requesting a Token does not work and the > StandardOauth2AccessTokenProvider returns a timeout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11912) Add to StandardOauth2AccessTokenProvider controller service the possibility to choose a Proxy Configuration Service
[ https://issues.apache.org/jira/browse/NIFI-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758244#comment-17758244 ] ASF subversion and git services commented on NIFI-11912: Commit 85ec0d91637ffa7ae7aba744a529a0bb1f866997 in nifi's branch refs/heads/support/nifi-1.x from Nandor Soma Abonyi [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=85ec0d9163 ] NIFI-11912 Added Proxy support to StandardOauth2AccessTokenProvider This closes #7609 Signed-off-by: David Handermann (cherry picked from commit e9b62f7b835569e2ee29e00aa897a3fb2ccf2688) > Add to StandardOauth2AccessTokenProvider controller service the possibility > to choose a Proxy Configuration Service > > > Key: NIFI-11912 > URL: https://issues.apache.org/jira/browse/NIFI-11912 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.23.0 >Reporter: Andrea Molteni >Assignee: Nandor Soma Abonyi >Priority: Major > Fix For: 1.latest, 2.latest > > Time Spent: 50m > Remaining Estimate: 0h > > Actually the StandardOauth2AccessTokenProvider is not able to use a Proxy > configuration service controller. > As a result connectivity when requesting a Token does not work and the > StandardOauth2AccessTokenProvider returns a timeout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11924) Closing HDFS file system in resource provider after using
[
https://issues.apache.org/jira/browse/NIFI-11924?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758243#comment-17758243
]
ASF subversion and git services commented on NIFI-11924:
Commit e3bead383c8a39357f5a273b6762ad147f561dea in nifi's branch
refs/heads/support/nifi-1.x from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e3bead383c ]
NIFI-11924 Removed unused import in HDFSResourceInputStream
Signed-off-by: David Handermann
> Closing HDFS file system in resource provider after using
> -
>
> Key: NIFI-11924
> URL: https://issues.apache.org/jira/browse/NIFI-11924
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Reporter: Simon Bence
>Assignee: Simon Bence
>Priority: Critical
> Fix For: 2.0.0, 1.24.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The {{HDFSExternalResourceProvider}} does not close the HDFS {{FileSystem}}
> after usage. This can lead to memory leakage. This needs to be solved.
> Possible solutions:
> I.: Maintain a single {{FileSystem}} resource during the lifecycle of the
> provider and monitor its health
> II.: Open and close a new {{FileSystem}} evert time the provider connects
> with the HDFS
> The first approach is considered a more error prone one as the Provider is
> active during the whole runtime of NiFi, thus additional logic would be
> needed to monitor the health of the resource and replace it in case of need.
> The second approach results a simpler code on the price of the performance:
> opening a new connection every time is subpar compared to the first option
> and in case of a processor which potentially works with high number of flow
> files within a short amount of time would be an important factor. The usage
> of the provider hovewer comes with a small number of calls, not resulting
> significant impact on the performance on NiFi nodes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11912) Add to StandardOauth2AccessTokenProvider controller service the possibility to choose a Proxy Configuration Service
[ https://issues.apache.org/jira/browse/NIFI-11912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758242#comment-17758242 ] ASF subversion and git services commented on NIFI-11912: Commit e9b62f7b835569e2ee29e00aa897a3fb2ccf2688 in nifi's branch refs/heads/main from Nandor Soma Abonyi [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e9b62f7b83 ] NIFI-11912 Added Proxy support to StandardOauth2AccessTokenProvider This closes #7609 Signed-off-by: David Handermann > Add to StandardOauth2AccessTokenProvider controller service the possibility > to choose a Proxy Configuration Service > > > Key: NIFI-11912 > URL: https://issues.apache.org/jira/browse/NIFI-11912 > Project: Apache NiFi > Issue Type: New Feature > Components: Core Framework >Affects Versions: 1.23.0 >Reporter: Andrea Molteni >Assignee: Nandor Soma Abonyi >Priority: Major > Fix For: 1.latest, 2.latest > > Time Spent: 50m > Remaining Estimate: 0h > > Actually the StandardOauth2AccessTokenProvider is not able to use a Proxy > configuration service controller. > As a result connectivity when requesting a Token does not work and the > StandardOauth2AccessTokenProvider returns a timeout. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] exceptionfactory closed pull request #7609: NIFI-11912 Add Proxy Configuration Service property to StandardOauth2AccessTokenProvider
exceptionfactory closed pull request #7609: NIFI-11912 Add Proxy Configuration Service property to StandardOauth2AccessTokenProvider URL: https://github.com/apache/nifi/pull/7609 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on pull request #7537: NIFI-11778 refactored Groovy tests in nifi-elasticsearch-restapi-processors to Java (and JUnit 5)
exceptionfactory commented on PR #7537: URL: https://github.com/apache/nifi/pull/7537#issuecomment-1690642043 > @exceptionfactory Just double checking before I proceed that the way to resolve the conflicts is for me to cut and paste the changes from [#7441](https://github.com/apache/nifi/pull/7441) to my code. Thanks! Yes, copying over and converting the new unit tests is the way to go. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] dan-s1 commented on pull request #7537: NIFI-11778 refactored Groovy tests in nifi-elasticsearch-restapi-processors to Java (and JUnit 5)
dan-s1 commented on PR #7537: URL: https://github.com/apache/nifi/pull/7537#issuecomment-1690606726 @exceptionfactory Just double checking before I proceed that the way to resolve the conflicts is for me to cut and paste the changes from [7441](https://github.com/apache/nifi/pull/7441) to my code. Thanks! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (NIFI-11986) Add all available metrics to PrometheusReportingTask endpoint
Matt Burgess created NIFI-11986: --- Summary: Add all available metrics to PrometheusReportingTask endpoint Key: NIFI-11986 URL: https://issues.apache.org/jira/browse/NIFI-11986 Project: Apache NiFi Issue Type: Improvement Components: Extensions Reporter: Matt Burgess Fix For: 1.latest, 2.latest The Prometheus REST API endpoint includes the following metrics: * NiFi Metrics Registry * JVM Metrics Registry * Connection Analytics Metrics Registry * Bulletin Metrics Registry * Cluster Metrics Registry However PrometheusReportingTask only includes the following: * NiFi Metrics Registry * JVM Metrics Registry This Jira proposes to add the remaining Metrics Registries to PrometheusReportingTask, each with a property (defaulting to false to maintain current behavior) specifying whether to include the metrics in the output. For NiFi 2.0 these properties could default to true instead. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] pvillard31 commented on pull request #7528: NIFI-11857 - CLI - recursively change version of processors
pvillard31 commented on PR #7528: URL: https://github.com/apache/nifi/pull/7528#issuecomment-1690583418 Hey @exceptionfactory - thanks for looking into this. Not sure when I'll be able to find time to get back to this in the near future. The reason I didn't tackle controller services is that it raises some questions such as: after changing the version, when we re-enable the controller service, should we also restart referencing components? I could definitely look into reporting tasks though, should be easy. Thoughts for controller services? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] dan-s1 commented on pull request #7537: NIFI-11778 refactored Groovy tests in nifi-elasticsearch-restapi-processors to Java (and JUnit 5)
dan-s1 commented on PR #7537: URL: https://github.com/apache/nifi/pull/7537#issuecomment-1690579707 @ChrisSamo632 Do I manually cut and paste those changes as in my branch those Groovy files have been deleted? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on a diff in pull request #7604: NIFI-11946 Added preserveSourceProperties query parameter to create flow API
exceptionfactory commented on code in PR #7604:
URL: https://github.com/apache/nifi/pull/7604#discussion_r1303493084
##
nifi-registry/nifi-registry-core/nifi-registry-web-api/src/main/java/org/apache/nifi/registry/web/service/StandardServiceFacade.java:
##
@@ -253,7 +253,7 @@ public VersionedFlow createFlow(final String
bucketIdentifier, final VersionedFl
}
final VersionedFlow createdFlow = createRevisableEntity(versionedFlow,
VERSIONED_FLOW_ENTITY_TYPE, currentUserIdentity(),
-() -> registryService.createFlow(bucketIdentifier,
versionedFlow));
+() -> registryService.createFlow(bucketIdentifier,
versionedFlow,preserveSourceProperties));
Review Comment:
```suggestion
() -> registryService.createFlow(bucketIdentifier,
versionedFlow, preserveSourceProperties));
```
##
nifi-registry/nifi-registry-core/nifi-registry-web-api/src/main/java/org/apache/nifi/registry/web/service/StandardServiceFacade.java:
##
@@ -242,7 +242,7 @@ public List getBucketItems() {
// -- Flow methods
--
@Override
-public VersionedFlow createFlow(final String bucketIdentifier, final
VersionedFlow versionedFlow) {
+public VersionedFlow createFlow(final String bucketIdentifier, final
VersionedFlow versionedFlow,final boolean preserveSourceProperties) {
Review Comment:
```suggestion
public VersionedFlow createFlow(final String bucketIdentifier, final
VersionedFlow versionedFlow, final boolean preserveSourceProperties) {
```
##
nifi-registry/nifi-registry-core/nifi-registry-web-api/src/main/java/org/apache/nifi/registry/web/api/BucketFlowResource.java:
##
@@ -99,11 +99,15 @@ public Response createFlow(
@ApiParam("The bucket identifier")
final String bucketId,
@ApiParam(value = "The details of the flow to create.", required =
true)
-final VersionedFlow flow) {
+final VersionedFlow flow,
+@ApiParam(
+value = "Whether source properties like identifier,name
createdTimestamp and modifiedTimestamp should be kept")
Review Comment:
```suggestion
value = "Whether source properties like identifier,
name, and created should be retained")
```
##
nifi-registry/nifi-registry-core/nifi-registry-web-api/src/main/java/org/apache/nifi/registry/web/api/BucketFlowResource.java:
##
@@ -99,11 +99,15 @@ public Response createFlow(
@ApiParam("The bucket identifier")
final String bucketId,
@ApiParam(value = "The details of the flow to create.", required =
true)
-final VersionedFlow flow) {
+final VersionedFlow flow,
+@ApiParam(
+value = "Whether source properties like identifier,name
createdTimestamp and modifiedTimestamp should be kept")
+@QueryParam("preserveSourceProperties")
+final boolean preserveSourceProperties) {
verifyPathParamsMatchBody(bucketId, flow);
-final VersionedFlow createdFlow = serviceFacade.createFlow(bucketId,
flow);
+final VersionedFlow createdFlow = serviceFacade.createFlow(bucketId,
flow,preserveSourceProperties);
Review Comment:
```suggestion
final VersionedFlow createdFlow = serviceFacade.createFlow(bucketId,
flow, preserveSourceProperties);
```
##
nifi-registry/nifi-registry-core/nifi-registry-framework/src/main/java/org/apache/nifi/registry/service/RegistryService.java:
##
@@ -339,10 +339,12 @@ public VersionedFlow createFlow(final String
bucketIdentifier, final VersionedFl
if (versionedFlow.getBucketIdentifier() == null) {
versionedFlow.setBucketIdentifier(bucketIdentifier);
}
+if (!preserveSourceProperties || (versionedFlow.getCreatedTimestamp()
<= 0) || (versionedFlow.getModifiedTimestamp() <= 0)) {
Review Comment:
Actually this approach could be changed so that if the caller sets the
timestamps, then they will be preserved, instead of passing the
`preserveSourceProperties` argument to this service level. The checks should
also be limited to the created timestamp so that the modified timestamp is
always updated.
```suggestion
if (versionedFlow.getCreatedTimestamp()) {
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
[GitHub] [nifi] ChrisSamo632 commented on pull request #7537: NIFI-11778 refactored Groovy tests in nifi-elasticsearch-restapi-processors to Java (and JUnit 5)
ChrisSamo632 commented on PR #7537: URL: https://github.com/apache/nifi/pull/7537#issuecomment-1690565613 > @ChrisSamo632 Checking in to see if my latest changes are okay. Thanks! @dan-s1 I've been away, but hoping to take a look at your latest changes soon/this week. Note that you've now got some conflicts after #7441 was recently merged - couple of new tests to migrate over for the updated processors -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-11480) PutElasticsearchRecord should have an option to output _bulk api response errors as flowfile attributes
[
https://issues.apache.org/jira/browse/NIFI-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758221#comment-17758221
]
ASF subversion and git services commented on NIFI-11480:
Commit fb502cdf9a1d6fc3abeb9d9abf182a1d8353f35a in nifi's branch
refs/heads/main from Chris Sampson
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=fb502cdf9a ]
NIFI-11480 add option to group PutElasticsearchRecord errors by Elasticsearch
_bulk error type
Signed-off-by: Matt Burgess
This closes #7441
> PutElasticsearchRecord should have an option to output _bulk api response
> errors as flowfile attributes
> ---
>
> Key: NIFI-11480
> URL: https://issues.apache.org/jira/browse/NIFI-11480
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Chris Sampson
>Assignee: Chris Sampson
>Priority: Minor
> Fix For: 1.latest, 2.latest
>
> Attachments: NIFI-11480_Flow.json
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> https://github.com/apache/nifi/pull/6903 for NIFI-1 introduced a
> [conversation|https://github.com/apache/nifi/pull/6903#issuecomment-1513872398]
> about outputting the response error details for Records that are not
> processed by Elasticsearch.
> The same PR introduces a new {{elasticsearch.bulk.error}} attribute for the
> {{PutElasticsearchJson}} processor, but explains why [it's not so simple for
> PutElasticsearchRecord|https://github.com/apache/nifi/pull/6903#issuecomment-1514554132]
> due to input FlowFiles potentially containing many Records and there being
> no obvious way of expressing error details for all such Records in the single
> output flowfile.
> One [suggested
> approach|https://github.com/apache/nifi/pull/6903#issuecomment-1517903668]
> would be to "partition" the output {{errors}} Records into multiple
> flowfiles, grouped by the error {{type}} provided by Elasticsearch. This
> {{type}} could then be added to the flowfile(s) as the
> {{elasticsearch.bulk.error}} attribute. Flows could then {{RouteOnAttribute}}
> if they wanted to handle certain Elasticsearch errors in particular ways.
> Leaving all errors flowfiles in the same output queue avoids the problem of
> the [large (and changing) number of potential Elasticsearch error
> types|https://github.com/apache/nifi/pull/6903#issuecomment-1517863606]
> Such output partitioning (if implemented) should be optional, driven by a
> processor property that maintains the current "all in one" flowfile output by
> default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11480) PutElasticsearchRecord should have an option to output _bulk api response errors as flowfile attributes
[
https://issues.apache.org/jira/browse/NIFI-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Burgess updated NIFI-11480:
Fix Version/s: 2.0.0
1.24.0
(was: 1.latest)
(was: 2.latest)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> PutElasticsearchRecord should have an option to output _bulk api response
> errors as flowfile attributes
> ---
>
> Key: NIFI-11480
> URL: https://issues.apache.org/jira/browse/NIFI-11480
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Chris Sampson
>Assignee: Chris Sampson
>Priority: Minor
> Fix For: 2.0.0, 1.24.0
>
> Attachments: NIFI-11480_Flow.json
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> https://github.com/apache/nifi/pull/6903 for NIFI-1 introduced a
> [conversation|https://github.com/apache/nifi/pull/6903#issuecomment-1513872398]
> about outputting the response error details for Records that are not
> processed by Elasticsearch.
> The same PR introduces a new {{elasticsearch.bulk.error}} attribute for the
> {{PutElasticsearchJson}} processor, but explains why [it's not so simple for
> PutElasticsearchRecord|https://github.com/apache/nifi/pull/6903#issuecomment-1514554132]
> due to input FlowFiles potentially containing many Records and there being
> no obvious way of expressing error details for all such Records in the single
> output flowfile.
> One [suggested
> approach|https://github.com/apache/nifi/pull/6903#issuecomment-1517903668]
> would be to "partition" the output {{errors}} Records into multiple
> flowfiles, grouped by the error {{type}} provided by Elasticsearch. This
> {{type}} could then be added to the flowfile(s) as the
> {{elasticsearch.bulk.error}} attribute. Flows could then {{RouteOnAttribute}}
> if they wanted to handle certain Elasticsearch errors in particular ways.
> Leaving all errors flowfiles in the same output queue avoids the problem of
> the [large (and changing) number of potential Elasticsearch error
> types|https://github.com/apache/nifi/pull/6903#issuecomment-1517863606]
> Such output partitioning (if implemented) should be optional, driven by a
> processor property that maintains the current "all in one" flowfile output by
> default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] mattyb149 closed pull request #7441: NIFI-11480 add option to group PutElasticsearchRecord errors by Elasticsearch _bulk error type
mattyb149 closed pull request #7441: NIFI-11480 add option to group PutElasticsearchRecord errors by Elasticsearch _bulk error type URL: https://github.com/apache/nifi/pull/7441 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] mattyb149 commented on pull request #7441: NIFI-11480 add option to group PutElasticsearchRecord errors by Elasticsearch _bulk error type
mattyb149 commented on PR #7441: URL: https://github.com/apache/nifi/pull/7441#issuecomment-1690558877 +1 LGTM, thanks for the improvement and the reproduction flow! Merging to support/nifi-1.x and main -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Commented] (NIFI-11480) PutElasticsearchRecord should have an option to output _bulk api response errors as flowfile attributes
[
https://issues.apache.org/jira/browse/NIFI-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758218#comment-17758218
]
ASF subversion and git services commented on NIFI-11480:
Commit e99a4259f3d8abdbe97344384ef7622f99888e4c in nifi's branch
refs/heads/support/nifi-1.x from Chris Sampson
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e99a4259f3 ]
NIFI-11480 add option to group PutElasticsearchRecord errors by Elasticsearch
_bulk error type
Signed-off-by: Matt Burgess
> PutElasticsearchRecord should have an option to output _bulk api response
> errors as flowfile attributes
> ---
>
> Key: NIFI-11480
> URL: https://issues.apache.org/jira/browse/NIFI-11480
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Chris Sampson
>Assignee: Chris Sampson
>Priority: Minor
> Fix For: 1.latest, 2.latest
>
> Attachments: NIFI-11480_Flow.json
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> https://github.com/apache/nifi/pull/6903 for NIFI-1 introduced a
> [conversation|https://github.com/apache/nifi/pull/6903#issuecomment-1513872398]
> about outputting the response error details for Records that are not
> processed by Elasticsearch.
> The same PR introduces a new {{elasticsearch.bulk.error}} attribute for the
> {{PutElasticsearchJson}} processor, but explains why [it's not so simple for
> PutElasticsearchRecord|https://github.com/apache/nifi/pull/6903#issuecomment-1514554132]
> due to input FlowFiles potentially containing many Records and there being
> no obvious way of expressing error details for all such Records in the single
> output flowfile.
> One [suggested
> approach|https://github.com/apache/nifi/pull/6903#issuecomment-1517903668]
> would be to "partition" the output {{errors}} Records into multiple
> flowfiles, grouped by the error {{type}} provided by Elasticsearch. This
> {{type}} could then be added to the flowfile(s) as the
> {{elasticsearch.bulk.error}} attribute. Flows could then {{RouteOnAttribute}}
> if they wanted to handle certain Elasticsearch errors in particular ways.
> Leaving all errors flowfiles in the same output queue avoids the problem of
> the [large (and changing) number of potential Elasticsearch error
> types|https://github.com/apache/nifi/pull/6903#issuecomment-1517863606]
> Such output partitioning (if implemented) should be optional, driven by a
> processor property that maintains the current "all in one" flowfile output by
> default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11934) InvokeHTTP does not send filename attribute
[ https://issues.apache.org/jira/browse/NIFI-11934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Bean updated NIFI-11934: - Status: Patch Available (was: In Progress) > InvokeHTTP does not send filename attribute > --- > > Key: NIFI-11934 > URL: https://issues.apache.org/jira/browse/NIFI-11934 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.23.0 >Reporter: Mark Bean >Assignee: Mark Bean >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The InvokeHTTP processor can be configured to send FlowFile attributes when > using the POST HTTP method. Certain attributes are excluded from being sent. > These include some core attributes: UUID, FILENAME and PATH. It makes sense > to exclude UUID and PATH as these will be created/assigned when the FlowFile > is received by a ListenHTTP processor. However, filename should be allowed to > remain as the original filename. > Not only is does this make good sense from a flow perspective, but it is also > consistent with the behavior of the now-deprecated PostHTTP processor. This > functionality must be maintained or dataflows will break when PostHTTP is no > longer available. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11985) Implement a processor to consume documents from Elasticsearch indices
[
https://issues.apache.org/jira/browse/NIFI-11985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Sampson updated NIFI-11985:
-
Description:
It is possible to use Elasticsearch to store series data, i.e. data is
continually added to an Elasticsearch index over time, with a {{date}} or a
1-up numeric {{long}} field.
This is more likely with the advent of [Data
Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html)
or the recent [Time Series Data
Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds.html),
both of which use a {{@timestamp}} field to indicate when a document was added
to the stream.
There are use cases where NiFi users may want to consume new data from the
Elasticsearch index/data stream after it's arrived, then pass it to another
service.
NiFi would need to:
* know which field to use as the "series field" (e.g. {{@timestamp}})
* track the last read "series field" value via State so that the same documents
are not retrieved from Elasticsearch multiple times
* allow for the optional specification of the "last read" field value, e.g. if
a user wants to offset the start of the documents to be read (this value should
only be used if a value doesn't also exist within the processor's State)
* allow for the fact that the "last read" vlaue will be blank when the
processor is first run (and the value is not otherwise specified), meaning we
want to retrieve all existing data
* allow for users to specify an optional Query Filter to apply to the search
within Elasticsearch when finding documents to retrieve
Possible implementations should consider using the {{SearchElasticsearch}}
processor as a basis, which already uses State tracking between processor
executions and allows for the retrieval of Elasticsearch documents in a
paginated manner (thus avoiding pulling too much data in a single request).
was:
It is possible to use Elasticsearch to store series data, i.e. data is
continually added to an Elasticsearch index over time, with a {{date}} or a
1-up numeric {{long}} field.
This is more likely with the advent of [Data
Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html)
or the recent [Time Series Data
Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds.html),
both of which use a {{@timestamp}} field to indicate when a document was added
to the stream.
There are use cases where NiFi users may want to consume new data from the
Elasticsearch index/data stream after it's arrived, then pass it to another
service.
NiFi would need to know which field to use as the "series field" (e.g.
{{@timestamp}}) and track this via State so that the same documents are not
retrieved from Elasticsearch multiple times. Possible implementations should
consider using the {{SearchElasticsearch}} processor as a basis, which already
uses State tracking between processor executions and allows for the retrieval
of Elasticsearch documents in a paginated manner (thus avoiding pulling too
much data in a single request).
> Implement a processor to consume documents from Elasticsearch indices
> -
>
> Key: NIFI-11985
> URL: https://issues.apache.org/jira/browse/NIFI-11985
> Project: Apache NiFi
> Issue Type: New Feature
>Reporter: Chris Sampson
>Priority: Minor
>
> It is possible to use Elasticsearch to store series data, i.e. data is
> continually added to an Elasticsearch index over time, with a {{date}} or a
> 1-up numeric {{long}} field.
> This is more likely with the advent of [Data
> Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html)
> or the recent [Time Series Data
> Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds.html),
> both of which use a {{@timestamp}} field to indicate when a document was
> added to the stream.
> There are use cases where NiFi users may want to consume new data from the
> Elasticsearch index/data stream after it's arrived, then pass it to another
> service.
> NiFi would need to:
> * know which field to use as the "series field" (e.g. {{@timestamp}})
> * track the last read "series field" value via State so that the same
> documents are not retrieved from Elasticsearch multiple times
> * allow for the optional specification of the "last read" field value, e.g.
> if a user wants to offset the start of the documents to be read (this value
> should only be used if a value doesn't also exist within the processor's
> State)
> * allow for the fact that the "last read" vlaue will be blank when the
> processor is first run (and the value is not otherwise specified), meaning we
> want to retrieve all existing data
> * allow for users to specify an
[jira] [Resolved] (NIFI-11975) Update okio.version to 3.5.0
[ https://issues.apache.org/jira/browse/NIFI-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann resolved NIFI-11975. - Fix Version/s: 2.0.0 1.24.0 Resolution: Fixed > Update okio.version to 3.5.0 > > > Key: NIFI-11975 > URL: https://issues.apache.org/jira/browse/NIFI-11975 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Fix For: 2.0.0, 1.24.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Update okio.version to 3.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11975) Update okio.version to 3.5.0
[ https://issues.apache.org/jira/browse/NIFI-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11975: Affects Version/s: (was: 1.23.1) (was: 1.23.2) > Update okio.version to 3.5.0 > > > Key: NIFI-11975 > URL: https://issues.apache.org/jira/browse/NIFI-11975 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Update okio.version to 3.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11975) Update okio.version to 3.5.0
[ https://issues.apache.org/jira/browse/NIFI-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-11975: Priority: Minor (was: Major) > Update okio.version to 3.5.0 > > > Key: NIFI-11975 > URL: https://issues.apache.org/jira/browse/NIFI-11975 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Mike R >Assignee: Mike R >Priority: Minor > Time Spent: 0.5h > Remaining Estimate: 0h > > Update okio.version to 3.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11972) Release NiFi 1.23.2
[ https://issues.apache.org/jira/browse/NIFI-11972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758207#comment-17758207 ] ASF subversion and git services commented on NIFI-11972: Commit 08101352a04c91f2f977f891b0a2a5f1a1632570 in nifi's branch refs/heads/support/nifi-1.x from mr1716 [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=08101352a0 ] NIFI-11972 Upgraded Okio from 3.4.0 to 3.5.0 - Upgraded Kotlin from 1.8.20 to 1.9.0 This closes #7636 Signed-off-by: David Handermann > Release NiFi 1.23.2 > --- > > Key: NIFI-11972 > URL: https://issues.apache.org/jira/browse/NIFI-11972 > Project: Apache NiFi > Issue Type: Task >Reporter: David Handermann >Assignee: David Handermann >Priority: Major > Fix For: 1.23.2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-11985) Implement a processor to consume documents from Elasticsearch indices
Chris Sampson created NIFI-11985:
Summary: Implement a processor to consume documents from
Elasticsearch indices
Key: NIFI-11985
URL: https://issues.apache.org/jira/browse/NIFI-11985
Project: Apache NiFi
Issue Type: New Feature
Reporter: Chris Sampson
It is possible to use Elasticsearch to store series data, i.e. data is
continually added to an Elasticsearch index over time, with a {{date}} or a
1-up numeric {{long}} field.
This is more likely with the advent of [Data
Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/data-streams.html)
or the recent [Time Series Data
Streams](https://www.elastic.co/guide/en/elasticsearch/reference/current/tsds.html),
both of which use a {{@timestamp}} field to indicate when a document was added
to the stream.
There are use cases where NiFi users may want to consume new data from the
Elasticsearch index/data stream after it's arrived, then pass it to another
service.
NiFi would need to know which field to use as the "series field" (e.g.
{{@timestamp}}) and track this via State so that the same documents are not
retrieved from Elasticsearch multiple times. Possible implementations should
consider using the {{SearchElasticsearch}} processor as a basis, which already
uses State tracking between processor executions and allows for the retrieval
of Elasticsearch documents in a paginated manner (thus avoiding pulling too
much data in a single request).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11975) Update okio.version to 3.5.0
[ https://issues.apache.org/jira/browse/NIFI-11975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758205#comment-17758205 ] ASF subversion and git services commented on NIFI-11975: Commit 9a0b3d0ce093e2583b31d9f13b81de0e14291ea1 in nifi's branch refs/heads/main from mr1716 [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=9a0b3d0ce0 ] NIFI-11975 Upgraded Okio from 3.4.0 to 3.5.0 - Upgraded Kotlin from 1.8.20 to 1.9.0 This closes #7636 Signed-off-by: David Handermann > Update okio.version to 3.5.0 > > > Key: NIFI-11975 > URL: https://issues.apache.org/jira/browse/NIFI-11975 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.23.1, 1.23.2 >Reporter: Mike R >Assignee: Mike R >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Update okio.version to 3.5.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] exceptionfactory closed pull request #7636: NIFI-11975 Update okio.version to 3.5.0
exceptionfactory closed pull request #7636: NIFI-11975 Update okio.version to 3.5.0 URL: https://github.com/apache/nifi/pull/7636 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi] ChrisSamo632 commented on pull request #7441: NIFI-11480 add option to group PutElasticsearchRecord errors by Elasticsearch _bulk error type
ChrisSamo632 commented on PR #7441: URL: https://github.com/apache/nifi/pull/7441#issuecomment-1690502339 @mattyb149 I've added an example Flow Definition to the Jira ticket that exhibits this behaviour, for reference -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Resolved] (NIFI-11978) NPE when trying to disable Management Controller Service
[
https://issues.apache.org/jira/browse/NIFI-11978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann resolved NIFI-11978.
-
Fix Version/s: 2.0.0
Resolution: Fixed
> NPE when trying to disable Management Controller Service
>
>
> Key: NIFI-11978
> URL: https://issues.apache.org/jira/browse/NIFI-11978
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Tamas Palfy
>Assignee: Tamas Palfy
>Priority: Major
> Fix For: 2.0.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> -With https://issues.apache.org/jira/browse/NIFI-11556 controller services
> implement the GroupedComponent interface. However Management Controller
> Services (the ones available and managed from the Controller Settings) don’t
> have groups.-
> With https://issues.apache.org/jira/browse/NIFI-11556 when verifying if we
> can update controller service referencing components we check if the Process
> Group of the Controller Service allows scheduling of components individually.
> However this part of the change didn't take into account that Management
> Controller Services don't belong to any Process Group and a
> NullPointerException is thrown when we try to disable one:
> {code:java}
> public class StandardControllerServiceDAO extends ComponentDAO implements
> ControllerServiceDAO {
> ...
> @Override
> public void verifyUpdateReferencingComponents(final String
> controllerServiceId, final ScheduledState scheduledState, final
> ControllerServiceState controllerServiceState) {
> final ControllerServiceNode controllerService =
> locateControllerService(controllerServiceId);
>
> controllerService.getProcessGroup().verifyCanScheduleComponentsIndividually();
> {code}
> which throws NullPointerException (as there is no process group).
> Tagging [~markap14] and [~exceptionfactory] as author and reviewer of
> NIFI-11556
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11978) NPE when trying to disable Management Controller Service
[
https://issues.apache.org/jira/browse/NIFI-11978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758201#comment-17758201
]
ASF subversion and git services commented on NIFI-11978:
Commit 1e12800912ce0cd368e7827e9b50470ff5c1db18 in nifi's branch
refs/heads/main from Tamas Palfy
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=1e12800912 ]
NIFI-11978 Fix: NPE when trying to disable Management Controller Service
This closes #7637
Signed-off-by: David Handermann
> NPE when trying to disable Management Controller Service
>
>
> Key: NIFI-11978
> URL: https://issues.apache.org/jira/browse/NIFI-11978
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Reporter: Tamas Palfy
>Assignee: Tamas Palfy
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> -With https://issues.apache.org/jira/browse/NIFI-11556 controller services
> implement the GroupedComponent interface. However Management Controller
> Services (the ones available and managed from the Controller Settings) don’t
> have groups.-
> With https://issues.apache.org/jira/browse/NIFI-11556 when verifying if we
> can update controller service referencing components we check if the Process
> Group of the Controller Service allows scheduling of components individually.
> However this part of the change didn't take into account that Management
> Controller Services don't belong to any Process Group and a
> NullPointerException is thrown when we try to disable one:
> {code:java}
> public class StandardControllerServiceDAO extends ComponentDAO implements
> ControllerServiceDAO {
> ...
> @Override
> public void verifyUpdateReferencingComponents(final String
> controllerServiceId, final ScheduledState scheduledState, final
> ControllerServiceState controllerServiceState) {
> final ControllerServiceNode controllerService =
> locateControllerService(controllerServiceId);
>
> controllerService.getProcessGroup().verifyCanScheduleComponentsIndividually();
> {code}
> which throws NullPointerException (as there is no process group).
> Tagging [~markap14] and [~exceptionfactory] as author and reviewer of
> NIFI-11556
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11480) PutElasticsearchRecord should have an option to output _bulk api response errors as flowfile attributes
[
https://issues.apache.org/jira/browse/NIFI-11480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Sampson updated NIFI-11480:
-
Attachment: NIFI-11480_Flow.json
> PutElasticsearchRecord should have an option to output _bulk api response
> errors as flowfile attributes
> ---
>
> Key: NIFI-11480
> URL: https://issues.apache.org/jira/browse/NIFI-11480
> Project: Apache NiFi
> Issue Type: Improvement
>Reporter: Chris Sampson
>Assignee: Chris Sampson
>Priority: Minor
> Fix For: 1.latest, 2.latest
>
> Attachments: NIFI-11480_Flow.json
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> https://github.com/apache/nifi/pull/6903 for NIFI-1 introduced a
> [conversation|https://github.com/apache/nifi/pull/6903#issuecomment-1513872398]
> about outputting the response error details for Records that are not
> processed by Elasticsearch.
> The same PR introduces a new {{elasticsearch.bulk.error}} attribute for the
> {{PutElasticsearchJson}} processor, but explains why [it's not so simple for
> PutElasticsearchRecord|https://github.com/apache/nifi/pull/6903#issuecomment-1514554132]
> due to input FlowFiles potentially containing many Records and there being
> no obvious way of expressing error details for all such Records in the single
> output flowfile.
> One [suggested
> approach|https://github.com/apache/nifi/pull/6903#issuecomment-1517903668]
> would be to "partition" the output {{errors}} Records into multiple
> flowfiles, grouped by the error {{type}} provided by Elasticsearch. This
> {{type}} could then be added to the flowfile(s) as the
> {{elasticsearch.bulk.error}} attribute. Flows could then {{RouteOnAttribute}}
> if they wanted to handle certain Elasticsearch errors in particular ways.
> Leaving all errors flowfiles in the same output queue avoids the problem of
> the [large (and changing) number of potential Elasticsearch error
> types|https://github.com/apache/nifi/pull/6903#issuecomment-1517863606]
> Such output partitioning (if implemented) should be optional, driven by a
> processor property that maintains the current "all in one" flowfile output by
> default.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[GitHub] [nifi] exceptionfactory closed pull request #7637: NIFI-11978 Fix: NPE when trying to disable Management Controller Service
exceptionfactory closed pull request #7637: NIFI-11978 Fix: NPE when trying to disable Management Controller Service URL: https://github.com/apache/nifi/pull/7637 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[GitHub] [nifi-minifi-cpp] szaszm commented on a diff in pull request #1638: MINIFICPP-1774 Set properties from command line arguments
szaszm commented on code in PR #1638: URL: https://github.com/apache/nifi-minifi-cpp/pull/1638#discussion_r1303419741 ## minifi_main/MiNiFiMain.cpp: ## Review Comment: Could we add a `--help` option that just prints help and exists with 0? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-11518) Upgrade to Jetty 10
[
https://issues.apache.org/jira/browse/NIFI-11518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Burgess updated NIFI-11518:
Fix Version/s: 2.0.0
(was: 2.latest)
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Upgrade to Jetty 10
> ---
>
> Key: NIFI-11518
> URL: https://issues.apache.org/jira/browse/NIFI-11518
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Extensions, MiNiFi, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Critical
> Fix For: 2.0.0
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Jetty 9.4 reached [end of community
> support|https://github.com/eclipse/jetty.project/issues/7958] in May 2022.
> Jetty 10 and 11 are currently supported, with Jetty 10 supporting traditional
> {{javax.servlet}} interfaces and Jetty 11 supporting newer
> {{jakarta.servlet}} interfaces.
> Jetty 10 requires Java 11 as the minimum version, and should be the target
> version to minimize initial impact on project components.
> Current project structure enforces a common Jetty version at the root level
> through dependency management, and standard NAR bundles depend on Jetty for a
> shared runtime version. This approach may need to be modified for components
> with transitive dependencies.
> The Jetty 10 Programming Guide highlights [several important changes from 9.4
> to
> 10|https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#pg-migration-94-to-10],
> including renamed WebSocket libraries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-11518) Upgrade to Jetty 10
[
https://issues.apache.org/jira/browse/NIFI-11518?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758192#comment-17758192
]
ASF subversion and git services commented on NIFI-11518:
Commit c08560447fe2990c9d244731a09ed27ca770cb50 in nifi's branch
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=c08560447f ]
NIFI-11518 Upgraded Jetty from 9.4.51 to 10.0.15
- Updated Jetty WebSocket components using Jetty 10 components
- Upgraded Solr components from 8.11.2 to 9.2.1 to align with Jetty 10
dependencies
Signed-off-by: Matt Burgess
This closes #7622
> Upgrade to Jetty 10
> ---
>
> Key: NIFI-11518
> URL: https://issues.apache.org/jira/browse/NIFI-11518
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework, Extensions, MiNiFi, NiFi Registry
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Critical
> Fix For: 2.latest
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Jetty 9.4 reached [end of community
> support|https://github.com/eclipse/jetty.project/issues/7958] in May 2022.
> Jetty 10 and 11 are currently supported, with Jetty 10 supporting traditional
> {{javax.servlet}} interfaces and Jetty 11 supporting newer
> {{jakarta.servlet}} interfaces.
> Jetty 10 requires Java 11 as the minimum version, and should be the target
> version to minimize initial impact on project components.
> Current project structure enforces a common Jetty version at the root level
> through dependency management, and standard NAR bundles depend on Jetty for a
> shared runtime version. This approach may need to be modified for components
> with transitive dependencies.
> The Jetty 10 Programming Guide highlights [several important changes from 9.4
> to
> 10|https://www.eclipse.org/jetty/documentation/jetty-10/programming-guide/index.html#pg-migration-94-to-10],
> including renamed WebSocket libraries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-11981) PublishGCPubSub failure on usage of Record-based processing
[ https://issues.apache.org/jira/browse/NIFI-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-11981: Fix Version/s: 2.0.0 1.24.0 (was: 1.latest) (was: 2.latest) Resolution: Fixed Status: Resolved (was: Patch Available) > PublishGCPubSub failure on usage of Record-based processing > > > Key: NIFI-11981 > URL: https://issues.apache.org/jira/browse/NIFI-11981 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 2.0.0, 1.24.0 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The processor "PublishGCPubSub" was recently updated to optionally provide > for FlowFile processing using a record-based strategy. When this option is > used with an Avro record reader, a failure to close resources coding error > was surfaced. > Fix should adjust record-based FlowFile handling to properly close resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11981) PublishGCPubSub failure on usage of Record-based processing
[ https://issues.apache.org/jira/browse/NIFI-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758187#comment-17758187 ] ASF subversion and git services commented on NIFI-11981: Commit c0c1b386f61737635eab3f42e3d0b97296fa09f3 in nifi's branch refs/heads/main from Paul Grey [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=c0c1b386f6 ] NIFI-11981 - PublishGCPubSub failure / Record-based processing / AVRO Signed-off-by: Matt Burgess This closes #7638 > PublishGCPubSub failure on usage of Record-based processing > > > Key: NIFI-11981 > URL: https://issues.apache.org/jira/browse/NIFI-11981 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 1.latest, 2.latest > > Time Spent: 0.5h > Remaining Estimate: 0h > > The processor "PublishGCPubSub" was recently updated to optionally provide > for FlowFile processing using a record-based strategy. When this option is > used with an Avro record reader, a failure to close resources coding error > was surfaced. > Fix should adjust record-based FlowFile handling to properly close resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-11981) PublishGCPubSub failure on usage of Record-based processing
[ https://issues.apache.org/jira/browse/NIFI-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758186#comment-17758186 ] ASF subversion and git services commented on NIFI-11981: Commit 3c801604864695512b1ec01c976ef82dc552ded3 in nifi's branch refs/heads/support/nifi-1.x from Paul Grey [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=3c80160486 ] NIFI-11981 - PublishGCPubSub failure / Record-based processing / AVRO Signed-off-by: Matt Burgess > PublishGCPubSub failure on usage of Record-based processing > > > Key: NIFI-11981 > URL: https://issues.apache.org/jira/browse/NIFI-11981 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 1.latest, 2.latest > > Time Spent: 10m > Remaining Estimate: 0h > > The processor "PublishGCPubSub" was recently updated to optionally provide > for FlowFile processing using a record-based strategy. When this option is > used with an Avro record reader, a failure to close resources coding error > was surfaced. > Fix should adjust record-based FlowFile handling to properly close resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] mattyb149 closed pull request #7638: NIFI-11981 - PublishGCPubSub failure / Record-based processing / AVRO
mattyb149 closed pull request #7638: NIFI-11981 - PublishGCPubSub failure / Record-based processing / AVRO URL: https://github.com/apache/nifi/pull/7638 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (NIFI-11981) PublishGCPubSub failure on usage of Record-based processing
[ https://issues.apache.org/jira/browse/NIFI-11981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-11981: Fix Version/s: 1.latest 2.latest > PublishGCPubSub failure on usage of Record-based processing > > > Key: NIFI-11981 > URL: https://issues.apache.org/jira/browse/NIFI-11981 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Paul Grey >Assignee: Paul Grey >Priority: Minor > Fix For: 1.latest, 2.latest > > Time Spent: 10m > Remaining Estimate: 0h > > The processor "PublishGCPubSub" was recently updated to optionally provide > for FlowFile processing using a record-based strategy. When this option is > used with an Avro record reader, a failure to close resources coding error > was surfaced. > Fix should adjust record-based FlowFile handling to properly close resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi] markobean opened a new pull request, #7639: NIFI-11934 allow FlowFile filename to be transmitted in HTTP header f…
markobean opened a new pull request, #7639: URL: https://github.com/apache/nifi/pull/7639 …or InvokeHTTP # Summary Removed 'filename' from the list of attributes to exclude when sending FlowFIle attributes using InvokeHTTP. Updated some of the documentation as well. [NIFI-11934](https://issues.apache.org/jira/browse/NIFI-11934) # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [X] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [X] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [X] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [X] Pull Request based on current revision of the `main` branch - [X] Pull Request refers to a feature branch with one commit containing changes # Verification Instantiate InvokeHTTP and set 'Request Header Attributes Pattern' to ".*" (or any other value which will include the "filename" attribute.) Receive FlowFile with a corresponding ListenHTTP. Verify 'filename' is as expected (same as FlowFile that was transferred.) ### Build - [X] Build completed using `mvn clean install -P contrib-check` - [X] JDK 17 ### Licensing - [ ] New dependencies are compatible with the [Apache License 2.0](https://apache.org/licenses/LICENSE-2.0) according to the [License Policy](https://www.apache.org/legal/resolved.html) - [ ] New dependencies are documented in applicable `LICENSE` and `NOTICE` files ### Documentation - [X] Documentation formatting appears as expected in rendered files -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Created] (NIFI-11984) Add Controller Services to Summary table
Pierre Villard created NIFI-11984: - Summary: Add Controller Services to Summary table Key: NIFI-11984 URL: https://issues.apache.org/jira/browse/NIFI-11984 Project: Apache NiFi Issue Type: Improvement Components: Core UI Reporter: Pierre Villard It would be nice to have a tab for Controller Services in the Summary table in order to have an overview of all controller services defined across all process groups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (MINIFICPP-2192) Windows service installation should be possible as normal user
Marton Szasz created MINIFICPP-2192: --- Summary: Windows service installation should be possible as normal user Key: MINIFICPP-2192 URL: https://issues.apache.org/jira/browse/MINIFICPP-2192 Project: Apache NiFi MiNiFi C++ Issue Type: Bug Reporter: Marton Szasz Currently only the default Local System user works. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] lordgamez opened a new pull request, #1639: MINIFICPP-1275 Remove deprecated ScopeGuard class
lordgamez opened a new pull request, #1639: URL: https://github.com/apache/nifi-minifi-cpp/pull/1639 https://issues.apache.org/jira/browse/MINIFICPP-1275 --- Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically main)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Assigned] (MINIFICPP-1275) [Due to 1.0.0] Remove deprecated ScopeGuard class
[ https://issues.apache.org/jira/browse/MINIFICPP-1275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gábor Gyimesi reassigned MINIFICPP-1275: Assignee: Gábor Gyimesi > [Due to 1.0.0] Remove deprecated ScopeGuard class > - > > Key: MINIFICPP-1275 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1275 > Project: Apache NiFi MiNiFi C++ > Issue Type: Task >Affects Versions: 0.7.0 >Reporter: Adam Hunyadi >Assignee: Gábor Gyimesi >Priority: Trivial > Fix For: 1.0.0 > > > *Background:* > ScopeGuard was deprecated and marked for removal in 1.0.0 due to equivalent > functionality ported in gsl. > *Proposal:* > On the major version change we should remove this class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[GitHub] [nifi-minifi-cpp] lordgamez opened a new pull request, #1638: MINIFICPP-1774 Set properties from command line arguments
lordgamez opened a new pull request, #1638: URL: https://github.com/apache/nifi-minifi-cpp/pull/1638 - Remove ArgParser class and use thirdparty argparse library instead - Add -p/--property option to override configuration properties https://issues.apache.org/jira/browse/MINIFICPP-1774 Thank you for submitting a contribution to Apache NiFi - MiNiFi C++. In order to streamline the review of the contribution we ask you to ensure the following steps have been taken: ### For all changes: - [ ] Is there a JIRA ticket associated with this PR? Is it referenced in the commit message? - [ ] Does your PR title start with MINIFICPP- where is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character. - [ ] Has your PR been rebased against the latest commit within the target branch (typically main)? - [ ] Is your initial contribution a single, squashed commit? ### For code changes: - [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)? - [ ] If applicable, have you updated the LICENSE file? - [ ] If applicable, have you updated the NOTICE file? ### For documentation related changes: - [ ] Have you ensured that format looks appropriate for the output in which it is rendered? ### Note: Please ensure that once the PR is submitted, you check GitHub Actions CI results for build issues and submit an update to your PR as soon as possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@nifi.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
[jira] [Updated] (MINIFICPP-2115) Improve the readability of CI
[ https://issues.apache.org/jira/browse/MINIFICPP-2115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Martin Zink updated MINIFICPP-2115: --- Priority: Trivial (was: Major) > Improve the readability of CI > - > > Key: MINIFICPP-2115 > URL: https://issues.apache.org/jira/browse/MINIFICPP-2115 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Martin Zink >Priority: Trivial > > We should use github action summary to improve the readability of CI outputs -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-1046) Rethink PublishKafka Target Batch Payload Size
[ https://issues.apache.org/jira/browse/MINIFICPP-1046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-1046: Priority: Minor (was: Major) > Rethink PublishKafka Target Batch Payload Size > -- > > Key: MINIFICPP-1046 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1046 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Dániel Bakai >Priority: Minor > > It would better to have a Max Batch Payload Size. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-1027) Move getclassname to ClassUtils
[ https://issues.apache.org/jira/browse/MINIFICPP-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-1027: Labels: easyfix newbie starter (was: ) > Move getclassname to ClassUtils > --- > > Key: MINIFICPP-1027 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1027 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Trivial > Labels: easyfix, newbie, starter > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-1044) Processors are being triggered even if they are stopped
[ https://issues.apache.org/jira/browse/MINIFICPP-1044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-1044. - Resolution: Fixed > Processors are being triggered even if they are stopped > --- > > Key: MINIFICPP-1044 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1044 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Major > > SchedulingAgent doesn't respect running state of processors, triggers them > unless they are yield. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-1035) MQTT processors doesn't export security-related properties
[ https://issues.apache.org/jira/browse/MINIFICPP-1035?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-1035. - Resolution: Fixed > MQTT processors doesn't export security-related properties > -- > > Key: MINIFICPP-1035 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1035 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Affects Versions: 0.6.0 >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Major > > MQTT processors doesn't export security related properties, which means they > can only connect via plain TCP. > It's not going to be fixed on scope of MINIFICPP-1034 as the feature seems to > be untested. This ticket is a follow up to verify secure communication before > enabling related properties. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-1027) Move getclassname to ClassUtils
[ https://issues.apache.org/jira/browse/MINIFICPP-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-1027: Priority: Trivial (was: Major) > Move getclassname to ClassUtils > --- > > Key: MINIFICPP-1027 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1027 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Trivial > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (MINIFICPP-1019) Python Processor Building, Setup, and Configuration
[ https://issues.apache.org/jira/browse/MINIFICPP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17758106#comment-17758106 ] Marton Szasz commented on MINIFICPP-1019: - We have examples at https://github.com/apache/nifi-minifi-cpp/blob/main/examples/scripts/README.md But more detailed docs for configuration details would be nice > Python Processor Building, Setup, and Configuration > --- > > Key: MINIFICPP-1019 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1019 > Project: Apache NiFi MiNiFi C++ > Issue Type: Documentation >Reporter: Jeremy Dyer >Priority: Minor > > Create documentation for building the minifi binary for Python processor > support, creating Python processors, and configuring the minifi agent runtime > to run your created processors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-1021) Enable TLS 1.3 support
[ https://issues.apache.org/jira/browse/MINIFICPP-1021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-1021. - Resolution: Fixed > Enable TLS 1.3 support > -- > > Key: MINIFICPP-1021 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1021 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Dániel Bakai >Priority: Major > > Since we now always ship libressl, curl and civetweb we can update them to > the proper versions to support TLS 1.3 for both incoming and outgoing > connections. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-1019) Python Processor Building, Setup, and Configuration
[ https://issues.apache.org/jira/browse/MINIFICPP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-1019: Priority: Minor (was: Major) > Python Processor Building, Setup, and Configuration > --- > > Key: MINIFICPP-1019 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1019 > Project: Apache NiFi MiNiFi C++ > Issue Type: Documentation >Reporter: Jeremy Dyer >Assignee: Jeremy Dyer >Priority: Minor > > Create documentation for building the minifi binary for Python processor > support, creating Python processors, and configuring the minifi agent runtime > to run your created processors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINIFICPP-1019) Python Processor Building, Setup, and Configuration
[ https://issues.apache.org/jira/browse/MINIFICPP-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reassigned MINIFICPP-1019: --- Assignee: (was: Jeremy Dyer) > Python Processor Building, Setup, and Configuration > --- > > Key: MINIFICPP-1019 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1019 > Project: Apache NiFi MiNiFi C++ > Issue Type: Documentation >Reporter: Jeremy Dyer >Priority: Minor > > Create documentation for building the minifi binary for Python processor > support, creating Python processors, and configuring the minifi agent runtime > to run your created processors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-1016) Resolve CWEL fields in XML
[ https://issues.apache.org/jira/browse/MINIFICPP-1016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-1016. - Resolution: Fixed > Resolve CWEL fields in XML > -- > > Key: MINIFICPP-1016 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1016 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Marc Parisi >Assignee: Marc Parisi >Priority: Major > > Fields should be resolved to match what windows produces for the detailed > view. We can handle this in line with the XML -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-1004) Env vars shouldn't appear in config file: deployment should handle them
[ https://issues.apache.org/jira/browse/MINIFICPP-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-1004. - Resolution: Won't Fix > Env vars shouldn't appear in config file: deployment should handle them > --- > > Key: MINIFICPP-1004 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1004 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: 0.6.0 >Reporter: Arpad Boda >Priority: Major > Fix For: 1.0.0 > > > Deployment of MiNiFi should COPY the config file, replace env vars and run > MiNiFi using that. > MiNiFi binary itself shouldn't handle env vars in config files. > As this is a breaking change, env vars being found in the config file should > end in failed loading instead of silently processing without handling the env > var. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-1001) Provide better logging when a stoppage delay occurs
[ https://issues.apache.org/jira/browse/MINIFICPP-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-1001. - Resolution: Fixed > Provide better logging when a stoppage delay occurs > --- > > Key: MINIFICPP-1001 > URL: https://issues.apache.org/jira/browse/MINIFICPP-1001 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Major > > I experienced a delay because part of the RPG code was waiting to complete. > We can probably make this a bit more clear to the user in the logs that we're > waiting on this "processor" to stop. > > [2019-08-13 08:37:55.453] [org::apache::nifi::minifi::FlowController] [info] > Started Flow Controller > [2019-08-13 08:37:55.453] [main] [info] MiNiFi started > [2019-08-13 08:37:55.453] [org::apache::nifi::minifi::FlowController] [info] > Stop Flow Controller > [2019-08-13 08:37:55.848] [org::apache::nifi::minifi::processors::TailFile] > [error] store state file failed > [2019-08-13 08:37:57.865] [org::apache::nifi::minifi::utils::HTTPClient] > [error] curl_easy_perform() failed Timeout was reached on > http://192.168.1.172:10080/efm/api/c2-protocol/heartbeat > [2019-08-13 08:38:00.274] [org::apache::nifi::minifi::utils::HTTPClient] > [error] curl_easy_perform() failed Timeout was reached on > http://192.168.1.172:10080/efm/api/c2-protocol/heartbeat > [2019-08-13 08:38:02.683] [org::apache::nifi::minifi::utils::HTTPClient] > [error] curl_easy_perform() failed Timeout was reached on > http://192.168.1.172:10080/efm/api/c2-protocol/heartbeat > [2019-08-13 08:38:05.091] [org::apache::nifi::minifi::utils::HTTPClient] > [error] curl_easy_perform() failed Timeout was reached on > http://192.168.1.172:10080/efm/api/c2-protocol/heartbeat > [2019-08-13 08:38:05.447] [org::apache::nifi::minifi::utils::HTTPClient] > [error] curl_easy_perform() failed Timeout was reached on > http://192.168.1.172:8080/nifi-api/site-to-site > [2019-08-13 08:38:05.447] > [org::apache::nifi::minifi::RemoteProcessorGroupPort] [error] > ProcessGroup::refreshRemoteSite2SiteInfo -- curl_easy_perform() failed , > response code 0 > [2019-08-13 08:38:05.447] > [org::apache::nifi::minifi::RemoteProcessorGroupPort] [info] no protocol, > yielding > [2019-08-13 08:38:05.447] [org::apache::nifi::minifi::FlowController] [info] > Unload Flow Controller > [2019-08-13 08:38:05.448] [main] [info] MiNiFi exit -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-999) MiNiFI as a S2S server
[ https://issues.apache.org/jira/browse/MINIFICPP-999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-999. Resolution: Won't Fix > MiNiFI as a S2S server > -- > > Key: MINIFICPP-999 > URL: https://issues.apache.org/jira/browse/MINIFICPP-999 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Major > > As Nanofi was introduced and it's able to transfer via S2S, MiNiFi should be > able to act as a S2S server (RAW is enough) to receive data from Nanofi. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (MINIFICPP-996) Output port keeps printing info message implying transmission
[ https://issues.apache.org/jira/browse/MINIFICPP-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reopened MINIFICPP-996: > Output port keeps printing info message implying transmission > - > > Key: MINIFICPP-996 > URL: https://issues.apache.org/jira/browse/MINIFICPP-996 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > Here is an example of the issue. It seems that even though no data is being > transmitted we are going through a code path. [~aboda] did you see this? > 2019-08-02 15:51:43.164] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f3b2dad4-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:45.178] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f4e6260e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:47.189] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f618f57e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:49.211] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f74d8c52-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:51.227] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f8811d64-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:53.245] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f9b50b96-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-996) Output port keeps printing info message implying transmission
[ https://issues.apache.org/jira/browse/MINIFICPP-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-996. Resolution: Fixed > Output port keeps printing info message implying transmission > - > > Key: MINIFICPP-996 > URL: https://issues.apache.org/jira/browse/MINIFICPP-996 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > Here is an example of the issue. It seems that even though no data is being > transmitted we are going through a code path. [~aboda] did you see this? > 2019-08-02 15:51:43.164] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f3b2dad4-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:45.178] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f4e6260e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:47.189] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f618f57e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:49.211] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f74d8c52-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:51.227] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f8811d64-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:53.245] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f9b50b96-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-997) findProcessor should use UUID in addition to name
[ https://issues.apache.org/jira/browse/MINIFICPP-997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-997. Resolution: Done > findProcessor should use UUID in addition to name > - > > Key: MINIFICPP-997 > URL: https://issues.apache.org/jira/browse/MINIFICPP-997 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Assignee: Marc Parisi >Priority: Major > > *findProcessor in PG should search by UUID primarily, then name.* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-996) Output port keeps printing info message implying transmission
[ https://issues.apache.org/jira/browse/MINIFICPP-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-996: --- Priority: Minor (was: Major) > Output port keeps printing info message implying transmission > - > > Key: MINIFICPP-996 > URL: https://issues.apache.org/jira/browse/MINIFICPP-996 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Assignee: Arpad Boda >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > Here is an example of the issue. It seems that even though no data is being > transmitted we are going through a code path. [~aboda] did you see this? > 2019-08-02 15:51:43.164] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f3b2dad4-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:45.178] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f4e6260e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:47.189] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f618f57e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:49.211] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f74d8c52-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:51.227] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f8811d64-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:53.245] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f9b50b96-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINIFICPP-996) Output port keeps printing info message implying transmission
[ https://issues.apache.org/jira/browse/MINIFICPP-996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reassigned MINIFICPP-996: -- Assignee: (was: Arpad Boda) > Output port keeps printing info message implying transmission > - > > Key: MINIFICPP-996 > URL: https://issues.apache.org/jira/browse/MINIFICPP-996 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > Here is an example of the issue. It seems that even though no data is being > transmitted we are going through a code path. [~aboda] did you see this? > 2019-08-02 15:51:43.164] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f3b2dad4-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:45.178] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f4e6260e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:47.189] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f618f57e-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:49.211] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f74d8c52-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:51.227] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f8811d64-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes > [2019-08-02 15:51:53.245] > [org::apache::nifi::minifi::sitetosite::SiteToSiteClient] [info] Site to Site > transaction f9b50b96-b55e-11e9-9df5-74e5f944bfe7 received flow record 0, with > content size 0 bytes -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-995) OpenCV testing should be improved
[
https://issues.apache.org/jira/browse/MINIFICPP-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marton Szasz updated MINIFICPP-995:
---
Summary: OpenCV testing should be improved (was: Opencv testing should be
improved)
> OpenCV testing should be improved
> -
>
> Key: MINIFICPP-995
> URL: https://issues.apache.org/jira/browse/MINIFICPP-995
> Project: Apache NiFi MiNiFi C++
> Issue Type: Improvement
>Reporter: Arpad Boda
>Assignee: Nghia Le
>Priority: Minor
>
> As we proceed with opencv we will need to be able to verify motion-detection
> and face-detection for eg., which requires using captures, basically being
> able to stream video in our unit or integration tests.
> The current opencv tests seems to fail anyway, but it's not a big issue given
> it depends on an external source:
> {code}
> [2019-08-tracel 00:04:04.971]
> [org::apache::nifi::minifi::processors::CaptureRTSPFrame] [trace]
> CaptureRTSPFrame processor scheduled
> OpenCV: Couldn't read video stream from file "rtsp://:@170.93.143.139/abcd"
> [2019-08-errorl 00:04:04.972]
> [org::apache::nifi::minifi::processors::CaptureRTSPFrame] [error] Unable to
> open RTSP stream: OpenCV(4.1.0)
> /Users/aboda/work/shadow/PRs/nifi-minifi-cpp/build/extensions/opencv/thirdparty/opencv/opencv-external/src/opencv-external/modules/videoio/src/cap.cpp:206:
> error: (-215:Assertion failed) api != 0 in function 'getBackendName'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (MINIFICPP-995) OpenCV testing should be improved
[
https://issues.apache.org/jira/browse/MINIFICPP-995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Marton Szasz reassigned MINIFICPP-995:
--
Assignee: (was: Nghia Le)
> OpenCV testing should be improved
> -
>
> Key: MINIFICPP-995
> URL: https://issues.apache.org/jira/browse/MINIFICPP-995
> Project: Apache NiFi MiNiFi C++
> Issue Type: Improvement
>Reporter: Arpad Boda
>Priority: Minor
>
> As we proceed with opencv we will need to be able to verify motion-detection
> and face-detection for eg., which requires using captures, basically being
> able to stream video in our unit or integration tests.
> The current opencv tests seems to fail anyway, but it's not a big issue given
> it depends on an external source:
> {code}
> [2019-08-tracel 00:04:04.971]
> [org::apache::nifi::minifi::processors::CaptureRTSPFrame] [trace]
> CaptureRTSPFrame processor scheduled
> OpenCV: Couldn't read video stream from file "rtsp://:@170.93.143.139/abcd"
> [2019-08-errorl 00:04:04.972]
> [org::apache::nifi::minifi::processors::CaptureRTSPFrame] [error] Unable to
> open RTSP stream: OpenCV(4.1.0)
> /Users/aboda/work/shadow/PRs/nifi-minifi-cpp/build/extensions/opencv/thirdparty/opencv/opencv-external/src/opencv-external/modules/videoio/src/cap.cpp:206:
> error: (-215:Assertion failed) api != 0 in function 'getBackendName'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-993) Use JNI to leverage NiFi tests for V on MiNiFi components
[ https://issues.apache.org/jira/browse/MINIFICPP-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-993. Resolution: Not A Problem Incompatible processors, and we have test coverage now in minifi c++ > Use JNI to leverage NiFi tests for V on MiNiFi components > --- > > Key: MINIFICPP-993 > URL: https://issues.apache.org/jira/browse/MINIFICPP-993 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Major > > We should be able to use the JNI extension to test MiNiFi against NiFi tests > that already exist and are trusted -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-992) Move name of connection queue inside object
[ https://issues.apache.org/jira/browse/MINIFICPP-992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-992. Resolution: Fixed > Move name of connection queue inside object > --- > > Key: MINIFICPP-992 > URL: https://issues.apache.org/jira/browse/MINIFICPP-992 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Assignee: Marc Parisi >Priority: Major > > Use this as an opportunity to clean up FlowInformation.h too -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-991) Handling environment vars in MiNiFi
[ https://issues.apache.org/jira/browse/MINIFICPP-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-991. Resolution: Not A Problem > Handling environment vars in MiNiFi > > > Key: MINIFICPP-991 > URL: https://issues.apache.org/jira/browse/MINIFICPP-991 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Major > > As [~phrocker] pointed out in > [https://github.com/apache/nifi-minifi-cpp/pull/612] env var setting might > caused unintended behaviour in case multiple processors (for eg. a cpp and a > Python one) try to set and use the same env var, which is a valid case for > oepncv. > We should find a general approach of handling env vars: > * If we handle them in processor init phase, that's guaranteed to be thread > safe, but property values are not accessible in that phase, so configuration > is difficult > * Handling in onschedule phase allows access to properties, although we have > to deal with thread-safety. > * No matter what approach we choose, a recommended way of doing this should > be documented to avoid users experiencing unwanted behaviours. > [~le.nghia] [~bakaid] [~phrocker] please share your opinions! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-990) Segfault on SIGINT after shutdown initiated
[ https://issues.apache.org/jira/browse/MINIFICPP-990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-990. Resolution: Fixed > Segfault on SIGINT after shutdown initiated > > > Key: MINIFICPP-990 > URL: https://issues.apache.org/jira/browse/MINIFICPP-990 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Andrew Christianson >Priority: Major > > If I send a SIGINT (ctrl-c) to MiNiFI, MiNiFi begins shutdown. If I send > another SIGINT while that shutdown is in progress, MiNiFi crashes with a > segfault. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-988) Evaluate Allowable values for Kafka options
[ https://issues.apache.org/jira/browse/MINIFICPP-988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-988. Resolution: Fixed > Evaluate Allowable values for Kafka options > --- > > Key: MINIFICPP-988 > URL: https://issues.apache.org/jira/browse/MINIFICPP-988 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Assignee: Nghia Le >Priority: Minor > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINIFICPP-985) Implement listvalidators
[ https://issues.apache.org/jira/browse/MINIFICPP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reassigned MINIFICPP-985: -- Assignee: (was: Arpad Boda) > Implement listvalidators > > > Key: MINIFICPP-985 > URL: https://issues.apache.org/jira/browse/MINIFICPP-985 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Affects Versions: 0.6.0 >Reporter: Arpad Boda >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > As [~nghiaxlee] pointed out in a change we don't have the functionality to > create list validators (in which case all elements of the input lists should > be validated using an encapsulated validator), so we can't validate multiple > choice properties for eg. > The change itself is quite easy, although we should keep in mind C2 > integration. Because of this [~phrocker] and [~kdoran] I would like to ask > for your feedback on adding this into agent manifest. Thanks in advance! > I scoped this for 0.7.0 as the MiNiFi impact would be small, however I can > accept rescheduling it to 0.8.0 in case C2 integration requires more effort > and testing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-985) Implement listvalidators
[ https://issues.apache.org/jira/browse/MINIFICPP-985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-985: --- Priority: Minor (was: Major) > Implement listvalidators > > > Key: MINIFICPP-985 > URL: https://issues.apache.org/jira/browse/MINIFICPP-985 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Affects Versions: 0.6.0 >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Minor > Time Spent: 1h 20m > Remaining Estimate: 0h > > As [~nghiaxlee] pointed out in a change we don't have the functionality to > create list validators (in which case all elements of the input lists should > be validated using an encapsulated validator), so we can't validate multiple > choice properties for eg. > The change itself is quite easy, although we should keep in mind C2 > integration. Because of this [~phrocker] and [~kdoran] I would like to ask > for your feedback on adding this into agent manifest. Thanks in advance! > I scoped this for 0.7.0 as the MiNiFi impact would be small, however I can > accept rescheduling it to 0.8.0 in case C2 integration requires more effort > and testing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-983) Fix tail file test linter errors
[ https://issues.apache.org/jira/browse/MINIFICPP-983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-983. Resolution: Fixed > Fix tail file test linter errors > > > Key: MINIFICPP-983 > URL: https://issues.apache.org/jira/browse/MINIFICPP-983 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Assignee: Nghia Le >Priority: Minor > > Linter errors have been introduced into TailFileTest. These can easily be > fixed by using our supplied linter. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-982) Tailfile issues in process session across deployments
[ https://issues.apache.org/jira/browse/MINIFICPP-982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-982. Resolution: Incomplete not enough information > Tailfile issues in process session across deployments > - > > Key: MINIFICPP-982 > URL: https://issues.apache.org/jira/browse/MINIFICPP-982 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Assignee: Marc Parisi >Priority: Blocker > > Issues on ARM32 and windows deployments demonstrate that this commit may be > causing a fault...but could be subsequent commits, so will use this as a > watermark to iterate forward. Issue appears obvious but will add to the unit > tests to verify. > [https://github.com/apache/nifi-minifi-cpp/commit/a49fe09c12efee4ca9c5db37dc8aca80dbf7eafc#diff-65b0ebbe7ddaaeffa1cac839d4977f04] > > [~bakaid] I saw a deprecation in this commit. I'm going to add arguments for > that DEPRECATION that support when it was deprecated and the release when we > expect to remove it. I'll post the gist to this so we can synchronize on that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-981) Avoid maintaining our own Curl HTTP Client
[ https://issues.apache.org/jira/browse/MINIFICPP-981?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-981: --- Priority: Minor (was: Critical) > Avoid maintaining our own Curl HTTP Client > -- > > Key: MINIFICPP-981 > URL: https://issues.apache.org/jira/browse/MINIFICPP-981 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Minor > > [https://github.com/jpbarrette/curlpp] may be a better alternative. I use it > on a separate project and would have preferred starting with that. Some > stakeholders did not want us to use that library, but I think we should avoid > maintaining our own client and wasting cycles to fix bugs. While we can argue > that we "know what our bugs are" I don't think that we do and there are > likely many more. Through evolution curlpp has improved and I would not like > to incur that cost on our project. I would prefer to avoid maintaining curl > code and use a third party library. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-980) Make debian can no longe find bison
[ https://issues.apache.org/jira/browse/MINIFICPP-980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-980. Resolution: Won't Fix `make debian` is mostly abandoned. Normal build and package still works on debian, and `make centos` binaries work on debian. > Make debian can no longe find bison > --- > > Key: MINIFICPP-980 > URL: https://issues.apache.org/jira/browse/MINIFICPP-980 > Project: Apache NiFi MiNiFi C++ > Issue Type: Bug >Reporter: Marc Parisi >Assignee: Marc Parisi >Priority: Blocker > > Also must fix travis targets. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-978) Add ability to test JNI processors
[ https://issues.apache.org/jira/browse/MINIFICPP-978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-978: --- Priority: Minor (was: Major) > Add ability to test JNI processors > --- > > Key: MINIFICPP-978 > URL: https://issues.apache.org/jira/browse/MINIFICPP-978 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Minor > > JNI processors don't always work in docker tests. We need to figure out why > this is. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-979) Add Python processor tests to docker verify
[ https://issues.apache.org/jira/browse/MINIFICPP-979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-979. Resolution: Done > Add Python processor tests to docker verify > --- > > Key: MINIFICPP-979 > URL: https://issues.apache.org/jira/browse/MINIFICPP-979 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Major > > Need ability to test docker tests and provide ways for users to define > requirements. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-974) Ensure that non-docker tested processors are not included into the make packaged docker builds
[ https://issues.apache.org/jira/browse/MINIFICPP-974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-974. Resolution: Done > Ensure that non-docker tested processors are not included into the make > packaged docker builds > -- > > Key: MINIFICPP-974 > URL: https://issues.apache.org/jira/browse/MINIFICPP-974 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Marc Parisi >Priority: Major > > This ensures that we don't trust and deploy artifacts that don't have some > type of regression test framework as it relates to our SITs. There may be > exceptions, so we can feel this desire out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-975) Add file system capabilities to docker verify
[ https://issues.apache.org/jira/browse/MINIFICPP-975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-975: --- Priority: Minor (was: Major) > Add file system capabilities to docker verify > - > > Key: MINIFICPP-975 > URL: https://issues.apache.org/jira/browse/MINIFICPP-975 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Marc Parisi >Priority: Minor > > Add capabilities in docker tests to perform file system activities, such as > making a file system read only, removing repos, etc. May also be the case > where we want to perform tasks that would render file systems unusable, in > which case we want to see how agents respond and how they can report that. > Some of these are certainly possible with unit tests, but we can likely make > this simpler via containers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-973) Add docker tests for procesors that don't have them
[ https://issues.apache.org/jira/browse/MINIFICPP-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-973. Resolution: Done > Add docker tests for procesors that don't have them > --- > > Key: MINIFICPP-973 > URL: https://issues.apache.org/jira/browse/MINIFICPP-973 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Marc Parisi >Priority: Major > > Processors that don't have corresponding docker tests should not be deployed > in docker container targets for builds. As a result we should ensure those > that we wish to include into the end artifact are docker tested. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-972) Add C2 server stub to DockerVerify
[ https://issues.apache.org/jira/browse/MINIFICPP-972?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-972. Resolution: Done NiFi C2 service is used > Add C2 server stub to DockerVerify > -- > > Key: MINIFICPP-972 > URL: https://issues.apache.org/jira/browse/MINIFICPP-972 > Project: Apache NiFi MiNiFi C++ > Issue Type: New Feature >Reporter: Marc Parisi >Priority: Major > > Currently we have NiFi and MiNiFi deployed in containers. we should have a > stubbed out c2 server that provides many of the capabilities we support > through the protocol. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-970) Complete docker picture of deployments
[ https://issues.apache.org/jira/browse/MINIFICPP-970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-970. Resolution: Won't Fix Windows will be done separately. Linux tests are done outside docker. We're also testing docker alpine builds with musl libc. > Complete docker picture of deployments > -- > > Key: MINIFICPP-970 > URL: https://issues.apache.org/jira/browse/MINIFICPP-970 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Major > > Add target for docker-verify-all which will test all O/S variants we build, > running all tests, docker tests in addition to validating against musl with > these parameters. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-967) Improve SITs
[ https://issues.apache.org/jira/browse/MINIFICPP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-967: --- Priority: Minor (was: Blocker) > Improve SITs > > > Key: MINIFICPP-967 > URL: https://issues.apache.org/jira/browse/MINIFICPP-967 > Project: Apache NiFi MiNiFi C++ > Issue Type: Epic >Reporter: Marc Parisi >Assignee: Arpad Boda >Priority: Minor > > I'm using this ticket to collect various other tickets ( closed and open ) > for adding them to our docker test framework. > > In my opinion this is the highest need in 0.7.0 in 0.8.0 and 0.9.0. Bugs will > arise as a result of this; however, there have been a variety of tickets > created and closed across this and elsewhere – so let's gather them into a > single EPIC so we can all work on them together. > > docker-verify > We have several stages of testing as you have across any project: unit, > integration, and SIT ( system integration testing ). > > 1) V – Verify and validate interactions between internal and external > components > In many cases, we can create all appropriate BV, EC, and introspective > test cases in unit and integration tests, but there are many that we cannot > capture without integration with a C2 server, NiFi Instance, Kafka server, or > other type of server. We should not attempt to launch these services in unit > or integration tests. External services and requirements for comms should be > verified and validated in docker contianers. > 2) Regression Testing – we should use this for all releases and before > merging. This may mean adding a targets if necessary, but the important thing > is that we define expectations within this test framework ( and the DSL ) and > adhere to them. This may mean that we are testing for memory leaks. We can do > this in docker tests more easily than unit/integration tests. ASAN is a great > goal to have for upcoming releases and I think docker tests are where we can > build this functionality into so that we can test across versions of systems, > glibc, and musl. > > 3) We have many versions of software that we can build upon. While we can > mitigate factors with including our own version of system libs, this won't > solve all issues, and will not be something that all consumers want. So we > can mitigate these desires by using docker tests to splay across platforms > and build systems, executing docker tests. > > 4) Fuzzing. Fuzzing can and often should be done at every level, but we can > very easily define ways in the DSL to fuzz properties in processors. This > mechanism should allow us to better test boundary values and equivalence > classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-969) Create Property fuzzing capabilities
[ https://issues.apache.org/jira/browse/MINIFICPP-969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-969: --- Priority: Minor (was: Major) > Create Property fuzzing capabilities > > > Key: MINIFICPP-969 > URL: https://issues.apache.org/jira/browse/MINIFICPP-969 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Marc Parisi >Priority: Minor > > We should be able to fuzz processor properties within MiNiFi agents. This > should be done by either pulling all properties and fuzzing them ( we can > define patterns ) or fuzz specified properties. > For example, in ListenHTTP we have several options, we should support testing > valid and invalid endpoints, invalid operations for security, etc. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (MINIFICPP-967) Improve SITs
[ https://issues.apache.org/jira/browse/MINIFICPP-967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz reassigned MINIFICPP-967: -- Assignee: (was: Arpad Boda) > Improve SITs > > > Key: MINIFICPP-967 > URL: https://issues.apache.org/jira/browse/MINIFICPP-967 > Project: Apache NiFi MiNiFi C++ > Issue Type: Epic >Reporter: Marc Parisi >Priority: Minor > > I'm using this ticket to collect various other tickets ( closed and open ) > for adding them to our docker test framework. > > In my opinion this is the highest need in 0.7.0 in 0.8.0 and 0.9.0. Bugs will > arise as a result of this; however, there have been a variety of tickets > created and closed across this and elsewhere – so let's gather them into a > single EPIC so we can all work on them together. > > docker-verify > We have several stages of testing as you have across any project: unit, > integration, and SIT ( system integration testing ). > > 1) V – Verify and validate interactions between internal and external > components > In many cases, we can create all appropriate BV, EC, and introspective > test cases in unit and integration tests, but there are many that we cannot > capture without integration with a C2 server, NiFi Instance, Kafka server, or > other type of server. We should not attempt to launch these services in unit > or integration tests. External services and requirements for comms should be > verified and validated in docker contianers. > 2) Regression Testing – we should use this for all releases and before > merging. This may mean adding a targets if necessary, but the important thing > is that we define expectations within this test framework ( and the DSL ) and > adhere to them. This may mean that we are testing for memory leaks. We can do > this in docker tests more easily than unit/integration tests. ASAN is a great > goal to have for upcoming releases and I think docker tests are where we can > build this functionality into so that we can test across versions of systems, > glibc, and musl. > > 3) We have many versions of software that we can build upon. While we can > mitigate factors with including our own version of system libs, this won't > solve all issues, and will not be something that all consumers want. So we > can mitigate these desires by using docker tests to splay across platforms > and build systems, executing docker tests. > > 4) Fuzzing. Fuzzing can and often should be done at every level, but we can > very easily define ways in the DSL to fuzz properties in processors. This > mechanism should allow us to better test boundary values and equivalence > classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-958) Visibilities (and contracts) of processors should be fixed
[ https://issues.apache.org/jira/browse/MINIFICPP-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-958. Resolution: Won't Fix 1: not a problem 2: will be done gradually, as we're changing parts of the code > Visibilities (and contracts) of processors should be fixed > -- > > Key: MINIFICPP-958 > URL: https://issues.apache.org/jira/browse/MINIFICPP-958 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Affects Versions: 0.6.0 >Reporter: Arpad Boda >Assignee: Arpad Boda >Priority: Major > Fix For: 1.0.0 > > > * Properties and relationships shouldn't be public. Validation should be done > via the data populated by the processor during init phase. > * Other data members, such as callbacks, non-vritual functions should be > hidden as well -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-956) Support compiling and linking our own libc++ and depend on libc only as a dynamic dependency.
[ https://issues.apache.org/jira/browse/MINIFICPP-956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-956. Resolution: Won't Fix Compatibility with older linux can be achieved with redhat devtoolset on centos > Support compiling and linking our own libc++ and depend on libc only as a > dynamic dependency. > - > > Key: MINIFICPP-956 > URL: https://issues.apache.org/jira/browse/MINIFICPP-956 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Dániel Bakai >Priority: Major > > * It would enable us to use C++14/C++17 on all platforms without losing > compatibility with older Linux systems -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-955) Move from the “compiles everywhere with all versions and sources of third-party dependencies” to “compiles everywhere with the third-party dependencies shipped by us”
[ https://issues.apache.org/jira/browse/MINIFICPP-955?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-955. Resolution: Won't Fix We have largely moved over to bundled third party libs, but it would make sense to add/keep the ability to optionally use system libs, to speed up build. > Move from the “compiles everywhere with all versions and sources of > third-party dependencies” to “compiles everywhere with the third-party > dependencies shipped by us” > -- > > Key: MINIFICPP-955 > URL: https://issues.apache.org/jira/browse/MINIFICPP-955 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Dániel Bakai >Priority: Major > > * Supporting both bundled and system versions is extra work and error-prone > * Because we don’t test all combinations of bundled and system dependencies > it is easy to introduce errors into untested combinations > * Having specific versions of third-party dependencies affords us greater > control and is more secure (both because we can update to fixed versions or > add security patches and because there is no chance of an API-incompatibility > causing unexpected behaviour) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (MINIFICPP-954) Consider moving the C2 line protocol to Google Protobuf
[ https://issues.apache.org/jira/browse/MINIFICPP-954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz resolved MINIFICPP-954. Resolution: Won't Fix We have consolidated on HTTP. > Consider moving the C2 line protocol to Google Protobuf > --- > > Key: MINIFICPP-954 > URL: https://issues.apache.org/jira/browse/MINIFICPP-954 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Dániel Bakai >Priority: Major > > * Very compact serialized format > * Easy protocol description > * Support for generating parsers for many languages from the proto file > * Has good versioning support > * Thoroughly tested, fuzzed > * Less chance of introducing security vulnerabilities with hand-written > parsers -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (MINIFICPP-951) Separate Streams and serialization
[ https://issues.apache.org/jira/browse/MINIFICPP-951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marton Szasz updated MINIFICPP-951: --- Priority: Minor (was: Major) > Separate Streams and serialization > -- > > Key: MINIFICPP-951 > URL: https://issues.apache.org/jira/browse/MINIFICPP-951 > Project: Apache NiFi MiNiFi C++ > Issue Type: Improvement >Reporter: Dániel Bakai >Priority: Minor > > Current stream implementations include serialization code for a couple of > data types. That should be handled separately. -- This message was sent by Atlassian Jira (v8.20.10#820010)
