[jira] [Commented] (NIFI-13328) WindowsEventLogReader should parse RenderingInfo
[
https://issues.apache.org/jira/browse/NIFI-13328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851869#comment-17851869
]
Sean Hunter commented on NIFI-13328:
I think I'd be alright with closing mine if we could get this JIRA knocked out.
Now I'm wondering how MiNiFi C++ handles this...
> WindowsEventLogReader should parse RenderingInfo
>
>
> Key: NIFI-13328
> URL: https://issues.apache.org/jira/browse/NIFI-13328
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
>Affects Versions: 1.24.0
> Environment: Docker
>Reporter: Stephen Jeffrey Hindmarch
>Priority: Major
>
> If windows events are extracted from the windows event collector they will
> include a "RenderingInfo" tag. However, this tag is not expected by the
> WindowsEventLogReader and will throw an error and pass the flow file into the
> failure relationship if the event contains the tag. This tag should be
> supported as it is a legitimate part of the Windows Event XML schema.
> See
> [https://learn.microsoft.com/en-us/windows/win32/wes/eventschema-renderingtype-complextype]
> and
> [https://learn.microsoft.com/en-us/windows/win32/wec/windows-event-collector]
> . In this particular use case, events are being collected from field
> technicians' laptops to perform a cybersecurity audit after they have
> plugging their laptops into customer networks.
> When these events are processed through a WindowsEventLogReader, the reader
> throws the following error.
> {noformat}
> ConvertRecord[id=7b99392f-2b54-139e-8791-349e930904cd] Failed to process
> FlowFile[filename=ffca2ea2-edd5-4ad1-8380-2bc4c8dae1ac]; will route to
> failure: org.apache.nifi.processor.exception.ProcessException: Could not
> parse incoming data
> - Caused by: org.apache.nifi.serialization.MalformedRecordException: Error
> reading records to determine the FlowFile's RecordSchema
> - Caused by: javax.xml.stream.XMLStreamException: Expecting tag but
> found unknown/invalid tag RenderingInfo{noformat}
> An example of the event record might be
> {noformat}
> https://schemas.microsoft.com/win/2004/08/events/event;>
>
> Guid="{555908d1-a6d7-4695-8e1e-26931d2012f4}" EventSourceName="Service
> Control Manager"/>
> 7036
> 0
> 4
> 0
> 0
> 0x8080
>
> 34153
>
>
> System
> WIN-O05CNUCF16M.hdf.local
>
>
>
> Smart Card Device Enumeration Service
> param2
>
> 5300630044006500760069006300650045006E0075006D002F003400
>
>
> This is a message
>
> {noformat}
> Removing the tag allows the event to be processed as normal.
> One possible workaround is to use a ReplaceText processor to remove the tag
> before reading, but this then involves either discarding the tag contents, or
> using an enrichment fork to find some other way of processing it. Another
> workaround is to use the XMLReader service, but this is a generic parser and
> has a its own problems.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13337) Column sizes when listing flowfiles in queue
[ https://issues.apache.org/jira/browse/NIFI-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan updated NIFI-13337: --- Resolution: Fixed Status: Resolved (was: Patch Available) > Column sizes when listing flowfiles in queue > > > Key: NIFI-13337 > URL: https://issues.apache.org/jira/browse/NIFI-13337 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2024-06-02 at 13.59.28.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > !Screenshot 2024-06-02 at 13.59.28.png|width=964,height=224! > It seems like columns cannot be resized. If that's correct, I believe the > defaults could be a bit better. In particular the columns 'Position' and > 'UUID' seem overly large (although we know the maximum size), while the > column 'Filename' could be larger. > As a side note, there is now one more click to get to flow file content, > details, provenance, etc, as we now have to click to get a menu instead of > having icons. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13337) Column sizes when listing flowfiles in queue
[ https://issues.apache.org/jira/browse/NIFI-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851856#comment-17851856 ] ASF subversion and git services commented on NIFI-13337: Commit e142341ceb46d2d7a0b6e91bffeff0630f5ee91b in nifi's branch refs/heads/main from Matt Gilman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=e142341ceb ] NIFI-13337: (#8915) - Adjust column widths of the queue listing table. > Column sizes when listing flowfiles in queue > > > Key: NIFI-13337 > URL: https://issues.apache.org/jira/browse/NIFI-13337 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2024-06-02 at 13.59.28.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > !Screenshot 2024-06-02 at 13.59.28.png|width=964,height=224! > It seems like columns cannot be resized. If that's correct, I believe the > defaults could be a bit better. In particular the columns 'Position' and > 'UUID' seem overly large (although we know the maximum size), while the > column 'Filename' could be larger. > As a side note, there is now one more click to get to flow file content, > details, provenance, etc, as we now have to click to get a menu instead of > having icons. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13337: Adjust column widths of the queue listing table [nifi]
scottyaslan merged PR #8915: URL: https://github.com/apache/nifi/pull/8915 -- 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-13337) Column sizes when listing flowfiles in queue
[ https://issues.apache.org/jira/browse/NIFI-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851855#comment-17851855 ] Scott Aslan commented on NIFI-13337: [~pvillard] Thank you for your feedback regarding the additional click required to access flow file content, details, provenance, and other information due to the new UX. Several important factors influenced this update: Firstly, in many cases, the table listings in NiFi display numerous columns, and as you noted, the widths are not resizable. This, combined with the density of information in these listings, made it challenging for users to navigate and comprehend. Previously, actions were spread across the 'actions' and 'moreDetails' columns, making it difficult for users to find the action they were looking for and the inconsistency in which icons were sometimes clickable or not and the inconsistent use of color for communicating state further complicated the user experience especially for accessible users. To address these issues, the 'more details' and 'actions' columns widths have been reduced to maximize space for other important information in other columns. Now, all actions are available via a single menu, ensuring every option is consistently discoverable. Color as a status indicator has been removed from the options in the menus and tooltips are only present on the icons in the 'moreDetails' column at the beginning of the row, aiding users in quickly viewing relevant details. This change not only improves accessibility but also enhances the overall user experience by increasing the readability of table contents and centralizing all actions. While there is an additional click in some cases, this trade-off results in a more intuitive and user-friendly interface. I hope this clarifies some of the reasoning behind these UX changes. Please feel free to share any further suggestions or feedback. > Column sizes when listing flowfiles in queue > > > Key: NIFI-13337 > URL: https://issues.apache.org/jira/browse/NIFI-13337 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2024-06-02 at 13.59.28.png > > Time Spent: 20m > Remaining Estimate: 0h > > !Screenshot 2024-06-02 at 13.59.28.png|width=964,height=224! > It seems like columns cannot be resized. If that's correct, I believe the > defaults could be a bit better. In particular the columns 'Position' and > 'UUID' seem overly large (although we know the maximum size), while the > column 'Filename' could be larger. > As a side note, there is now one more click to get to flow file content, > details, provenance, etc, as we now have to click to get a menu instead of > having icons. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13077) On-demand Extension Provider
[
https://issues.apache.org/jira/browse/NIFI-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851852#comment-17851852
]
James Guzman (Medel) commented on NIFI-13077:
-
Thanks [~pvillard] for sharing this Jira ticket in the NIFI-13301 ticket. Yes
many great benefits to having an On-Demand Extension Provider. One of the
benefits that caught my attention as I was reading your description was the
ability to create smaller versions of Apache NIFi. Both when building NiFi and
MiNiFi CPP from source, I have faced multiple times where the build failed
because of some external libraries that failed to download or failed to build
successfully, which caused the NiFi or MiNiFi CPP to fail building. As I start
working on NIFI-13301. I will keep your NIFI-13077 in mind too. I really your
extra input on this area. I was talking about this area with [~bbende] and
[~joewitt] . We'll most likely need to break this feature into multiple sub
tasks.
> On-demand Extension Provider
>
>
> Key: NIFI-13077
> URL: https://issues.apache.org/jira/browse/NIFI-13077
> Project: Apache NiFi
> Issue Type: Epic
> Components: Core Framework
>Reporter: Pierre Villard
>Priority: Major
>
> We currently have the concept of *ExternalResourceProvider* with two
> implementations (HDFS and NiFi Registry) that can be configured to list and
> download all NARs made available in those locations. Those implementations,
> if configured, would get started when NiFi starts and would download ALL of
> the available NARs, plus a background thread would check every five minutes
> for new NARs to be available and downloaded.
> The proposal here is to have a similar concept that would focus on extensions
> / components but instead of having a background thread and instead of having
> all of the components downloaded, the approach would be to plug this into the
> *ExtensionBuilder* and when a component cannot be instantiated (when loading
> a flow definition) with locally available components, then, instead of
> creating a ghost component, the Extension Providers would be queried with
> specific coordinates and if the provider makes the component available, then
> the NAR would be downloaded (alongside required dependencies if the NAR
> depends on another NAR).
> This approach already exists in the *Kafka Connect NiFi plugin* with the
> class {*}ExtensionClientDefinition{*}. By adopting this approach in NiFi,
> it’d be much easier to ship a much *smaller version of NiFi* and have NiFi
> download the required components based on flows that are being instantiated /
> deployed.
> The operation of downloading the NAR would not be blocking, meaning that we
> would still create a ghost component but after completion of the NAR(s)
> download and the loading of the components, the flows would be fully
> operational.
> It might be possible to show something similar as for the Python extensions
> where we show that the component is still in the process of downloading third
> party dependencies.
> While this is a great opportunity to reduce the size of the NiFi binary (and
> associated container image), it would not be great from a user perspective
> when designing flows because all of the NARs removed from the default image
> would no longer be visible in the list of available components when adding,
> for example, a processor to the canvas.
> Longer term we could imagine that the extension providers can also implement
> a listing API so that when showing the list of available components, we would
> show the list of the components available locally as well as the components
> available through the extensions providers. The listing of components could
> add another column to indicate the source of the component.
> This is something that is exposed for the Extension Bundles in the NiFi
> Registry (we also have the information about the NiFi API version that has
> been used for building the components so we could use this information to
> only list components that should be compatible from an API standpoint - same
> major version but lower or equal API version).
> The immediate goal though would be to introduce the concept of
> ExtensionProvider with the following APIs:
> {code:java}
> boolean isAvailableExtension(Coordinates)
> void downloadExtension(Coordinates)
> {code}
> Longer term we could also consider something like:
> {code:java}
> List listExtensions(){code}
> But we would need to figure out how a NAR can provide the information about
> the components that are inside of it. The NiFi Registry provides this
> information, but that would not be the case for a Maven based implementation
> for example.
> In nifi.properties we would have something looking like:
> {code:java}
> nifi.nar.extension.provider..{code}
> And we would
[jira] [Updated] (NIFI-13077) On-demand Extension Provider
[
https://issues.apache.org/jira/browse/NIFI-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Guzman (Medel) updated NIFI-13077:
Description:
We currently have the concept of *ExternalResourceProvider* with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
*ExtensionBuilder* and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded (alongside required dependencies if the NAR depends on
another NAR).
This approach already exists in the *Kafka Connect NiFi plugin* with the class
{*}ExtensionClientDefinition{*}. By adopting this approach in NiFi, it’d be
much easier to ship a much *smaller version of NiFi* and have NiFi download the
required components based on flows that are being instantiated / deployed.
The operation of downloading the NAR would not be blocking, meaning that we
would still create a ghost component but after completion of the NAR(s)
download and the loading of the components, the flows would be fully
operational.
It might be possible to show something similar as for the Python extensions
where we show that the component is still in the process of downloading third
party dependencies.
While this is a great opportunity to reduce the size of the NiFi binary (and
associated container image), it would not be great from a user perspective when
designing flows because all of the NARs removed from the default image would no
longer be visible in the list of available components when adding, for example,
a processor to the canvas.
Longer term we could imagine that the extension providers can also implement a
listing API so that when showing the list of available components, we would
show the list of the components available locally as well as the components
available through the extensions providers. The listing of components could add
another column to indicate the source of the component.
This is something that is exposed for the Extension Bundles in the NiFi
Registry (we also have the information about the NiFi API version that has been
used for building the components so we could use this information to only list
components that should be compatible from an API standpoint - same major
version but lower or equal API version).
The immediate goal though would be to introduce the concept of
ExtensionProvider with the following APIs:
{code:java}
boolean isAvailableExtension(Coordinates)
void downloadExtension(Coordinates)
{code}
Longer term we could also consider something like:
{code:java}
List listExtensions(){code}
But we would need to figure out how a NAR can provide the information about the
components that are inside of it. The NiFi Registry provides this information,
but that would not be the case for a Maven based implementation for example.
In nifi.properties we would have something looking like:
{code:java}
nifi.nar.extension.provider..{code}
And we would loop through all the configured providers to find the appropriate
NAR to download based on provided coordinates in the flow definition that is
being instantiated (either from flow.json.gz, or an uploaded JSON flow
definition, or when checking out a flow from a registry client).
was:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
[jira] [Updated] (NIFI-13077) On-demand Extension Provider
[
https://issues.apache.org/jira/browse/NIFI-13077?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Guzman (Medel) updated NIFI-13077:
Description:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be downloaded (alongside required dependencies if the NAR depends on
another NAR).
This approach already exists in the Kafka Connect NiFi plugin with the class
{*}ExtensionClientDefinition{*}. By adopting this approach in NiFi, it’d be
much easier to ship a much smaller version of NiFi and have NiFi download the
required components based on flows that are being instantiated / deployed.
The operation of downloading the NAR would not be blocking, meaning that we
would still create a ghost component but after completion of the NAR(s)
download and the loading of the components, the flows would be fully
operational.
It might be possible to show something similar as for the Python extensions
where we show that the component is still in the process of downloading third
party dependencies.
While this is a great opportunity to reduce the size of the NiFi binary (and
associated container image), it would not be great from a user perspective when
designing flows because all of the NARs removed from the default image would no
longer be visible in the list of available components when adding, for example,
a processor to the canvas.
Longer term we could imagine that the extension providers can also implement a
listing API so that when showing the list of available components, we would
show the list of the components available locally as well as the components
available through the extensions providers. The listing of components could add
another column to indicate the source of the component.
This is something that is exposed for the Extension Bundles in the NiFi
Registry (we also have the information about the NiFi API version that has been
used for building the components so we could use this information to only list
components that should be compatible from an API standpoint - same major
version but lower or equal API version).
The immediate goal though would be to introduce the concept of
ExtensionProvider with the following APIs:
{code:java}
boolean isAvailableExtension(Coordinates)
void downloadExtension(Coordinates)
{code}
Longer term we could also consider something like:
{code:java}
List listExtensions(){code}
But we would need to figure out how a NAR can provide the information about the
components that are inside of it. The NiFi Registry provides this information,
but that would not be the case for a Maven based implementation for example.
In nifi.properties we would have something looking like:
{code:java}
nifi.nar.extension.provider..{code}
And we would loop through all the configured providers to find the appropriate
NAR to download based on provided coordinates in the flow definition that is
being instantiated (either from flow.json.gz, or an uploaded JSON flow
definition, or when checking out a flow from a registry client).
was:
We currently have the concept of ExternalResourceProvider with two
implementations (HDFS and NiFi Registry) that can be configured to list and
download all NARs made available in those locations. Those implementations, if
configured, would get started when NiFi starts and would download ALL of the
available NARs, plus a background thread would check every five minutes for new
NARs to be available and downloaded.
The proposal here is to have a similar concept that would focus on extensions /
components but instead of having a background thread and instead of having all
of the components downloaded, the approach would be to plug this into the
ExtensionBuilder and when a component cannot be instantiated (when loading a
flow definition) with locally available components, then, instead of creating a
ghost component, the Extension Providers would be queried with specific
coordinates and if the provider makes the component available, then the NAR
would be
[jira] [Updated] (NIFI-13355) View details for cluster and flow configuration history tables should be in kebab action menu
[ https://issues.apache.org/jira/browse/NIFI-13355?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan updated NIFI-13355: --- Status: Patch Available (was: In Progress) > View details for cluster and flow configuration history tables should be in > kebab action menu > - > > Key: NIFI-13355 > URL: https://issues.apache.org/jira/browse/NIFI-13355 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Scott Aslan >Assignee: Scott Aslan >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] [NIFI-13355] move view cluster details and view flow configuration de… [nifi]
scottyaslan opened a new pull request, #8921: URL: https://github.com/apache/nifi/pull/8921 …tails into action kebab menus -- 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-13355) View details for cluster and flow configuration history tables should be in kebab action menu
Scott Aslan created NIFI-13355: -- Summary: View details for cluster and flow configuration history tables should be in kebab action menu Key: NIFI-13355 URL: https://issues.apache.org/jira/browse/NIFI-13355 Project: Apache NiFi Issue Type: Sub-task Reporter: Scott Aslan Assignee: Scott Aslan -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13353) anchor tags (links) on dark surfaces in dark mode are too dark
[ https://issues.apache.org/jira/browse/NIFI-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan updated NIFI-13353: --- Status: Patch Available (was: In Progress) > anchor tags (links) on dark surfaces in dark mode are too dark > -- > > Key: NIFI-13353 > URL: https://issues.apache.org/jira/browse/NIFI-13353 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Scott Aslan >Assignee: Scott Aslan >Priority: Major > Attachments: image-2024-06-03-17-06-55-325.png > > Time Spent: 10m > Remaining Estimate: 0h > > !image-2024-06-03-17-06-55-325.png|width=483,height=212! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13337: Adjust column widths of the queue listing table [nifi]
scottyaslan commented on PR #8915: URL: https://github.com/apache/nifi/pull/8915#issuecomment-2146276023 Reviewing... -- 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
[PR] NIFI-13351 Enhance QueryDatabaseTable/Record to not call session.putAttribute multiple times [nifi]
jrsteinebrey opened a new pull request, #8919: URL: https://github.com/apache/nifi/pull/8919 NIFI-13351 Enhance QueryDatabaseTable and QueryDatabaseTableRecord processors not to call session.putAttribute multiple times # Summary [NIFI-13351](https://issues.apache.org/jira/browse/NIFI-13351) # 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-13351) issue created ### Pull Request Tracking - [X] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-13351` - [X] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-13351` ### 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 I checked that existing unit tests exercised the new code and existing tests provided good coverage. I also run the new code in the NiFi and tested the processor and looked at flow files and confirmed that the attributes written by the new code really appeared in the output flow files. ### Build - [X] Build completed using `mvn clean install -P contrib-check` - [X] JDK 21 ### UI Contributions No UI changes ### Licensing No new files or dependencies ### Documentation No documentation changes needed. -- 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-13349) Align angular material and tailwind typography font-sizes
[ https://issues.apache.org/jira/browse/NIFI-13349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan updated NIFI-13349: --- Status: Patch Available (was: In Progress) > Align angular material and tailwind typography font-sizes > - > > Key: NIFI-13349 > URL: https://issues.apache.org/jira/browse/NIFI-13349 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Scott Aslan >Assignee: Scott Aslan >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13288) Fix SplitXml, and SplitAvro processors not to call session.putAttribute multiple times
[ https://issues.apache.org/jira/browse/NIFI-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Stieglitz updated NIFI-13288: Status: Patch Available (was: In Progress) > Fix SplitXml, and SplitAvro processors not to call session.putAttribute > multiple times > -- > > Key: NIFI-13288 > URL: https://issues.apache.org/jira/browse/NIFI-13288 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Assignee: Daniel Stieglitz >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Per [~markap14] in the following > [post|https://lists.apache.org/thread/7zo2px31r3377c7vhby4h6nrngdf3llf] one > should avoid calling session.putAttribute many times since in order to > maintain object immutability it has to create a new FlowFile object (and a > new HashMap of all attributes!) > for every call to session.putAttribute which leads to potentially a huge > amount of garbage getting created. Some of the split processors SplitXml and > SplitAvro all have loops to create a new flow file for each split and it > calls session.putAttribute more than once (in order to populate the split > attributes FRAGMENT_ID, FRAGMENT_INDEX etc) for each flow file created. Per > Mark's advice, these should be fixed to to populate the attributes in a Map > and then make one call to session.putAllAttributes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-13288 Fixed the SplitXml and SplitAvro processors not to call session.putAttribute multiple times. [nifi]
dan-s1 opened a new pull request, #8917: URL: https://github.com/apache/nifi/pull/8917 # Summary [NIFI-13288](https://issues.apache.org/jira/browse/NIFI-13288) # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [ ] Pull Request based on current revision of the `main` branch - [ ] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 21 ### UI Contributions - [ ] NiFi is modernizing its UI. Any contributions that update the [current UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui) also need to be implemented in the [new UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi). ### 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 - [ ] 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] [Updated] (NIFI-13310) Fix duplicate rat plugin declaration in jolt transform module
[ https://issues.apache.org/jira/browse/NIFI-13310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-13310: Status: Patch Available (was: Open) > Fix duplicate rat plugin declaration in jolt transform module > - > > Key: NIFI-13310 > URL: https://issues.apache.org/jira/browse/NIFI-13310 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > > [WARNING] > [WARNING] Some problems were encountered while building the effective model > for org.apache.nifi:nifi-jolt-transform-json-ui:war:2.0.0-SNAPSHOT > [WARNING] 'build.plugins.plugin.(groupId:artifactId)' must be unique but > found duplicate declaration of plugin org.apache.rat:apache-rat-plugin @ line > 209, column 21 > [WARNING] > [WARNING] It is highly recommended to fix these problems because they > threaten the stability of your build. > [WARNING] > [WARNING] For this reason, future Maven versions might no longer support > building such malformed projects. > [WARNING] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-13310 merged RAT declarations [nifi]
joewitt opened a new pull request, #8916: URL: https://github.com/apache/nifi/pull/8916 # Summary [NIFI-13310](https://issues.apache.org/jira/browse/NIFI-13310) # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [ ] Pull Request based on current revision of the `main` branch - [ ] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 21 ### UI Contributions - [ ] NiFi is modernizing its UI. Any contributions that update the [current UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui) also need to be implemented in the [new UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi). ### 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 - [ ] 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] [Updated] (NIFI-13352) Intermittent Failures in ListenOTLPTest
[
https://issues.apache.org/jira/browse/NIFI-13352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-13352:
Fix Version/s: 2.0.0-M4
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Intermittent Failures in ListenOTLPTest
> ---
>
> Key: NIFI-13352
> URL: https://issues.apache.org/jira/browse/NIFI-13352
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M3
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Fix For: 2.0.0-M4
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The {{ListenOTLPTest}} throws failures intermittently when running on GitHub
> Actions, related to socket connection issues.
> {noformat}
> Error: Tests run: 11, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 4.199 s <<< FAILURE! -- in
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest
> Error:
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed
> -- Time elapsed: 0.054 s <<< ERROR!
> org.apache.nifi.web.client.api.WebClientServiceException: Request execution
> failed HTTP Method [GET] URI [https://localhost:65351/v1/logs]
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:273)
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.retrieve(StandardWebClientService.java:258)
> at
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed(ListenOTLPTest.java:225)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: java.net.ConnectException: Failed to connect to
> localhost/[0:0:0:0:0:0:0:1]:65351
> at
> okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
> at
> okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
> at
> okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> at
> okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> at
> okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> at
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
> at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:271)
> ... 5 more
> Suppressed: java.net.SocketException: An established connection was
> aborted by the software in your host machine
> at java.base/sun.nio.ch.SocketDispatcher.read0(Native Method)
> at
> java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:46)
> at
> java.base/sun.nio.ch.NioSocketImpl.tryRead(NioSocketImpl.java:262)
> at
> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:313)
> at
> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:352)
> at
> java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
> at
> java.base/java.net.Socket$SocketInputStream.read(Socket.java:)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1461)
> at
>
[jira] [Commented] (NIFI-13352) Intermittent Failures in ListenOTLPTest
[
https://issues.apache.org/jira/browse/NIFI-13352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851837#comment-17851837
]
ASF subversion and git services commented on NIFI-13352:
Commit ab2cea4c229f71ff9c967cb36e70328b3027fa57 in nifi's branch
refs/heads/main from David Handermann
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=ab2cea4c22 ]
NIFI-13352 Adjusted Shutdown handling in ListenOTLP and Test Class
This closes #8913
- Added quick duration for shutdown quiet period in ListenOTLP HttpServerFactory
- Added TestRunner.stop() to ListenOTLPTest to close listening sockets
- Increased Connect Timeout from 5 to 10 seconds in ListenOTLPTest
Signed-off-by: Joseph Witt
> Intermittent Failures in ListenOTLPTest
> ---
>
> Key: NIFI-13352
> URL: https://issues.apache.org/jira/browse/NIFI-13352
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M3
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The {{ListenOTLPTest}} throws failures intermittently when running on GitHub
> Actions, related to socket connection issues.
> {noformat}
> Error: Tests run: 11, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 4.199 s <<< FAILURE! -- in
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest
> Error:
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed
> -- Time elapsed: 0.054 s <<< ERROR!
> org.apache.nifi.web.client.api.WebClientServiceException: Request execution
> failed HTTP Method [GET] URI [https://localhost:65351/v1/logs]
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:273)
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.retrieve(StandardWebClientService.java:258)
> at
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed(ListenOTLPTest.java:225)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: java.net.ConnectException: Failed to connect to
> localhost/[0:0:0:0:0:0:0:1]:65351
> at
> okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
> at
> okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
> at
> okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> at
> okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> at
> okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> at
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
> at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:271)
> ... 5 more
> Suppressed: java.net.SocketException: An established connection was
> aborted by the software in your host machine
> at java.base/sun.nio.ch.SocketDispatcher.read0(Native Method)
> at
> java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:46)
> at
> java.base/sun.nio.ch.NioSocketImpl.tryRead(NioSocketImpl.java:262)
> at
> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:313)
> at
> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:352)
> at
> java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
> at
> java.base/java.net.Socket$SocketInputStream.read(Socket.java:)
> at
>
Re: [PR] NIFI-13352 Adjust Shutdown handling in ListenOTLP and Test Class [nifi]
asfgit closed pull request #8913: NIFI-13352 Adjust Shutdown handling in ListenOTLP and Test Class URL: https://github.com/apache/nifi/pull/8913 -- 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-13337) Column sizes when listing flowfiles in queue
[ https://issues.apache.org/jira/browse/NIFI-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman updated NIFI-13337: --- Status: Patch Available (was: In Progress) > Column sizes when listing flowfiles in queue > > > Key: NIFI-13337 > URL: https://issues.apache.org/jira/browse/NIFI-13337 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2024-06-02 at 13.59.28.png > > Time Spent: 10m > Remaining Estimate: 0h > > !Screenshot 2024-06-02 at 13.59.28.png|width=964,height=224! > It seems like columns cannot be resized. If that's correct, I believe the > defaults could be a bit better. In particular the columns 'Position' and > 'UUID' seem overly large (although we know the maximum size), while the > column 'Filename' could be larger. > As a side note, there is now one more click to get to flow file content, > details, provenance, etc, as we now have to click to get a menu instead of > having icons. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-13337: Adjust column widths of the queue listing table [nifi]
mcgilman opened a new pull request, #8915: URL: https://github.com/apache/nifi/pull/8915 NIFI-13337: - Adjust column widths of the queue listing table. -- 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-13354) Prepare frontend codebase for co-location with out UIs
Matt Gilman created NIFI-13354: -- Summary: Prepare frontend codebase for co-location with out UIs Key: NIFI-13354 URL: https://issues.apache.org/jira/browse/NIFI-13354 Project: Apache NiFi Issue Type: Sub-task Components: Core UI Reporter: Matt Gilman NiFi is comprised of numerous UIs. These UIs exist within different maven modules because of they live in different parts of the codebase and they are packaged in different NARs. This is makes it difficult to reuse shared components, styles, dependencies, etc. This Jira is tracking the migration of the recently rewritten NiFi UI to a top level maven module. This will establish a place where subsequent UIs (custom UIs, documentation, data viewers, etc) can be added. Once all the UIs have been updated, we will be left with a single maven module that produces a single artifact of all built UIs. The existing WARs which currently package the UIs will be responsible for unpacking the front end artifact and copying the applications into the WAR staging directory. In the end, we'll have a single place for all UIs to be colocated where they can easily share reusable components and styles. Further it will be a single place for front end dependencies to be managed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-13337) Column sizes when listing flowfiles in queue
[ https://issues.apache.org/jira/browse/NIFI-13337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman reassigned NIFI-13337: -- Assignee: Matt Gilman > Column sizes when listing flowfiles in queue > > > Key: NIFI-13337 > URL: https://issues.apache.org/jira/browse/NIFI-13337 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2024-06-02 at 13.59.28.png > > > !Screenshot 2024-06-02 at 13.59.28.png|width=964,height=224! > It seems like columns cannot be resized. If that's correct, I believe the > defaults could be a bit better. In particular the columns 'Position' and > 'UUID' seem overly large (although we know the maximum size), while the > column 'Filename' could be larger. > As a side note, there is now one more click to get to flow file content, > details, provenance, etc, as we now have to click to get a menu instead of > having icons. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (NIFI-12661) Flow Analysis report menu
[ https://issues.apache.org/jira/browse/NIFI-12661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Gilman resolved NIFI-12661. Resolution: Duplicate > Flow Analysis report menu > - > > Key: NIFI-12661 > URL: https://issues.apache.org/jira/browse/NIFI-12661 > Project: Apache NiFi > Issue Type: Sub-task > Components: Core UI >Reporter: Shane Ardell >Assignee: Shane Ardell >Priority: Major > > Implement the work from [https://github.com/apache/nifi/pull/8273] in the new > UI. Link to original ticket here: > https://issues.apache.org/jira/browse/NIFI-11520 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13353) anchor tags (links) on dark surfaces in dark mode are too dark
Scott Aslan created NIFI-13353: -- Summary: anchor tags (links) on dark surfaces in dark mode are too dark Key: NIFI-13353 URL: https://issues.apache.org/jira/browse/NIFI-13353 Project: Apache NiFi Issue Type: Sub-task Reporter: Scott Aslan Attachments: image-2024-06-03-17-06-55-325.png !image-2024-06-03-17-06-55-325.png|width=483,height=212! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (NIFI-13353) anchor tags (links) on dark surfaces in dark mode are too dark
[ https://issues.apache.org/jira/browse/NIFI-13353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Aslan reassigned NIFI-13353: -- Assignee: Scott Aslan > anchor tags (links) on dark surfaces in dark mode are too dark > -- > > Key: NIFI-13353 > URL: https://issues.apache.org/jira/browse/NIFI-13353 > Project: Apache NiFi > Issue Type: Sub-task >Reporter: Scott Aslan >Assignee: Scott Aslan >Priority: Major > Attachments: image-2024-06-03-17-06-55-325.png > > > !image-2024-06-03-17-06-55-325.png|width=483,height=212! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13352 Adjust Shutdown handling in ListenOTLP and Test Class [nifi]
joewitt commented on PR #8913: URL: https://github.com/apache/nifi/pull/8913#issuecomment-2146189922 ShutdownQuietPeriod.QUICK.getDuration() changes from the default of 2 secs to much faster which is better in test and related environments like this. Nice! -- 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
Re: [PR] NIFI-13352 Adjust Shutdown handling in ListenOTLP and Test Class [nifi]
joewitt commented on PR #8913: URL: https://github.com/apache/nifi/pull/8913#issuecomment-2146187129 +1 pending build results. -- 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
[PR] NIFI-13159 PutFTP/PutSFTP change when delete happens on REPLACE [nifi]
mosermw opened a new pull request, #8914: URL: https://github.com/apache/nifi/pull/8914 # Summary [NIFI-13159](https://issues.apache.org/jira/browse/NIFI-13159) For PutFTP/PutSFTP conflict resolution strategy REPLACE, when DOT_RENAME or temp filename is used, delay the deletion of remote file until after temp file transfer completes. # 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 Please indicate the verification steps performed prior to pull request creation. ### Build - [x] Build completed using `mvn clean install -P contrib-check` - [x] JDK 21 ### UI Contributions - [ ] NiFi is modernizing its UI. Any contributions that update the [current UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui) also need to be implemented in the [new UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi). ### 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 - [ ] 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] [Commented] (NIFI-13301) Create ExtensionRegistryClient for External Extension Registry Interaction
[
https://issues.apache.org/jira/browse/NIFI-13301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851821#comment-17851821
]
David Handermann commented on NIFI-13301:
-
[~pvillard] Running multiple instances of NiFi Registry could provide high
availability for read operations. That would require a different strategy for
pushing artifacts into each NiFi Registry, which could be cumbersome, but it
might be possible. As mentioned above, I think moving in the direction of
another backend solution would be a better strategic approach for something
like a public marketplace, but of course there are many details to consider.
> Create ExtensionRegistryClient for External Extension Registry Interaction
> --
>
> Key: NIFI-13301
> URL: https://issues.apache.org/jira/browse/NIFI-13301
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions, NiFi Registry
> Environment: Linux: Ubuntu 20.04 or 22.04
>Reporter: James Guzman (Medel)
>Assignee: James Guzman (Medel)
>Priority: Minor
>
> *Objective:* Improve/enable sharing/reuse of at least two features of Apache
> NiFi, so the community can have an easier time contributing their flows
> and/or custom processors into a NiFi Marketplace:
> * {*}Pre-Designed Flows{*}: (Approach 1) stored in a NiFi Registry or
> accessible location. (Approach 2) NiFi Registry can also substituted by
> NiFi's git registry client having the location of the NiFi Marketplace.
> Thus, we just have a git location and NiFi uses that to find/store flows.
> * *Components/Processors* built in *Java/Python* that anyone is free to use
> * *End to End Full Stack Applications Powered By NiFi or MiNiFi CPP?* The
> frontend could be various ones from PyQT, ReactJS, H2O.ai Wave, 3D Slicer,
> OHIF Viewer, etc: (Maybe this one can be subscription based where users get
> access if they invest in the monthly or yearly subscription?)
> *Potential Solution:* Apache NiFi builds an extension point for interacting
> with Extension Registries, similar to how it currently has
> *{{FlowRegistryClient}}* with implementations for NiFi Registry and now
> GitHub, there would be *{{ExtensionRegistryClient}}* with implementations for
> stuff like Nexus, NiFi Registry, and any other vendor ones, for example maybe
> Datavolo provides one, but basically in apache we don't want to build another
> application, we already have NiFi Registry. (Briefly Discussed with [~bbende]
> )
> * I will start by looking into *{{FlowRegistryClient}}* and then base
> *{{ExtensionRegistryClient}}* toward that approach. If I am understanding
> correctly, we would contribute an *{{ExtensionRegistryClient}}* feature into
> Apache NiFi that enables NiFi to integrate with other vendors (Datavolo,
> H2Oai, etc) group of processors, data flow templates and so on. I see where
> you are coming from with for Apache the goal being not to build another
> application. That application could be by the another and NiFi's
> *{{ExtensionRegistryClient}}* hooks up to their {*}RegistryServer{*}. (Heres
> the path I will take toward that goal).
>
> {*}Project Ownership{*}: There will be a clear line that the NiFi Marketplace
> is not owned by the Apache NiFi PMC, rather it will be managed and owned by a
> vendor in close alignment with NiFi, which we will announce at a later time.
>
> {*}Motivation (NiFi){*}: Some people in the community have shown interest in
> having a NiFi Processor Marketplace where they can contribute their category
> of processors. In particular, I saw some people interested in contributing
> their NiFi python processors. This NiFi Processor marketplace could be also
> applied toward the community interested in contributing custom NiFi java
> processors.
> * {*}Extra MiNiFi C+{+}{{+}}{*}: We could even add a section for MiNiFi C+
> custom processors. There is a part of the MiNiFi build process that brings in
> NiFi through building the JNI extension. So, that is a way to integrate NiFi
> Registry there too.
> I have briefly talked with [~bbende] and [~joewitt] asking them questions on
> ways to bring custom python processors into production. One of the routes was
> through leveraging NiFi Registry in connection with Apache NiFi to streamline
> integration. For my use case, I would leverage the NiFi Processor Marketplace
> to start contributing my AI/DL "Medical Imaging" Pipeline of custom NiFi
> Python Processors where I focused on my master thesis AI/DL for stroke
> diagnosis.
> *High Level Details of NiFi Processor Marketplace App:* For a full stack NiFi
> Processor Marketplace App, there are frameworks we can leverage for the UI
> from ReactJS (this mainly is used for frontend), H2O.ai Wave (this can be
> used for full
Re: [PR] [NIFI-13082] Created SplitPcap processor, Pcap supporting class, and … [nifi]
exceptionfactory commented on PR #8691: URL: https://github.com/apache/nifi/pull/8691#issuecomment-2146154785 > I've been looking through the codebase and I can't find any instances where OutputStream is used without either an OutputStreamCallback (and thus is seemingly incompatible with InputStreamCallback as used in SplitRecord) or a RecordWriter (which needs a schema and a controller service). Is writing a controller service required in order to follow this pattern, or is there an example of another approach somewhere I've missed? Writing a Controller Service is not required. The `StreamCallback` interface provides access to both an `InputStream` and `OutputStream`, which should support a stream-based solution without excessive buffering in memory. > > Also, in SplitRecord the 'splits' array is used to hold the data processed within the InputStreamCallback that splits the original record, but the individual 'split' records aren't returned by the callback (just appended to the 'splits' array whilst the callback is running). Does that mean that the callback itself is synchronous, or does something in OutputStream handle blocking to ensure there aren't issues with race conditions? The callback is synchronous, so `onTrigger()` and methods it calls must be implemented in a thread-safe manner. -- 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-13138) Add extensions name and description in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Handermann updated NIFI-13138: Fix Version/s: 2.0.0-M4 Resolution: Fixed Status: Resolved (was: Patch Available) > Add extensions name and description in NiFi Registry > > > Key: NIFI-13138 > URL: https://issues.apache.org/jira/browse/NIFI-13138 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 1h > Remaining Estimate: 0h > > Similar to NIFI-13050, it'd be extremely useful, for a given bundle, in NiFi > Registry, to display the included extensions in that bundle. For each > extension, we want to display the name and associated description. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13138) Add extensions name and description in NiFi Registry
[ https://issues.apache.org/jira/browse/NIFI-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851818#comment-17851818 ] ASF subversion and git services commented on NIFI-13138: Commit b768b23e0fee26d84698f584e0a4c862c83ccd97 in nifi's branch refs/heads/main from Pierre Villard [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=b768b23e0f ] NIFI-13138 Add Bundle extensions name and description in NiFi Registry This closes #8740 Signed-off-by: David Handermann > Add extensions name and description in NiFi Registry > > > Key: NIFI-13138 > URL: https://issues.apache.org/jira/browse/NIFI-13138 > Project: Apache NiFi > Issue Type: Improvement > Components: NiFi Registry >Reporter: Pierre Villard >Assignee: Pierre Villard >Priority: Major > Time Spent: 1h > Remaining Estimate: 0h > > Similar to NIFI-13050, it'd be extremely useful, for a given bundle, in NiFi > Registry, to display the included extensions in that bundle. For each > extension, we want to display the name and associated description. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13138 - Add extensions name and description in NiFi Registry [nifi]
exceptionfactory closed pull request #8740: NIFI-13138 - Add extensions name and description in NiFi Registry URL: https://github.com/apache/nifi/pull/8740 -- 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-13352) Intermittent Failures in ListenOTLPTest
[
https://issues.apache.org/jira/browse/NIFI-13352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Handermann updated NIFI-13352:
Status: Patch Available (was: Open)
> Intermittent Failures in ListenOTLPTest
> ---
>
> Key: NIFI-13352
> URL: https://issues.apache.org/jira/browse/NIFI-13352
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
>Affects Versions: 2.0.0-M3
>Reporter: David Handermann
>Assignee: David Handermann
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The {{ListenOTLPTest}} throws failures intermittently when running on GitHub
> Actions, related to socket connection issues.
> {noformat}
> Error: Tests run: 11, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:
> 4.199 s <<< FAILURE! -- in
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest
> Error:
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed
> -- Time elapsed: 0.054 s <<< ERROR!
> org.apache.nifi.web.client.api.WebClientServiceException: Request execution
> failed HTTP Method [GET] URI [https://localhost:65351/v1/logs]
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:273)
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.retrieve(StandardWebClientService.java:258)
> at
> org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed(ListenOTLPTest.java:225)
> at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
> Caused by: java.net.ConnectException: Failed to connect to
> localhost/[0:0:0:0:0:0:0:1]:65351
> at
> okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
> at
> okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
> at
> okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
> at
> okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
> at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
> at
> okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
> at
> okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
> at
> okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
> at
> okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
> at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
> at
> org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:271)
> ... 5 more
> Suppressed: java.net.SocketException: An established connection was
> aborted by the software in your host machine
> at java.base/sun.nio.ch.SocketDispatcher.read0(Native Method)
> at
> java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:46)
> at
> java.base/sun.nio.ch.NioSocketImpl.tryRead(NioSocketImpl.java:262)
> at
> java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:313)
> at
> java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:352)
> at
> java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
> at
> java.base/java.net.Socket$SocketInputStream.read(Socket.java:)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483)
> at
> java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)
> at
> java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1461)
> at
> java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1066)
> at
[PR] NIFI-13352 Adjust Shutdown handling in ListenOTLP and Test Class [nifi]
exceptionfactory opened a new pull request, #8913: URL: https://github.com/apache/nifi/pull/8913 # Summary [NIFI-13352](https://issues.apache.org/jira/browse/NIFI-13352) Adjusts shutdown handling in the `ListenOTLP` Processor and associated test class to mitigate intermittent test failures related to socket connections. Changes include shortening the shutdown quiet period for the `ListenOTLP` `HttpServerFactory` to avoiding waiting 2 seconds before closing the listening socket, instead waiting 100 ms. Changes to the test class include calling `TestRunner.stop()` in an `AfterEach` method to proactively close listening sockets. # 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 Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 21 ### UI Contributions - [ ] NiFi is modernizing its UI. Any contributions that update the [current UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui) also need to be implemented in the [new UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi). ### 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 - [ ] 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
Re: [PR] NIFI-13313: Remove old UI [nifi]
exceptionfactory commented on code in PR #8906:
URL: https://github.com/apache/nifi/pull/8906#discussion_r1625057038
##
nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/AccessResource.java:
##
@@ -412,7 +412,7 @@ private LogoutRequest completeLogoutRequest(final
HttpServletResponse httpServle
}
private String getNiFiLogoutCompleteUri() {
-return getNiFiUri() + "logout-complete";
+return getNiFiUri() + "#/logout-complete";
Review Comment:
Thanks for making the adjustments in `JettyServer` to add the rewrite
handling @mcgilman, the latest version looks good!
--
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-13288) Fix SplitXml, and SplitAvro processors not to call session.putAttribute multiple times
[ https://issues.apache.org/jira/browse/NIFI-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Stieglitz updated NIFI-13288: Summary: Fix SplitXml, and SplitAvro processors not to call session.putAttribute multiple times (was: Fix SplitJson, SplitXml, and SplitAvro processors not to call session.putAttribute multiple times) > Fix SplitXml, and SplitAvro processors not to call session.putAttribute > multiple times > -- > > Key: NIFI-13288 > URL: https://issues.apache.org/jira/browse/NIFI-13288 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Assignee: Daniel Stieglitz >Priority: Major > > Per [~markap14] in the following > [post|https://lists.apache.org/thread/7zo2px31r3377c7vhby4h6nrngdf3llf] one > should avoid calling session.putAttribute many times since in order to > maintain object immutability it has to create a new FlowFile object (and a > new HashMap of all attributes!) > for every call to session.putAttribute which leads to potentially a huge > amount of garbage getting created. Some of the split processors SplitJson, > SplitXml, and SplitAvro all have loops to create a new flow file for each > split and it calls session.putAttribute more than once (in order to populate > the split attributes FRAGMENT_ID, FRAGMENT_INDEX etc) for each flow file > created. Per Mark's advice, these should be fixed to to populate the > attributes in a Map and then make one call to session.putAllAttributes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13288) Fix SplitXml, and SplitAvro processors not to call session.putAttribute multiple times
[ https://issues.apache.org/jira/browse/NIFI-13288?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Stieglitz updated NIFI-13288: Description: Per [~markap14] in the following [post|https://lists.apache.org/thread/7zo2px31r3377c7vhby4h6nrngdf3llf] one should avoid calling session.putAttribute many times since in order to maintain object immutability it has to create a new FlowFile object (and a new HashMap of all attributes!) for every call to session.putAttribute which leads to potentially a huge amount of garbage getting created. Some of the split processors SplitXml and SplitAvro all have loops to create a new flow file for each split and it calls session.putAttribute more than once (in order to populate the split attributes FRAGMENT_ID, FRAGMENT_INDEX etc) for each flow file created. Per Mark's advice, these should be fixed to to populate the attributes in a Map and then make one call to session.putAllAttributes. was: Per [~markap14] in the following [post|https://lists.apache.org/thread/7zo2px31r3377c7vhby4h6nrngdf3llf] one should avoid calling session.putAttribute many times since in order to maintain object immutability it has to create a new FlowFile object (and a new HashMap of all attributes!) for every call to session.putAttribute which leads to potentially a huge amount of garbage getting created. Some of the split processors SplitJson, SplitXml, and SplitAvro all have loops to create a new flow file for each split and it calls session.putAttribute more than once (in order to populate the split attributes FRAGMENT_ID, FRAGMENT_INDEX etc) for each flow file created. Per Mark's advice, these should be fixed to to populate the attributes in a Map and then make one call to session.putAllAttributes. > Fix SplitXml, and SplitAvro processors not to call session.putAttribute > multiple times > -- > > Key: NIFI-13288 > URL: https://issues.apache.org/jira/browse/NIFI-13288 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Assignee: Daniel Stieglitz >Priority: Major > > Per [~markap14] in the following > [post|https://lists.apache.org/thread/7zo2px31r3377c7vhby4h6nrngdf3llf] one > should avoid calling session.putAttribute many times since in order to > maintain object immutability it has to create a new FlowFile object (and a > new HashMap of all attributes!) > for every call to session.putAttribute which leads to potentially a huge > amount of garbage getting created. Some of the split processors SplitXml and > SplitAvro all have loops to create a new flow file for each split and it > calls session.putAttribute more than once (in order to populate the split > attributes FRAGMENT_ID, FRAGMENT_INDEX etc) for each flow file created. Per > Mark's advice, these should be fixed to to populate the attributes in a Map > and then make one call to session.putAllAttributes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13352) Intermittent Failures in ListenOTLPTest
David Handermann created NIFI-13352:
---
Summary: Intermittent Failures in ListenOTLPTest
Key: NIFI-13352
URL: https://issues.apache.org/jira/browse/NIFI-13352
Project: Apache NiFi
Issue Type: Bug
Components: Extensions
Affects Versions: 2.0.0-M3
Reporter: David Handermann
Assignee: David Handermann
The {{ListenOTLPTest}} throws failures intermittently when running on GitHub
Actions, related to socket connection issues.
{noformat}
Error: Tests run: 11, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 4.199
s <<< FAILURE! -- in org.apache.nifi.processors.opentelemetry.ListenOTLPTest
Error:
org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed
-- Time elapsed: 0.054 s <<< ERROR!
org.apache.nifi.web.client.api.WebClientServiceException: Request execution
failed HTTP Method [GET] URI [https://localhost:65351/v1/logs]
at
org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:273)
at
org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.retrieve(StandardWebClientService.java:258)
at
org.apache.nifi.processors.opentelemetry.ListenOTLPTest.testGetMethodNotAllowed(ListenOTLPTest.java:225)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
Caused by: java.net.ConnectException: Failed to connect to
localhost/[0:0:0:0:0:0:0:1]:65351
at
okhttp3.internal.connection.RealConnection.connectSocket(RealConnection.kt:297)
at
okhttp3.internal.connection.RealConnection.connect(RealConnection.kt:207)
at
okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFinder.kt:226)
at
okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFinder.kt:106)
at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFinder.kt:74)
at
okhttp3.internal.connection.RealCall.initExchange$okhttp(RealCall.kt:255)
at
okhttp3.internal.connection.ConnectInterceptor.intercept(ConnectInterceptor.kt:32)
at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at
okhttp3.internal.cache.CacheInterceptor.intercept(CacheInterceptor.kt:95)
at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at
okhttp3.internal.http.BridgeInterceptor.intercept(BridgeInterceptor.kt:83)
at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at
okhttp3.internal.http.RetryAndFollowUpInterceptor.intercept(RetryAndFollowUpInterceptor.kt:76)
at
okhttp3.internal.http.RealInterceptorChain.proceed(RealInterceptorChain.kt:109)
at
okhttp3.internal.connection.RealCall.getResponseWithInterceptorChain$okhttp(RealCall.kt:201)
at okhttp3.internal.connection.RealCall.execute(RealCall.kt:154)
at
org.apache.nifi.web.client.StandardWebClientService$StandardHttpRequestBodySpec.execute(StandardWebClientService.java:271)
... 5 more
Suppressed: java.net.SocketException: An established connection was
aborted by the software in your host machine
at java.base/sun.nio.ch.SocketDispatcher.read0(Native Method)
at
java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:46)
at
java.base/sun.nio.ch.NioSocketImpl.tryRead(NioSocketImpl.java:262)
at
java.base/sun.nio.ch.NioSocketImpl.implRead(NioSocketImpl.java:313)
at
java.base/sun.nio.ch.NioSocketImpl.read(NioSocketImpl.java:352)
at
java.base/sun.nio.ch.NioSocketImpl$1.read(NioSocketImpl.java:802)
at
java.base/java.net.Socket$SocketInputStream.read(Socket.java:)
at
java.base/sun.security.ssl.SSLSocketInputRecord.read(SSLSocketInputRecord.java:489)
at
java.base/sun.security.ssl.SSLSocketInputRecord.readHeader(SSLSocketInputRecord.java:483)
at
java.base/sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket(SSLSocketInputRecord.java:70)
at
java.base/sun.security.ssl.SSLSocketImpl.readApplicationRecord(SSLSocketImpl.java:1461)
at
java.base/sun.security.ssl.SSLSocketImpl$AppInputStream.read(SSLSocketImpl.java:1066)
at okio.InputStreamSource.read(JvmOkio.kt:93)
at okio.AsyncTimeout$source$1.read(AsyncTimeout.kt:153)
at okio.RealBufferedSource.request(RealBufferedSource.kt:210)
at okio.RealBufferedSource.require(RealBufferedSource.kt:203)
at
okhttp3.internal.http2.Http2Reader.nextFrame(Http2Reader.kt:89)
at
[jira] [Updated] (NIFI-13350) Unable to Edit Parameter
[
https://issues.apache.org/jira/browse/NIFI-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rob Fellows updated NIFI-13350:
---
Fix Version/s: 2.0.0-M4
Resolution: Fixed
Status: Resolved (was: Patch Available)
> Unable to Edit Parameter
>
>
> Key: NIFI-13350
> URL: https://issues.apache.org/jira/browse/NIFI-13350
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Major
> Fix For: 2.0.0-M4
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Unable to Edit Parameter in New Parameter Context dialog.
> {noformat}
> TypeError: this.editParameter is not a function
> at _ParameterTable.editClicked (parameter-table.component.ts:277:14)
> at ParameterTable_td_14_Conditional_6_Template_button_click_0_listener
> (parameter-table.component.html:125:72)
> at executeListenerWithErrorHandling (core.mjs:25629:16)
> at wrapListenerIn_markDirtyAndPreventDefault (core.mjs:25669:22)
> at HTMLButtonElement. (platform-browser.mjs:749:112)
> at _ZoneDelegate.invokeTask (zone.js:403:31)
> at core.mjs:18229:55
> at AsyncStackTaggingZoneSpec.onInvokeTask (core.mjs:18229:36)
> at _ZoneDelegate.invokeTask (zone.js:402:36)
> at Object.onInvokeTask (core.mjs:18542:33){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-13350) Unable to Edit Parameter
[
https://issues.apache.org/jira/browse/NIFI-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851814#comment-17851814
]
ASF subversion and git services commented on NIFI-13350:
Commit 210e0b1655435a655130cca897b94ebe84d5b647 in nifi's branch
refs/heads/main from Matt Gilman
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=210e0b1655 ]
NIFI-13350: (#8912)
- Allowing parameters to be edited in New Parameter Context dialog.
- Ensuring the proper tab is selected in the Parameter Context dialog based on
the current usage.
This closes #8912
> Unable to Edit Parameter
>
>
> Key: NIFI-13350
> URL: https://issues.apache.org/jira/browse/NIFI-13350
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Unable to Edit Parameter in New Parameter Context dialog.
> {noformat}
> TypeError: this.editParameter is not a function
> at _ParameterTable.editClicked (parameter-table.component.ts:277:14)
> at ParameterTable_td_14_Conditional_6_Template_button_click_0_listener
> (parameter-table.component.html:125:72)
> at executeListenerWithErrorHandling (core.mjs:25629:16)
> at wrapListenerIn_markDirtyAndPreventDefault (core.mjs:25669:22)
> at HTMLButtonElement. (platform-browser.mjs:749:112)
> at _ZoneDelegate.invokeTask (zone.js:403:31)
> at core.mjs:18229:55
> at AsyncStackTaggingZoneSpec.onInvokeTask (core.mjs:18229:36)
> at _ZoneDelegate.invokeTask (zone.js:402:36)
> at Object.onInvokeTask (core.mjs:18542:33){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-13350: Allowing parameters to be edited in New Parameter Context dialog [nifi]
rfellows merged PR #8912: URL: https://github.com/apache/nifi/pull/8912 -- 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
Re: [PR] NIFI-13313: Remove old UI [nifi]
joewitt commented on PR #8906: URL: https://github.com/apache/nifi/pull/8906#issuecomment-2146094253 just built and things are looking really good! -- 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
Re: [PR] NIFI-13341 Update BinFiles not to write attributes to FlowFiles for auto-terminated original relationship [nifi]
mattyb149 closed pull request #8911: NIFI-13341 Update BinFiles not to write attributes to FlowFiles for auto-terminated original relationship URL: https://github.com/apache/nifi/pull/8911 -- 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-13341) Update MergeContent and JoinEnrichment to not write attributes to FlowFiles for auto-terminated Original relationship
[ https://issues.apache.org/jira/browse/NIFI-13341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess resolved NIFI-13341. - Fix Version/s: 2.0.0-M4 Resolution: Fixed > Update MergeContent and JoinEnrichment to not write attributes to FlowFiles > for auto-terminated Original relationship > - > > Key: NIFI-13341 > URL: https://issues.apache.org/jira/browse/NIFI-13341 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.26.0, 2.0.0-M3 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 40m > Remaining Estimate: 0h > > NIFI-13196 introduces the ability to check if a relationship is > auto-terminated. In the case of BinFiles (which is extended by MergeContent > and JoinEnrichment processors), the processor can have the REL_ORIGINAL > auto-terminated. When it is auto-terminated, skip copying attributes into the > flow files which are being auto-terminated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13341 Update BinFiles not to write attributes to FlowFiles for auto-terminated original relationship [nifi]
mattyb149 commented on PR #8911: URL: https://github.com/apache/nifi/pull/8911#issuecomment-2146072011 isAutoTerminated() was only added to ProcessContext in 2.x (https://issues.apache.org/jira/browse/NIFI-13196) so it can't be backported as-is. I will merge to main however and we can discuss whether to backport both Jiras. -- 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
Re: [PR] NIFI-13350: Allowing parameters to be edited in New Parameter Context dialog [nifi]
rfellows commented on PR #8912: URL: https://github.com/apache/nifi/pull/8912#issuecomment-2146061002 Will review... -- 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-11078) Add Component UUID to Flow Configuration History viewable table
[ https://issues.apache.org/jira/browse/NIFI-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851805#comment-17851805 ] ASF subversion and git services commented on NIFI-11078: Commit f9aefc2d5e6e66d4d2f2a70d156addeee3da3ff3 in nifi's branch refs/heads/main from sujkm [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=f9aefc2d5e ] NIFI-11078: Adds Component UUID to Flow Configuration History Table (#8909) This closes #8909 > Add Component UUID to Flow Configuration History viewable table > --- > > Key: NIFI-11078 > URL: https://issues.apache.org/jira/browse/NIFI-11078 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Assignee: Sue Kim >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > The Flow Configuration History table provides the component name but not the > component UUID directly in the viewable table except via the "View Details" > icon link. There are often many processors on the canvas with the same name > and it is impossible to differentiate between two of the same name unless you > apply a filter on the id. Sometimes the component id is unknown (for instance > when it was removed from the canvas) and so there is no way to apply the > filter. Being able to view and sort by component id would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-11078: Adds Component UUID to Flow Configuration History Table [nifi]
rfellows merged PR #8909: URL: https://github.com/apache/nifi/pull/8909 -- 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-11078) Add Component UUID to Flow Configuration History viewable table
[ https://issues.apache.org/jira/browse/NIFI-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows updated NIFI-11078: --- Fix Version/s: 2.0.0-M4 Resolution: Fixed Status: Resolved (was: Patch Available) > Add Component UUID to Flow Configuration History viewable table > --- > > Key: NIFI-11078 > URL: https://issues.apache.org/jira/browse/NIFI-11078 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Assignee: Sue Kim >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The Flow Configuration History table provides the component name but not the > component UUID directly in the viewable table except via the "View Details" > icon link. There are often many processors on the canvas with the same name > and it is impossible to differentiate between two of the same name unless you > apply a filter on the id. Sometimes the component id is unknown (for instance > when it was removed from the canvas) and so there is no way to apply the > filter. Being able to view and sort by component id would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13323) For 1.x, Remove the instantiation of Object arrays for arguments in ComponentLog log and org.slf4j.Logger statements
[ https://issues.apache.org/jira/browse/NIFI-13323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Stieglitz updated NIFI-13323: Status: Patch Available (was: In Progress) > For 1.x, Remove the instantiation of Object arrays for arguments in > ComponentLog log and org.slf4j.Logger statements > > > Key: NIFI-13323 > URL: https://issues.apache.org/jira/browse/NIFI-13323 > Project: Apache NiFi > Issue Type: Improvement >Affects Versions: 1.27.0 >Reporter: Daniel Stieglitz >Assignee: Daniel Stieglitz >Priority: Major > Time Spent: 1h 20m > Remaining Estimate: 0h > > This ticket is a follow up of NIFI-13265 which was only able to be applied to > the 2.x branch. This ticket aims to do the same type of changes in the 1.x > branch. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-11078) Add Component UUID to Flow Configuration History viewable table
[ https://issues.apache.org/jira/browse/NIFI-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rob Fellows updated NIFI-11078: --- Status: Patch Available (was: Open) > Add Component UUID to Flow Configuration History viewable table > --- > > Key: NIFI-11078 > URL: https://issues.apache.org/jira/browse/NIFI-11078 > Project: Apache NiFi > Issue Type: Improvement >Reporter: Daniel Stieglitz >Assignee: Sue Kim >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > The Flow Configuration History table provides the component name but not the > component UUID directly in the viewable table except via the "View Details" > icon link. There are often many processors on the canvas with the same name > and it is impossible to differentiate between two of the same name unless you > apply a filter on the id. Sometimes the component id is unknown (for instance > when it was removed from the canvas) and so there is no way to apply the > filter. Being able to view and sort by component id would be helpful. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-11078: Adds Component UUID to Flow Configuration History Table [nifi]
rfellows commented on PR #8909: URL: https://github.com/apache/nifi/pull/8909#issuecomment-2146028861 Reviewing... -- 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-13351) Enhance QueryDatabaseTable and QueryDatabaseTableRecord processors not to call session.putAttribute multiple times
Jim Steinebrey created NIFI-13351: - Summary: Enhance QueryDatabaseTable and QueryDatabaseTableRecord processors not to call session.putAttribute multiple times Key: NIFI-13351 URL: https://issues.apache.org/jira/browse/NIFI-13351 Project: Apache NiFi Issue Type: Improvement Affects Versions: 2.0.0-M3, 1.26.0 Reporter: Jim Steinebrey Assignee: Jim Steinebrey Per [~markap14] in the following [post|https://lists.apache.org/thread/7zo2px31r3377c7vhby4h6nrngdf3llf] one should avoid calling session.putAttribute many times since in order to maintain object immutability it has to create a new FlowFile object (and a new HashMap of all attributes!) for every call to session.putAttribute which leads to potentially a large amount of unneeded garbage getting created. Enhance QueryDatabaseTable and QueryDatabaseTableRecord processors not to call session.putAttribute multiple times in a for loop for column max values. The repeated putAttribute calls exist in AbstractQueryDatabaseTable which is extended by those two processors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-13350: Allowing parameters to be edited in New Parameter Context dialog [nifi]
mcgilman opened a new pull request, #8912: URL: https://github.com/apache/nifi/pull/8912 NIFI-13350: - Allowing parameters to be edited in New Parameter Context dialog. - Ensuring the proper tab is selected in the Parameter Context dialog based on the current usage. -- 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-13350) Unable to Edit Parameter
[
https://issues.apache.org/jira/browse/NIFI-13350?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matt Gilman updated NIFI-13350:
---
Status: Patch Available (was: In Progress)
> Unable to Edit Parameter
>
>
> Key: NIFI-13350
> URL: https://issues.apache.org/jira/browse/NIFI-13350
> Project: Apache NiFi
> Issue Type: Sub-task
> Components: Core Framework
>Reporter: Matt Gilman
>Assignee: Matt Gilman
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Unable to Edit Parameter in New Parameter Context dialog.
> {noformat}
> TypeError: this.editParameter is not a function
> at _ParameterTable.editClicked (parameter-table.component.ts:277:14)
> at ParameterTable_td_14_Conditional_6_Template_button_click_0_listener
> (parameter-table.component.html:125:72)
> at executeListenerWithErrorHandling (core.mjs:25629:16)
> at wrapListenerIn_markDirtyAndPreventDefault (core.mjs:25669:22)
> at HTMLButtonElement. (platform-browser.mjs:749:112)
> at _ZoneDelegate.invokeTask (zone.js:403:31)
> at core.mjs:18229:55
> at AsyncStackTaggingZoneSpec.onInvokeTask (core.mjs:18229:36)
> at _ZoneDelegate.invokeTask (zone.js:402:36)
> at Object.onInvokeTask (core.mjs:18542:33){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (NIFI-13342) Restore amazon sts dependency
[ https://issues.apache.org/jira/browse/NIFI-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851790#comment-17851790 ] ASF subversion and git services commented on NIFI-13342: Commit 34c24f759ac5478b4f335d6df5ff46e01dfc132d in nifi's branch refs/heads/main from Joe Witt [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=34c24f759a ] NIFI-13342 restored sts dependency in aws service api Signed-off-by: Matt Burgess This closes #8910 > Restore amazon sts dependency > -- > > Key: NIFI-13342 > URL: https://issues.apache.org/jira/browse/NIFI-13342 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 2.0.0-M3 >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In NIFI-11288 we brought in the aws sts library . But in NiFI 12988 it was > removed as detections found it unused by our code. Restoring and marking as > runtime which means code should not depend on it but it is needed at runtime > which will help with future scan/resolutions as we clean things up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13342) Restore amazon sts dependency
[ https://issues.apache.org/jira/browse/NIFI-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-13342: Resolution: Fixed Status: Resolved (was: Patch Available) > Restore amazon sts dependency > -- > > Key: NIFI-13342 > URL: https://issues.apache.org/jira/browse/NIFI-13342 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 2.0.0-M3 >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > In NIFI-11288 we brought in the aws sts library . But in NiFI 12988 it was > removed as detections found it unused by our code. Restoring and marking as > runtime which means code should not depend on it but it is needed at runtime > which will help with future scan/resolutions as we clean things up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13342 restored sts dependency in aws service api [nifi]
mattyb149 closed pull request #8910: NIFI-13342 restored sts dependency in aws service api URL: https://github.com/apache/nifi/pull/8910 -- 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
Re: [PR] NIFI-13342 restored sts dependency in aws service api [nifi]
mattyb149 commented on PR #8910: URL: https://github.com/apache/nifi/pull/8910#issuecomment-2145958398 +1 LGTM, thanks for the fix! Merging to 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] [Updated] (NIFI-13342) Restore amazon sts dependency
[ https://issues.apache.org/jira/browse/NIFI-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matt Burgess updated NIFI-13342: Status: Patch Available (was: Open) > Restore amazon sts dependency > -- > > Key: NIFI-13342 > URL: https://issues.apache.org/jira/browse/NIFI-13342 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 2.0.0-M3 >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M4 > > Time Spent: 10m > Remaining Estimate: 0h > > In NIFI-11288 we brought in the aws sts library . But in NiFI 12988 it was > removed as detections found it unused by our code. Restoring and marking as > runtime which means code should not depend on it but it is needed at runtime > which will help with future scan/resolutions as we clean things up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13350) Unable to Edit Parameter
Matt Gilman created NIFI-13350:
--
Summary: Unable to Edit Parameter
Key: NIFI-13350
URL: https://issues.apache.org/jira/browse/NIFI-13350
Project: Apache NiFi
Issue Type: Sub-task
Components: Core Framework
Reporter: Matt Gilman
Assignee: Matt Gilman
Unable to Edit Parameter in New Parameter Context dialog.
{noformat}
TypeError: this.editParameter is not a function
at _ParameterTable.editClicked (parameter-table.component.ts:277:14)
at ParameterTable_td_14_Conditional_6_Template_button_click_0_listener
(parameter-table.component.html:125:72)
at executeListenerWithErrorHandling (core.mjs:25629:16)
at wrapListenerIn_markDirtyAndPreventDefault (core.mjs:25669:22)
at HTMLButtonElement. (platform-browser.mjs:749:112)
at _ZoneDelegate.invokeTask (zone.js:403:31)
at core.mjs:18229:55
at AsyncStackTaggingZoneSpec.onInvokeTask (core.mjs:18229:36)
at _ZoneDelegate.invokeTask (zone.js:402:36)
at Object.onInvokeTask (core.mjs:18542:33){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (NIFI-13349) Align angular material and tailwind typography font-sizes
Scott Aslan created NIFI-13349: -- Summary: Align angular material and tailwind typography font-sizes Key: NIFI-13349 URL: https://issues.apache.org/jira/browse/NIFI-13349 Project: Apache NiFi Issue Type: Sub-task Reporter: Scott Aslan Assignee: Scott Aslan -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13341 Update BinFiles not to write attributes to FlowFiles for auto-terminated original relationship [nifi]
mattyb149 commented on PR #8911: URL: https://github.com/apache/nifi/pull/8911#issuecomment-2145895209 +1 LGTM, will merge when Github Actions finish successfully. -- 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-13341) Update MergeContent and JoinEnrichment to not write attributes to FlowFiles for auto-terminated Original relationship
[ https://issues.apache.org/jira/browse/NIFI-13341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Steinebrey updated NIFI-13341: -- Summary: Update MergeContent and JoinEnrichment to not write attributes to FlowFiles for auto-terminated Original relationship (was: Update MergeContent and JoinEnrichment to not write attributes to FlowFiles for auto-terminated relationship) > Update MergeContent and JoinEnrichment to not write attributes to FlowFiles > for auto-terminated Original relationship > - > > Key: NIFI-13341 > URL: https://issues.apache.org/jira/browse/NIFI-13341 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.26.0, 2.0.0-M3 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > NIFI-13196 introduces the ability to check if a relationship is > auto-terminated. In the case of BinFiles (which is extended by MergeContent > and JoinEnrichment processors), the processor can have the REL_ORIGINAL > auto-terminated. When it is auto-terminated, skip copying attributes into the > flow files which are being auto-terminated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13341) Update MergeContent and JoinEnrichment to not write attributes to FlowFiles for auto-terminated relationship
[ https://issues.apache.org/jira/browse/NIFI-13341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Steinebrey updated NIFI-13341: -- Summary: Update MergeContent and JoinEnrichment to not write attributes to FlowFiles for auto-terminated relationship (was: Update BinFiles not to write attributes to FlowFiles for auto-terminated relationship) > Update MergeContent and JoinEnrichment to not write attributes to FlowFiles > for auto-terminated relationship > > > Key: NIFI-13341 > URL: https://issues.apache.org/jira/browse/NIFI-13341 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.26.0, 2.0.0-M3 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > NIFI-13196 introduces the ability to check if a relationship is > auto-terminated. In the case of BinFiles (which is extended by MergeContent > and JoinEnrichment processors), the processor can have the REL_ORIGINAL > auto-terminated. When it is auto-terminated, skip copying attributes into the > flow files which are being auto-terminated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-13341 Update BinFiles not to write attributes to FlowFiles for auto-terminated original relationship [nifi]
jrsteinebrey opened a new pull request, #8911: URL: https://github.com/apache/nifi/pull/8911 # Summary [NIFI-13341](https://issues.apache.org/jira/browse/NIFI-13341) # 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-13341) 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 I ran the existing MergeContent and JoinEnrichment automated tests and the ConcatenateRangeOfFlowFiles IT tests in RequiresAdditionalInputIT and they all passed. I also create a flow in the UI to test the processor worked properly with the code change. ### Build - [X] Build completed using `mvn clean install -P contrib-check` - [X] JDK 21 ### UI Contributions No UI changes ### Licensing No new files or dependencies. ### Documentation No documentation changes. -- 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
Re: [PR] MINIFICPP-2346-P1: Integrated Conan2 for OpenSSL, CURL, ZLIB & Build MiNiFi [nifi-minifi-cpp]
james94 commented on PR #1793: URL: https://github.com/apache/nifi-minifi-cpp/pull/1793#issuecomment-2145872447 Yes I agree with you @martinzink I do plan to add being able to configure minifi options mapping to conan options through the bootstrap py script, but that will be in a later PR, so we keep this initial PR light as @szaszm 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
[jira] [Created] (NIFI-13348) Improve flow import to leverage ExtensionRegistryClients
Bryan Bende created NIFI-13348: -- Summary: Improve flow import to leverage ExtensionRegistryClients Key: NIFI-13348 URL: https://issues.apache.org/jira/browse/NIFI-13348 Project: Apache NiFi Issue Type: Task Reporter: Bryan Bende Assignee: Bryan Bende Use available flow registry clients to auto resolve NARs during import. Relates to ideas in https://issues.apache.org/jira/browse/NIFI-13077 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[PR] NIFI-13342 restored sts dependency in aws service api [nifi]
joewitt opened a new pull request, #8910: URL: https://github.com/apache/nifi/pull/8910 # Summary [NIFI-13342](https://issues.apache.org/jira/browse/NIFI-13342) # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [ ] Pull Request based on current revision of the `main` branch - [ ] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 21 ### UI Contributions - [ ] NiFi is modernizing its UI. Any contributions that update the [current UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui) also need to be implemented in the [new UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi). ### 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 - [ ] 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] [Updated] (NIFI-13342) Restore amazon sts dependency
[ https://issues.apache.org/jira/browse/NIFI-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-13342: Affects Version/s: 2.0.0-M3 > Restore amazon sts dependency > -- > > Key: NIFI-13342 > URL: https://issues.apache.org/jira/browse/NIFI-13342 > Project: Apache NiFi > Issue Type: Task >Affects Versions: 2.0.0-M3 >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M4 > > > In NIFI-11288 we brought in the aws sts library . But in NiFI 12988 it was > removed as detections found it unused by our code. Restoring and marking as > runtime which means code should not depend on it but it is needed at runtime > which will help with future scan/resolutions as we clean things up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13342) Restore amazon sts dependency
[ https://issues.apache.org/jira/browse/NIFI-13342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joe Witt updated NIFI-13342: Fix Version/s: 2.0.0-M4 > Restore amazon sts dependency > -- > > Key: NIFI-13342 > URL: https://issues.apache.org/jira/browse/NIFI-13342 > Project: Apache NiFi > Issue Type: Task >Reporter: Joe Witt >Assignee: Joe Witt >Priority: Major > Fix For: 2.0.0-M4 > > > In NIFI-11288 we brought in the aws sts library . But in NiFI 12988 it was > removed as detections found it unused by our code. Restoring and marking as > runtime which means code should not depend on it but it is needed at runtime > which will help with future scan/resolutions as we clean things up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13347) Implement REST API for using ExtensionRegistryClient
Bryan Bende created NIFI-13347: -- Summary: Implement REST API for using ExtensionRegistryClient Key: NIFI-13347 URL: https://issues.apache.org/jira/browse/NIFI-13347 Project: Apache NiFi Issue Type: Task Reporter: Bryan Bende Assignee: Bryan Bende This would include the end-points described in the feature proposal for installing a NAR and retrieving component manifests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13346) Implement backend CRUD for ExtensionRegistryClient
Bryan Bende created NIFI-13346: -- Summary: Implement backend CRUD for ExtensionRegistryClient Key: NIFI-13346 URL: https://issues.apache.org/jira/browse/NIFI-13346 Project: Apache NiFi Issue Type: Task Reporter: Bryan Bende Assignee: Bryan Bende -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13345) Introduce ExtensionRegistryClient to nifi-api
Bryan Bende created NIFI-13345: -- Summary: Introduce ExtensionRegistryClient to nifi-api Key: NIFI-13345 URL: https://issues.apache.org/jira/browse/NIFI-13345 Project: Apache NiFi Issue Type: Task Reporter: Bryan Bende Assignee: Bryan Bende -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13344) Implement backend for uploading and managing custom NARs
Bryan Bende created NIFI-13344: -- Summary: Implement backend for uploading and managing custom NARs Key: NIFI-13344 URL: https://issues.apache.org/jira/browse/NIFI-13344 Project: Apache NiFi Issue Type: Task Reporter: Bryan Bende Assignee: Bryan Bende -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13343) Custom NAR Improvements
Bryan Bende created NIFI-13343: -- Summary: Custom NAR Improvements Key: NIFI-13343 URL: https://issues.apache.org/jira/browse/NIFI-13343 Project: Apache NiFi Issue Type: Epic Reporter: Bryan Bende Assignee: Bryan Bende This epic is for tracking work towards the feature proposal for [Custom NAR Improvements|https://cwiki.apache.org/confluence/display/NIFI/Custom+NAR+Improvements]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (NIFI-13329) Fallback to raw viewer when formatted viewer fails
[ https://issues.apache.org/jira/browse/NIFI-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851746#comment-17851746 ] ASF subversion and git services commented on NIFI-13329: Commit 48edbeed9066a564bfe6f80778f4b603c46a in nifi's branch refs/heads/main from Matt Gilman [ https://gitbox.apache.org/repos/asf?p=nifi.git;h=48edbeed90 ] NIFI-13329 - Updating the standard content viewer to render an error message when there is an error formatting. Co-authored-by: Pierre Villard Signed-off-by: Pierre Villard This closes #8905. > Fallback to raw viewer when formatted viewer fails > -- > > Key: NIFI-13329 > URL: https://issues.apache.org/jira/browse/NIFI-13329 > Project: Apache NiFi > Issue Type: Bug >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Attachments: Screenshot 2024-05-30 at 11.19.23.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > The formatted viewer (based on the mime.type attribute) recently became the > default. In case the MIME type is wrong, this would return an error when > opening the flowfile's content. It could be nice to catch the error and > fallback to the raw viewer. > !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (NIFI-13329) Fallback to raw viewer when formatted viewer fails
[ https://issues.apache.org/jira/browse/NIFI-13329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Villard updated NIFI-13329: -- Fix Version/s: 2.0.0-M4 Resolution: Fixed Status: Resolved (was: Patch Available) > Fallback to raw viewer when formatted viewer fails > -- > > Key: NIFI-13329 > URL: https://issues.apache.org/jira/browse/NIFI-13329 > Project: Apache NiFi > Issue Type: Bug >Reporter: Pierre Villard >Assignee: Matt Gilman >Priority: Major > Fix For: 2.0.0-M4 > > Attachments: Screenshot 2024-05-30 at 11.19.23.png > > Time Spent: 40m > Remaining Estimate: 0h > > The formatted viewer (based on the mime.type attribute) recently became the > default. In case the MIME type is wrong, this would return an error when > opening the flowfile's content. It could be nice to catch the error and > fallback to the raw viewer. > !Screenshot 2024-05-30 at 11.19.23.png|width=611,height=150! -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13329: Updating the standard content viewer to render an error message when there is an error formatting [nifi]
asfgit closed pull request #8905: NIFI-13329: Updating the standard content viewer to render an error message when there is an error formatting URL: https://github.com/apache/nifi/pull/8905 -- 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
Re: [PR] NIFI-13329: Updating the standard content viewer to render an error message when there is an error formatting [nifi]
pvillard31 commented on PR #8905: URL: https://github.com/apache/nifi/pull/8905#issuecomment-2145763680 Thanks @mcgilman, merging! -- 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-13342) Restore amazon sts dependency
Joe Witt created NIFI-13342: --- Summary: Restore amazon sts dependency Key: NIFI-13342 URL: https://issues.apache.org/jira/browse/NIFI-13342 Project: Apache NiFi Issue Type: Task Reporter: Joe Witt Assignee: Joe Witt In NIFI-11288 we brought in the aws sts library . But in NiFI 12988 it was removed as detections found it unused by our code. Restoring and marking as runtime which means code should not depend on it but it is needed at runtime which will help with future scan/resolutions as we clean things up. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13030 Adding endpoint for comparing versions of registered flows [nifi]
simonbence commented on code in PR #8670:
URL: https://github.com/apache/nifi/pull/8670#discussion_r1624749082
##
nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-api/src/main/java/org/apache/nifi/web/api/FlowResource.java:
##
@@ -2057,6 +2062,100 @@ public Response getDetails(
return generateOkResponse(flowDetails).build();
}
+@GET
+@Consumes(MediaType.WILDCARD)
+@Produces(MediaType.APPLICATION_JSON)
+
@Path("registries/{registry-id}/branches/{branch-id-a}/buckets/{bucket-id-a}/flows/{flow-id-a}/{version-a}/diff/branches/{branch-id-b}/buckets/{bucket-id-b}/flows/{flow-id-b}/{version-b}")
Review Comment:
As for URL perspective, other then the registry id, it is expected to
provide branch-bucket-flow-version information for both sides of the comparson.
As for the user interface, the idea is to have a button with every version,
like `Compare To...` which leads to the comparison view, which should be
similart to the `Local Changes`, expect additional controls to pick the
information above. The left side of the comparison should be already filled
based on the picked version.
--
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
[PR] NIFI-11078: Adds Component UUID to Flow Configuration History Table [nifi]
sujkm opened a new pull request, #8909: URL: https://github.com/apache/nifi/pull/8909 # Summary [NIFI-11078](https://issues.apache.org/jira/browse/NIFI-11078) Added Component UUID to flow configuration history table in old UI and new UI. # Tracking Please complete the following tracking steps prior to pull request creation. ### Issue Tracking - [ ] [Apache NiFi Jira](https://issues.apache.org/jira/browse/NIFI) issue created ### Pull Request Tracking - [ ] Pull Request title starts with Apache NiFi Jira issue number, such as `NIFI-0` - [ ] Pull Request commit message starts with Apache NiFi Jira issue number, as such `NIFI-0` ### Pull Request Formatting - [ ] Pull Request based on current revision of the `main` branch - [ ] Pull Request refers to a feature branch with one commit containing changes # Verification Please indicate the verification steps performed prior to pull request creation. ### Build - [ ] Build completed using `mvn clean install -P contrib-check` - [ ] JDK 21 ### UI Contributions - [ ] NiFi is modernizing its UI. Any contributions that update the [current UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-ui) also need to be implemented in the [new UI](https://github.com/apache/nifi/tree/main/nifi-framework-bundle/nifi-framework/nifi-web/nifi-web-frontend/src/main/nifi). ### 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 - [ ] 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] [Commented] (NIFI-13340) Flowfiles stopped to be ingested before a processor group
[
https://issues.apache.org/jira/browse/NIFI-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17851707#comment-17851707
]
Joe Witt commented on NIFI-13340:
-
Hello can you take a look at https://issues.apache.org/jira/browse/NIFI-13281
and let us know if this sounds similar?
> Flowfiles stopped to be ingested before a processor group
> -
>
> Key: NIFI-13340
> URL: https://issues.apache.org/jira/browse/NIFI-13340
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.25.0
> Environment: Host OS :ubuntu 20.04 in wsl
> CPU: Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz
> RAM: 128GB
> ZFS ARC cache was configured to be maximum 4 GB
>Reporter: Yuanhao Zhu
>Priority: Major
> Labels: data-consistency, statestore
> Attachments: image-2024-06-03-14-42-37-280.png,
> image-2024-06-03-14-44-15-590.png
>
>
> *Background:* We run nifi as a standalone instance in a docker container in
> on all our stages, the statemanagement provider used by our instance is the
> local WAL backed provider.
> {*}Description{*}: We observed that the flowfiles in front of one of our
> processor groups stopped to be ingested once in a while and it happens on all
> our stages without noticeable pattern. The flowfile concurrency policy of the
> processor group that stopped ingesting data is set to SINGLE_BATCH_PER_NODE
> and the outbound policy is set to BATCH_OUTPUT. The ingestion should continue
> since the processor group had already send out every flowfile in it, but it
> stopped.
>
> There is only one brutal solution from our side(We need to delete the
> processor group and restore it from nifi registry again) and the occurrence
> of this issue had impacted our data ingestion.
> !image-2024-06-03-14-42-37-280.png!
> !image-2024-06-03-14-44-15-590.png!
> As you can see in the screenshot that the processor group 'Delete before
> Insert' has no more flowfile to output but still it does not ingest the data
> queued in the input port
>
> {{In the log file I found the following:}}
>
> {code:java}
> 2024-06-03 11:34:01,772 TRACE [Timer-Driven Process Thread-15]
> o.apache.nifi.groups.StandardDataValve Will not allow data to flow into
> StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert] because Outbound Policy is Batch Output and valve is already
> open to allow data to flow out of group{code}
>
> {{ }}
> {{Also in the diagnostics, I found the following for the 'Delete before
> Insert' processor group:}}
> {{ }}
> {code:java}
> Process Group e6510a87-aa78-3268-1b11-3c310f0ad144, Name = Search and Delete
> existing reports(This is the parent processor group of the Delete before
> Insert)
> Currently Have Data Flowing In: []
> Currently Have Data Flowing Out:
> [StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert]]
> Reason for Not allowing data to flow in:
> Data Valve is already allowing data to flow out of group:
>
> StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert]
> Reason for Not allowing data to flow out:
> Output is Allowed:
>
> StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert] {code}
> {{ }}
> {{Which is clearly {*}not correct{*}. since there are currently not data
> flowing out from the 'Delete before Insert' processor group.}}
> {{ }}
> {{We dig through the source code of StandardDataValve.java and found that
> that data valve's states are stored every time the data valve is opened and
> close so the potential reason causing this issue is that the processor group
> id was put into the statemap when data flowed in but somehow the removal of
> the entry was not successful. We are aware that if the statemap is not stored
> before the nifi restarts, it could lead to such circumstances, but in the
> recent occurrences of this issue, there were not nifi restart recorded or
> observed at the time when all those flowfiles started to queue in front of
> the processor group}}
> {{ }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (NIFI-13340) Flowfiles stopped to be ingested before a processor group
[
https://issues.apache.org/jira/browse/NIFI-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joe Witt updated NIFI-13340:
Priority: Major (was: Blocker)
> Flowfiles stopped to be ingested before a processor group
> -
>
> Key: NIFI-13340
> URL: https://issues.apache.org/jira/browse/NIFI-13340
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
>Affects Versions: 1.25.0
> Environment: Host OS :ubuntu 20.04 in wsl
> CPU: Intel(R) Xeon(R) Platinum 8370C CPU @ 2.80GHz
> RAM: 128GB
> ZFS ARC cache was configured to be maximum 4 GB
>Reporter: Yuanhao Zhu
>Priority: Major
> Labels: data-consistency, statestore
> Attachments: image-2024-06-03-14-42-37-280.png,
> image-2024-06-03-14-44-15-590.png
>
>
> *Background:* We run nifi as a standalone instance in a docker container in
> on all our stages, the statemanagement provider used by our instance is the
> local WAL backed provider.
> {*}Description{*}: We observed that the flowfiles in front of one of our
> processor groups stopped to be ingested once in a while and it happens on all
> our stages without noticeable pattern. The flowfile concurrency policy of the
> processor group that stopped ingesting data is set to SINGLE_BATCH_PER_NODE
> and the outbound policy is set to BATCH_OUTPUT. The ingestion should continue
> since the processor group had already send out every flowfile in it, but it
> stopped.
>
> There is only one brutal solution from our side(We need to delete the
> processor group and restore it from nifi registry again) and the occurrence
> of this issue had impacted our data ingestion.
> !image-2024-06-03-14-42-37-280.png!
> !image-2024-06-03-14-44-15-590.png!
> As you can see in the screenshot that the processor group 'Delete before
> Insert' has no more flowfile to output but still it does not ingest the data
> queued in the input port
>
> {{In the log file I found the following:}}
>
> {code:java}
> 2024-06-03 11:34:01,772 TRACE [Timer-Driven Process Thread-15]
> o.apache.nifi.groups.StandardDataValve Will not allow data to flow into
> StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert] because Outbound Policy is Batch Output and valve is already
> open to allow data to flow out of group{code}
>
> {{ }}
> {{Also in the diagnostics, I found the following for the 'Delete before
> Insert' processor group:}}
> {{ }}
> {code:java}
> Process Group e6510a87-aa78-3268-1b11-3c310f0ad144, Name = Search and Delete
> existing reports(This is the parent processor group of the Delete before
> Insert)
> Currently Have Data Flowing In: []
> Currently Have Data Flowing Out:
> [StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert]]
> Reason for Not allowing data to flow in:
> Data Valve is already allowing data to flow out of group:
>
> StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert]
> Reason for Not allowing data to flow out:
> Output is Allowed:
>
> StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
> before Insert] {code}
> {{ }}
> {{Which is clearly {*}not correct{*}. since there are currently not data
> flowing out from the 'Delete before Insert' processor group.}}
> {{ }}
> {{We dig through the source code of StandardDataValve.java and found that
> that data valve's states are stored every time the data valve is opened and
> close so the potential reason causing this issue is that the processor group
> id was put into the statemap when data flowed in but somehow the removal of
> the entry was not successful. We are aware that if the statemap is not stored
> before the nifi restarts, it could lead to such circumstances, but in the
> recent occurrences of this issue, there were not nifi restart recorded or
> observed at the time when all those flowfiles started to queue in front of
> the processor group}}
> {{ }}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
Re: [PR] NIFI-13323 Removed the instantiation of Object arrays for arguments in ComponentLog log in the HashAttribute and PostHttp Processors. [nifi]
exceptionfactory commented on PR #8903:
URL: https://github.com/apache/nifi/pull/8903#issuecomment-2145580852
> @exceptionfactory In `PutElasticsearchHttp` on line 252 `logger.error("No
value for index in for {}, transferring to failure", id_attribute, file);`
there is only one parameter (`{}`) specified in the logging statement yet there
are two parameter arguments ( `id_attribute, file`) given.
>
> should the log statement be `logger.error("No value for index in {} for
{}, transferring to failure", id_attribute, file);` ?
@dan-s1 On further consideration, I'm not sure it is worth back-porting this
change. Especially for this type of syntax change, there is very little value
in bringing it over, given the current focus on getting 2.0 finalized.
--
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
Re: [PR] NIFI-13323 Removed the instantiation of Object arrays for arguments in ComponentLog log in the HashAttribute and PostHttp Processors. [nifi]
dan-s1 commented on PR #8903:
URL: https://github.com/apache/nifi/pull/8903#issuecomment-2145550691
@exceptionfactory In `PutElasticsearchHttp` on line 252
`logger.error("No value for index in for {}, transferring to failure",
id_attribute, file);`
there is only one parameter (`{}`) specified in the logging statement yet
there are two parameter arguments ( `id_attribute, file`) given. Can you please
advise where does the other parameter in the logging statement go? 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
Re: [PR] NIFI-13313: Remove old UI [nifi]
mcgilman commented on PR #8906: URL: https://github.com/apache/nifi/pull/8906#issuecomment-2145545377 > Interested in your thoughts on this. Thanks for your comments! In my experience there is too much coordination between the front and back end to use PathLocationStrategy with dynamic context paths. That said, I'm sure we can we could figure it out using the technique referenced (where the server transforms the page when served) or possibly another approach. HashLocationStrategy completely decouples these concerns as the front end route is never even sent to the server. 2.0.0-M3 is released with HashLocationStrategy in place and if there is any feedback regarding it we could certainly evaluate the alternative. -- 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
[PR] MINIFICPP-2368 Add sensitive parameter support [nifi-minifi-cpp]
lordgamez opened a new pull request, #1806: URL: https://github.com/apache/nifi-minifi-cpp/pull/1806 https://issues.apache.org/jira/browse/MINIFICPP-2368 Depends on https://github.com/apache/nifi-minifi-cpp/pull/1792 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] (NIFI-13340) Flowfiles stopped to be ingested before a processor group
[
https://issues.apache.org/jira/browse/NIFI-13340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuanhao Zhu updated NIFI-13340:
---
Description:
*Background:* We run nifi as a standalone instance in a docker container in on
all our stages, the statemanagement provider used by our instance is the local
WAL backed provider.
{*}Description{*}: We observed that the flowfiles in front of one of our
processor groups stopped to be ingested once in a while and it happens on all
our stages without noticeable pattern. The flowfile concurrency policy of the
processor group that stopped ingesting data is set to SINGLE_BATCH_PER_NODE and
the outbound policy is set to BATCH_OUTPUT. The ingestion should continue since
the processor group had already send out every flowfile in it, but it stopped.
There is only one brutal solution from our side(We need to delete the processor
group and restore it from nifi registry again) and the occurrence of this issue
had impacted our data ingestion.
!image-2024-06-03-14-42-37-280.png!
!image-2024-06-03-14-44-15-590.png!
As you can see in the screenshot that the processor group 'Delete before
Insert' has no more flowfile to output but still it does not ingest the data
queued in the input port
{{In the log file I found the following:}}
{code:java}
2024-06-03 11:34:01,772 TRACE [Timer-Driven Process Thread-15]
o.apache.nifi.groups.StandardDataValve Will not allow data to flow into
StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
before Insert] because Outbound Policy is Batch Output and valve is already
open to allow data to flow out of group{code}
{{ }}
{{Also in the diagnostics, I found the following for the 'Delete before Insert'
processor group:}}
{{ }}
{code:java}
Process Group e6510a87-aa78-3268-1b11-3c310f0ad144, Name = Search and Delete
existing reports(This is the parent processor group of the Delete before Insert)
Currently Have Data Flowing In: []
Currently Have Data Flowing Out:
[StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
before Insert]]
Reason for Not allowing data to flow in:
Data Valve is already allowing data to flow out of group:
StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
before Insert]
Reason for Not allowing data to flow out:
Output is Allowed:
StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
before Insert] {code}
{{ }}
{{Which is clearly {*}not correct{*}. since there are currently not data
flowing out from the 'Delete before Insert' processor group.}}
{{ }}
{{We dig through the source code of StandardDataValve.java and found that that
data valve's states are stored every time the data valve is opened and close so
the potential reason causing this issue is that the processor group id was put
into the statemap when data flowed in but somehow the removal of the entry was
not successful. We are aware that if the statemap is not stored before the nifi
restarts, it could lead to such circumstances, but in the recent occurrences of
this issue, there were not nifi restart recorded or observed at the time when
all those flowfiles started to queue in front of the processor group}}
{{ }}
was:
*Background:* We run nifi as a standalone instance in a docker container in on
all our stages, the statemanagement provider used by our instance is the local
WAL backed provider.
{*}Description{*}: We observed that the flowfiles in front of one of our
processor groups stopped to be ingested once in a while and it happens on all
our stages without noticeable pattern. The flowfile concurrency policy of the
processor group that stopped ingesting data is set to SINGLE_BATCH_PER_NODE and
the outbound policy is set to BATCH_OUTPUT. The ingestion should continue since
the processor group had already send out every flowfile in it, but it stopped.
There is only one brutal solution from our side(We have to manually switch the
flowfile concurrency to unbounded and then switch it back to make it work
again) and the occurrence of this issue had impacted our data ingestion.
!image-2024-06-03-14-42-37-280.png!
!image-2024-06-03-14-44-15-590.png!
As you can see in the screenshot that the processor group 'Delete before
Insert' has no more flowfile to output but still it does not ingest the data
queued in the input port
{{In the log file I found the following:}}
{code:java}
2024-06-03 11:34:01,772 TRACE [Timer-Driven Process Thread-15]
o.apache.nifi.groups.StandardDataValve Will not allow data to flow into
StandardProcessGroup[identifier=5eb0ad69-e8ed-3ba0-52da-af94fb9836cd,name=Delete
before Insert] because Outbound Policy is Batch Output and valve is already
open to allow data to flow out of group{code}
{{ }}
{{Also in the diagnostics, I found the following for the 'Delete before Insert'
Re: [PR] MINIFICPP-2388 Fix warnings on Windows build [nifi-minifi-cpp]
szaszm commented on code in PR #1805:
URL: https://github.com/apache/nifi-minifi-cpp/pull/1805#discussion_r1624596338
##
extensions/expression-language/CMakeLists.txt:
##
@@ -96,20 +96,22 @@ find_package(FLEX REQUIRED)
bison_target(
el-parser
${CMAKE_CURRENT_SOURCE_DIR}/Parser.yy
-${CMAKE_CURRENT_SOURCE_DIR}/Parser.cpp
+${CMAKE_CURRENT_SOURCE_DIR}/el-parser/Parser.cpp
)
flex_target(
el-scanner
${CMAKE_CURRENT_SOURCE_DIR}/Scanner.ll
-${CMAKE_CURRENT_SOURCE_DIR}/Scanner.cpp
+${CMAKE_CURRENT_SOURCE_DIR}/el-scanner/Scanner.cpp
COMPILE_FLAGS --c++
)
add_flex_bison_dependency(el-scanner el-parser)
include_directories(./ ../../libminifi/include ../../libminifi/include/core)
include_directories(SYSTEM ../../thirdparty/)
+include_directories(SYSTEM el-parser)
+include_directories(SYSTEM el-scanner)
Review Comment:
Ok, got it. But I still thing that we should not add directory-based include
paths, and add them to each target as necessary. It would also be nicer to
generate these files under the build directory, instead of the source tree.
--
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] (NIFI-13341) Update BinFiles not to write attributes to FlowFiles for auto-terminated relationship
[ https://issues.apache.org/jira/browse/NIFI-13341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Steinebrey reassigned NIFI-13341: - Assignee: Jim Steinebrey > Update BinFiles not to write attributes to FlowFiles for auto-terminated > relationship > - > > Key: NIFI-13341 > URL: https://issues.apache.org/jira/browse/NIFI-13341 > Project: Apache NiFi > Issue Type: Improvement > Components: Extensions >Affects Versions: 1.26.0, 2.0.0-M3 >Reporter: Jim Steinebrey >Assignee: Jim Steinebrey >Priority: Major > > NIFI-13196 introduces the ability to check if a relationship is > auto-terminated. In the case of BinFiles (which is extended by MergeContent > and JoinEnrichment processors), the processor can have the REL_ORIGINAL > auto-terminated. When it is auto-terminated, skip copying attributes into the > flow files which are being auto-terminated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (NIFI-13341) Update BinFiles not to write attributes to FlowFiles for auto-terminated relationship
Jim Steinebrey created NIFI-13341: - Summary: Update BinFiles not to write attributes to FlowFiles for auto-terminated relationship Key: NIFI-13341 URL: https://issues.apache.org/jira/browse/NIFI-13341 Project: Apache NiFi Issue Type: Improvement Components: Extensions Affects Versions: 2.0.0-M3, 1.26.0 Reporter: Jim Steinebrey NIFI-13196 introduces the ability to check if a relationship is auto-terminated. In the case of BinFiles (which is extended by MergeContent and JoinEnrichment processors), the processor can have the REL_ORIGINAL auto-terminated. When it is auto-terminated, skip copying attributes into the flow files which are being auto-terminated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [PR] NIFI-13323 Removed the instantiation of Object arrays for arguments in ComponentLog log in the HashAttribute and PostHttp Processors. [nifi]
exceptionfactory commented on PR #8903: URL: https://github.com/apache/nifi/pull/8903#issuecomment-2145386908 > @exceptionfactory I just thought a review of ~300 files may be too big for one review. I see, thanks for the consideration. It is large, but we have had larger, and for something like this, it seems acceptable to bundle the changes together. -- 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
Re: [PR] MINIFICPP-2388 Fix warnings on Windows build [nifi-minifi-cpp]
lordgamez commented on code in PR #1805: URL: https://github.com/apache/nifi-minifi-cpp/pull/1805#discussion_r1624584513 ## .gitignore: ## @@ -65,6 +65,12 @@ __pycache__/ /provenance_repository /logs msi/WixWin.wsi +extensions/expression-language/el-scanner/Scanner.cpp +extensions/expression-language/el-parser/Parser.cpp +extensions/expression-language/el-parser/Parser.hpp +extensions/expression-language/el-parser/location.hh +extensions/expression-language/el-parser/position.hh +extensions/expression-language/el-parser/stack.hh Review Comment: In the first draft el-scanner and el-parser directories were not part of the repository as they were only created at build time with the generated files. As CPPLINT.cfg is now also added in those directories I think you are right, I'll add the .gitignore files there as well. -- 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
