Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

Just as a point of discussion, I'm not entirely sure that splitting into multiple physical git repositories is actually adding any value. I think it's worth consideration that all the (good) changes being proposed are done under a single mono-repository model. If we split into multiple repositori

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

can maintain that. > > in any event im not making a statement of whether to do many repos or not. > just correcting some potentially misleading claims. > > thanks > > On Fri, Jul 12, 2019, 12:01 PM Adam Taft wrote: > > > Just as a point of discussion, I'm not enti

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

; different convenience binaries resulting from a single source release > artifact though. > > Thanks > > On Fri, Jul 12, 2019 at 12:26 PM Adam Taft wrote: > > > I think the concerns around user management are valid, are they not? > > Overhead in JIRA goes up (assig

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

t; > long-term goal. I think this project restructuring won't solve the > > problem completely (in fact, to your point, it may uncover some > > unfortunate tight-coupling that needs to be reworked on the current > > master before the split can happen), but I do think it will

Re: [EXT] [discuss] Splitting NiFi framework and extension repos and releases

t to a single repository which influences behavior in > all three modules and requires one or more reviewers with comprehensive > knowledge over all aspects of the project. > > > Andy LoPresto > alopre...@apache.org > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A

Re: Maven Build Error - nifi-properties-loader sub-project test failures

Aram, Just to rule out the obvious ... Can you update your Maven and Java versions, which would include: - Maven 3.6.2 - Java 1.8.0_222 Also, are you including a MAVEN_OPTS environment to increase your JVM memory in Maven? $> export MAVEN_OPTS="-Xms1g -Xmx3g" Thanks, Adam On Wed, Oct 9, 2019

Re: Maven Build Error - nifi-properties-loader sub-project test failures

to what we suggest here: > http://nifi.apache.org/quickstart.html > > It seems like it is reading material from files (test files) and they don't > contain what is expected so I wonder about git settings. > > Thanks > Joe > > On Thu, Oct 10, 2019 at 1:10 AM Adam Taft

Re: Maven Build Error - nifi-properties-loader sub-project test failures

t; Upgrading my Java-JDK install version to *1.8.0_222* and Maven to *3.6.2* > did indeed *fix my build issue*! > > Aram S. Openden > aram.open...@gmail.com > > > > On Thu, Oct 10, 2019 at 1:10 AM Adam Taft wrote: > > > Aram, > > > > Just to rule out th

Re: PULL ProvenanceEvent

Nissim, Just to be clear, you are trying to distinguish between processors which are actively "pulling" data (GetXYZ) vs. processors which just "listen" for data (ListenXYZ)? Is that your basic vision? GetFile => PULL GetHTTP => PULL ListenHTTP => RECEIVE ListenTCP => RECEIVE Could you clarify

Re: Release vote helper docker setups

In general I like this idea. I'd like to even suggest a possibly broader vision that aims towards a more stable build environment that would be the "reference" environment for building NiFi. I have been kicking around and looking at a Docker based build environment for NiFi. The idea is that you

Re: PULL ProvenanceEvent

ion." > Thanks, > Nissim > > On Friday, October 11, 2019, 11:30:19 AM EDT, Nissim Shiman > wrote: > > Adam, > "Yes" to your first question and the four processor examples you listed. > > I will need to get back to you regarding your other points. &

Java 11 Compilation

While building 1.10.0-rc3, I wanted to experiment with the compilation and runtime variants using Java 8 and Java 11. The summary of this experiment was: Comp: Java 8 Run: Java 8 => SUCCESS Comp: Java 8 Run: Java 11 => SUCCESS Comp: Java 11 Run: Java 8 => FAILURE Comp: Java 11 Run: Jav

Re: [VOTE] Release Apache NiFi 1.10.0 (rc3)

+1 (binding) Signatures verified. Hashes verified. Tests pass, source builds cleanly. I used both Java 11 & Java 8 to build. I did run into a problem compiling with Java 11 and running with Java 8. I don't believe this was a goal of the Java 11 compatibility changes, so nothing unexpected about

Re: Java 11 Compilation

est stable Java at that > time (11, 13) > > thanks > > On Wed, Oct 30, 2019 at 12:51 PM Adam Taft wrote: > > > While building 1.10.0-rc3, I wanted to experiment with the compilation > and > > runtime variants using Java 8 and Java 11. The summary of this > experime

Re: invokeHttp routing of exceptions like ConnectException and IOException to failure instead of retry

Hi David, *> "What is the reasoning for routing them to failure instead of retry?"* Good question ... HTTP status codes give good hints as to what a client should do for retry/no-retry operations. Generally 400 error codes do not get retried, 500 codes get retried, etc. It doesn't, however, giv

Re: PULL ProvenanceEvent

e this distinction be > on > > > the > > > > "RECEIVE" event as a metadata item specifying active vs passive. The > > > > protocol utilized as mentioned in the transport URI should clarify > this > > > > though. > > > > > > > > In short - i think there is a

Re: [DISCUSS] NiFi 2.0 Release Goals

I'm not seeing the side thread that was going to discuss deprecation of PostHTTP. Has that thread started and I just don't see it? One (significant?) concern with PostHTTP is the smooth integration of NiFi-to-NiFi communication that is very transparently enabled with the ListenHTTP and PostHTTP p

Re: [DISCUSS] NiFi 2.0 Release Goals

ase and we cannot > make it a pain for users. We got away with things at 0.x to 1.0 that we > cannot get away with on 2.0 > > Thanks > > On Fri, Jul 30, 2021 at 3:41 PM Adam Taft wrote: > > > I'm not seeing the side thread that was going to discuss deprecation of >

Re: Using nifi in separated networks

Marc, How would this differ from a more generic use of the existing processors, PutTCP/ListentTCP and PutUDP/ListenUDP? I'm not sure what value is being added above these existing processors, but I'm sure I'm missing something. There's already an ability to serialize flowfiles via MergeContent.

Re: Using nifi in separated networks

you must be > fast, very fast. It is a multithreaded architecture because one thread > cannot receive, decode, and write a gigabit per second. I used the > disruptor library. Receive a packet in one thread, decode it in another > thread. A third thread gets the packet and write the content

Re: nifi-0.3.0 release

This issue, from my perspective, somewhat speaks to the "maturity model" surrounding an open source community. If NiFi is to be considered a "stable and mature" product, such that any minor point release is considered supported and usable for production purposes, then a 0.2.1 release should most d

Re: nifi error

One possible option to help on this might be to commit a .gitattributes file, which would basically name the problematic test files and mark them to not modify their line endings. http://git-scm.com/docs/gitattributes I think the format would look something like: /path/to/problematic/test/file -

Re: Fetch change list

Some additional feature requests for sake of consideration... For some file systems (I can think of one), the last modified date may not be dependable or possibly not high enough precision. Additional strategies could be considered for determining whether a file has been previously processed. Fo

Re: Fetch change list

t; > > > Joe > > > > On Wed, Jul 29, 2015 at 10:31 AM, Joe Witt wrote: > > > > > Turning noatime on kicks last mod out the window. It is for sure the > > > case when dealing with file IO that there really are no rules. As > > > Adam notes it is ab

Re: Route Original Flow File Base on InvokeHTTP Response

If you're needing to read the HTTP response code, InvokeHTTP should do this for you. It basically stores the HTTP response code into the original request flowfile. With a 2xx response code, it will route the request flowfile (with the response code attributes) to the "Original" relationship. Fro

Re: Route Original Flow File Base on InvokeHTTP Response

Right. Fundamentally, with InvokeHTTP you have two flowfiles involved. The original flowfile which represents the HTTP request, and a newly created "response" flowfile which captures the message body from the response. After invoke HTTP does its thing, you are effectively left with two flowfiles.

Re: Route Original Flow File Base on InvokeHTTP Response

One option I think we kicked around at some point was to capture the response body as a flowfile attribute in the original flowfile. For reasonably sized response bodies, this would work OK. It would be a nice way to handle your situation, because then the response becomes an attribute of the req

Re: [DISCUSS] Feature proposal: Read-only mode as default

Alternative suggestion: undo It shouldn't be too hard to keep multiple diffs of the flow.xml around to allow for some sort of undo capabilities. What are the thoughts or concerns for supporting undo? On Fri, Aug 7, 2015 at 10:31 PM, Joe Witt wrote: > Team, > > We've been hearing from users of

Re: [DISCUSS] Feature proposal: Read-only mode as default

Thinking about it some more, I don't mind the concept of "read only" toggle. Maybe it's not set by default, but it could be a really easy UI element to add somewhere. Just a little slider-toggle element. [1] In theory, this might be a UI only feature, it wouldn't strictly need support in the bac

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

The difficulties of using the gitflow workflow and the release process can be significantly reduced with good tooling. I'm currently using the jgit-flow [1][2] maven plugin with very good success. It handles and manages feature, release, and hotfix branches seemlessly. And it avoids common probl

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

The default branch is not a feature of GitHub, GitLab, etc. It's a feature of git itself. On the 'bare' repository, issue this command: git symbolic-ref HEAD refs/heads/*mybranch* Effectively, this is what GitHub is doing. It should be possible to do with the Apache git host as well. On Thu

Re: [DISCUSS] Removal of the 'master' vs 'develop' distinction

ded to this having value. That is why i was supportive > of the idea back in Nov/Dec. But over the past 8 months or so I've > only seen it as an 'extra step' for an already difficult RM task and > as something that creates confusion. > > So for me, this is an easy discuss

Re: [VOTE] Release Apache NiFi nifi-nar-maven-plugin 1.1.0

+1 - Validated source signature, hashes, licensing. Nar plugin compiles and builds nifi-0.3.0-SNAPSHOT without problem on Mac 10.10.4 with JDK 8u60, maven 3.3.3. Running -Dmode=tree against the standard-nar results in: [INFO] --- nifi-nar-maven-plugin:1.1.0:provided-nar-dependencies (default-cli

Re: Source code for Version 0.3.0

What's the thoughts on creating a proper 0.3.0 tag, as would be traditional for a final release? It is arguably a little confusing to only have the RC tags, when looking for the final release. I found this head scratching for 0.2.0 as well. Adam On Mon, Sep 21, 2015 at 7:44 AM, Esteban Alivert

Re: Source code for Version 0.3.0

roper release tag, signed by the RM on passage of the release vote. I > >> don't recall off-hand what the phrasing was in the VOTE thread (if > >> any). > >> > >> On Mon, Sep 21, 2015 at 8:13 AM, Adam Taft wrote: > >>> > >>> What's t

Re: Common data exchange formats and tabular data

CSV (and friends like TSV, PSV, etc.) are obviously very naturally oriented to representing tabular data. I don't know that there would be a lot of value using/inventing a JSON or AVRO format in place of CSV for tabular data The only slight advantage might be maintaining type information, which J

Re: LogAttribute - Sending that output to a custom logger?

This thread has forked into two different conversations: 1. improvements to LogAttribute processor; 2. improvements to processor documentation. 1) re: improvements to LogAttribute - we already have NIFI-67 [1] that suggests a number of improvements to LogAttribute. One of these is the use of a

Re: LogAttribute - Sending that output to a custom logger?

HTC > > > - Reply message - > From: "Adam Taft" > Date: Mon, Nov 2, 2015 19:23 > Subject: LogAttribute - Sending that output to a custom logger? > To: > > This thread has forked into two different conversations: 1. improvements > to LogAttribute

Re: Incorporation of other Maven repositories

I'm concerned that not all networks will be able to connect with and use the JCenter repository. If it's not in Maven Central, we should likely avoid the dependency and instead find alternative approaches. Adam On Fri, Nov 6, 2015 at 11:31 AM, Joe Witt wrote: > joe explained to me he meant t

Re: Incorporation of other Maven repositories

t are some examples of networks which can access maven central but > > > cannot access JCenter? > > > > > > Thanks > > > Joe > > > > > > On Fri, Nov 6, 2015 at 12:10 PM, Adam Taft wrote: > > >> I'm concerned that not all n

Re: ExecuteStreamCommand tests

git revert is your friend. https://git-scm.com/docs/git-revert It's not "rollback" -- it's another new commit with the changes reinstated. On Thu, Nov 12, 2015 at 5:45 PM, Joe Witt wrote: > ok - will undo the commit. I get to learn a new git trick? Or just > add them back? I must admit I'm

Re: Keep Files

Also, as a potential work-around, it's possible to use GetFile with "delete" mode and then somewhere in your flow, use PutFile to place the file back down into a "complete" directory. i.e. something like: /path/incoming <- use GetFile to pick up files here /path/complete <- use PutFile to place

Re: Keep Files

t; /data/input_links/, and set Keep Source File to False. When the GetFile > processor picks up the file, it'll read the contents and create a flowfile > by following the symlink, delete the symlink, and the original file will > remain in /data/input_files. > > On Mon, Nov 16, 2015

Re: remote command execution via SSH?

Right. As an example, I'm currently using ExecuteCommand to transfer data over an SSH pipe. I'm actually transferring data from a NiFi dataflow* to an HDFS cluster, using something like: Command Path: bash Command Arguments: -c; ssh $host 'hadoop fs -appendToFile - /path/to/hdfs/file' For som

Re: remote command execution via SSH?

Sumo, On Tue, Nov 24, 2015 at 10:27 PM, Sumanth Chinthagunta wrote: > I think you guys may have configured password less login for SSH (keys?) > ​Correct. I'm using SSH key exchange for authentication. It's usually done password-less, true, but it doesn't necessarily have to be (if using ssh

Re: absolute.path vs path for FetchFile/ListFile

+1 to Mark's idea. Having both attributes might be nice and probably doesn't hurt anything. The convenience of having a relative path is that you can munge it or add prefixes to it more easily via the expression language. An absolute path would somewhat be more difficult to work with, if you wan

Re: GetHTTP processor error

URL Encoding in Java is properly done through the URI interface, particularly when using this[1] constructor: URI(String scheme, String userInfo, String

Re: NiFi 0.4.1 InvokeHttp processor POST error issue

Joe, Just as a quick observation, this statement isn't completely accurate: > "... and can stream the contents instead of loading into memory" The original InvokeHTTP code (pre okhttp) explicitly set the content-length header, because it was known (the flowfile payload content length is always k

Re: NiFi 0.4.1 InvokeHttp processor POST error issue

the "Use Chunked Encoding" > property will false. > [1] > https://github.com/square/okhttp/blob/parent-2.7.1/okhttp/src/main/java/com/squareup/okhttp/Call.java#L263[2] > https://issues.apache.org/jira/browse/NIFI-1405 > Joe - - - - - - > Joseph Percivall > li

Re: Are we thinking about Penalization all wrong?

If we're willing to have a LoopFlowFile processor, why not consider a PenalizeFlowFile processor too? Just throwing it out for discussions sake, but penalization could ultimately be realized in multiple ways: a) by both the processor developer (and DFM via penalty duration), as it is done today;

Re: [DISCUSS] git branching model

One of the harder things with gitflow is using it in combination with maven. It's ideal that the tags and releases are tracking closely with the maven pom.xml version. gitflow, on its own, doesn't keep the pom version updated with the git release names. Because of the general importance of keepi

Re: InvokeHTTP body

I think it makes total sense that POST/PUT requests read from the flowfile content. Therefore, the problem should be fixed further up in the flow design. For example, try these solutions: GenerateFlowFile -> ReplaceText -> InvokeHTTP (or) GetFile -> InvokeHTTP The problem you're describing ha

Re: Processor: User friendly vs system friendly design

I'm probably on the far end of favoring composibility and processor reuse. In this case, I would even go one step further and suggest that you're talking about three separate operations: 1. Split a multi-line CSV input file into individual single line flowfiles. 2. Read columns from a single CSV

Re: Processor: User friendly vs system friendly design

how to access attributes from code? > > once I have something usable or for testing where would I publish it? just > on my github site? or is there a place for sharing? > > greetings > > Uwe > > > > Gesendet: Freitag, 18. März 2016 um 18:03 Uhr > Von: "Ada

Re: Re: Processor: User friendly vs system friendly design

r row >> TemplateProcessor: > ​​ > split row into fields and merge with template >> MergeContent: merge > flowfiles into one >> PutFile: put the file to the filesystem > > Example result: > > { > "name": "Peterson", >

Re: Dynamic URLs using InvokeHttp from an array

One (possibly bad) idea would be to try and loop your flow around the UpdateAttribute processor using RouteOnAttribute. UpdateAttribute has an "advanced" mode which would let you do logic something like: if $foo == "" then set $foo = "step 1"; if $foo == "step 1" then set $foo = "step 2"; if $foo

Re: Dynamic URLs using InvokeHttp from an array

ribute, you'd end up with 10 flowfiles that could be sent to InvokeHTTP. That might be a fun way to solve this. :) On Thu, Mar 31, 2016 at 9:55 AM, Adam Taft wrote: > One (possibly bad) idea would be to try and loop your flow around the > UpdateAttribute processor using RouteOnAttribute.

Re: Dynamic URLs using InvokeHttp from an array

Yeah, these solutions won't work for thousands of iterations. Andy's suggestion for using ExecuteScript starts to sound very compelling, especially if you are algorithmically generating your term values. Another thought for you. Uwe Geercken was experimenting with a processor which could read in

Re: Dynamic URLs using InvokeHttp from an array

You are probably missing the necessary change to the following file: META-INF/services/org.apache.nifi.processor.Processor ​If you haven't modified this file to include your processor, this would be the problem. Adam ​ On Fri, Apr 1, 2016 at 2:53 PM, kkang wrote: > I looked into the links, b

Re: [VOTE] Release Apache NiFi 1.3.0

I'm getting a test failure for this RC. Here is the maven snippet. --- T E S T S --- Running org.apache.nifi.provenance.CryptoUtilsTest Tests run: 16, Failures: 1, Errors: 0, Skipped: 0, Time

Re: [VOTE] Release Apache NiFi 1.3.0

ing a disposable Docker container). > > NIFI-3836 is open for it. > > If this is what it is, just build as a non root user. > > > On Jun 5, 2017, at 5:25 PM, Adam Taft wrote: > > > > I'm getting

Re: [VOTE] Release Apache NiFi 0.7.4

+1 (binding) Verified gpg signature. Verified all hashes on source zipfile. Performed mvn clean install -Pcontrib-checks Builds cleanly, all tests pass in docker container centos:latest w/ openjdk-1.8.0 and maven 3.5.0 LICENSE, NOTICE, README look good. Binary runs as expected with a simple datafl

Re: [VOTE] Release Apache NiFi 1.3.0

ion":83 ? NullPointer StandardFlowSynchronizerSpec.scaling of #filename with encoding version "#flowEncodingVersion":83 ? NullPointer StandardFlowSynchronizerSpec.scaling of #filename with encoding version "#flowEncodingVersion":83 ? NullPointer StandardFlowSynchronizerSpec.scaling o

Re: How to ingest files into HDFS via Apache NiFi from non-hadoop environment

This is a bit outside of the box, but I have actually implemented this solution previously. My scenario was very similar. NIFI was installed outside of the firewalled HDFS cluster. The only external access to the HDFS cluster was through SSH. Therefore, my solution was to use SSH to call a remo

Re: Does PostHTTP support Multipart/form-data ?

The multipart/form-data body would have to be preemptively created and stored in your flowfile payload. InvokeHTTP could then be used to POST the message body to the remote server (after having set the appropriate content-type). i.e. you have to manually construct the multipart form in the flowfi

Re: [EXT] Re: [DISCUSS} Closing in on a NiFi 1.4.0 release?

Here's another good link to try, maybe a little easier to read: https://issues.apache.org/jira/projects/NIFI/versions/12340589 On Wed, Sep 20, 2017 at 8:01 AM, Brandon DeVries wrote: > Mayank, > > Try this: > > https://issues.apache.org/jira/issues/?jql=project%20% > 3D%20NIFI%20AND%20fixVers

Re: Dockerfile and Docker Hub Management

Aldrin, +1 to separate repository (bullet #2). The basic premise that Docker releases should happen separate from the main distribution is spot on. I think a separate repository would help keep this separation. I tend to believe that the future of NiFi distributions will be via containerization.

Re: About NIFI-3620: Multipart support in invokeHTTP.java

Multipart is just a set of related content types (multipart/form-data, multipart/mixed). InvokeHTTP doesn't care too much about content types, it just sends bytes verbatim from the flowfile payload. What should be considered is for an upstream processor to create the multipart payload in the flow

Re: [DISCUSS] Apache NiFi distribution has grown too large

I'd also vote for an OSGi backend (in the long term). It's something that has been on my mind (and mentioned) for years now. The Nar classloader ecosystem is trying to implement features of OSGi (and doing it somewhat poorly at that, if you are honest). Not saying that OSGi is the right solution

Re: [GitHub] nifi issue #272: NIFI-1620 Allow empty Content-Type in InvokeHTTP processor

I added a comment to the JIRA ticket associated with this pull request. I think there should be discussion / buy-in from others on the aestetics of introducing a new processor property for this edge case. Instead, I think the goals of this request could be fulfilled without strictly introducing a

Re: PostHTTP Penalize file on HTTP 5xx response

In the wild west of HTTP response codes, a 500 Server Error could mean practically anything. In my experience, you can't infer any semantic meaning for what a 500 status code could mean, unless you're very familiar with the server application. I'd even go so far as to suggest, if a modification i

Re: proposal to extend several component key properties to use Expression Lng instead of VarRegs only (based off https://issues.apache.org/jira/browse/NIFI-8214)

Definitely appreciate having as much "control" as possible afforded to each flowfile. The use cases described here are spot on and I've hit this myself previously. Any endpoint definition would ideally be configurable from the flowfile itself via expression language. It's easy enough to hard code a

Re: setup TLS configuration

Elvis, I found this document which might help give you clues to convert between IBM MQ's "kdb" format and the traditional Java "jks" format. In principle, it looks like you will need to export your client certificates, etc. out from your kdb store: https://www.ibm.com/mysupport/s/question/0D50z00

Re: Cobol/EBCDIC Source

Hi Frank, NiFi does not currently have native support for Cobol formats, such as copybook or EBCDIC. However, NiFi is built to be very extensible/pluggable, and as such, support can be added for any type of data conversion that you can imagine. For example, a new conversion processor from EBCDIC w

Re: [discuss] NiFi 1.20 and NiFi 2.0

Joe / team, Question on this. I think it would be helpful to understand the desired timelines for the first 2.0.0 release. I know it's not strictly predictable, but having a sense of what the timing looks like is important to help understand the implications of a "maintenance only" 1.x line. The s

Re: [discuss] NiFi 1.20 and NiFi 2.0

riod, or more incremental fix releases > for the initial 2.0.0 release train, but I do not expect delaying a 2.0.0 > release for new features, as that is not part of the release goals. > > I think it would be helpful to see some traction on the 2.0 release goals > before attempting to

Re: [discuss] NiFi 1.20 and NiFi 2.0

Handermann > > [1] > https://cwiki.apache.org/confluence/display/NIFI/NiFi+2.0+Release+Goals > > > > On Mon, Jan 9, 2023 at 6:08 PM Adam Taft wrote: > > > I think this sentence is capturing some of my question ... > > > > David wrote: > > > I thin

Re: [discuss] NiFi 1.20 and NiFi 2.0

This is really insightful and spot on ... Kevin wrote: > Good migration tooling will take a while to develop and test, and the core > contributors to that effort may not have sufficient variety of flows to > evaluate when the migration tools are "done" for the majority of the > community to have s

PostHTTP Deprecation Concerns

Just wanted to note a concern on the deprecation (and presumed removal) of the PostHTTP processor in the upcoming 2.0 release. While yes, for traditional client interactions with an external HTTP service, utilizing InvokeHTTP for your POST operation is probably sensible. The concern is that there

Re: PostHTTP Deprecation Concerns

and wall clock time. It's easy > to bench with DuplicateFlowfile on your production flow and metrics > analysis, just make sure your provenance db has sufficient space. > > Kind regards, > > On Thu, Jan 12, 2023, 10:09 Adam Taft wrote: > > > Just wanted to note a c

Re: PostHTTP Deprecation Concerns

self). Thanks again for the response. /Adam On Wed, Jan 11, 2023 at 9:27 PM Adam Taft wrote: > Hi Mathew, > > > It's quite remarkable you're advocating against standard practice > presumably > > for your own convenience. > > Wow, absolutely not stated no

Re: ValidateXml Processor - validatexml.invalid.error = Validation failed (NiFi 1.19.1)

Bilal, And I will be more than happy to help fix this. This is plaguing myself as well. Please let me know what your ticket number is, and I will help in whatever way is needed to get this fixed. /Adam On Wed, Feb 8, 2023 at 10:13 AM Dan S wrote: > Bilal, > Please create a bug ticket for this

Re: PostHTTP Deprecation Concerns

ou can find the solution under its name "nifi-flow-over-tcp" both on > GitHub and on Maven Central. > githubDOTcom/EndzeitBegins/nifi-flow-over-tcp > > > Maybe this can be helpful to you as well in the aforementioned cases you > previously made use of the PostHTTP processor. &g

Re: ValidateXml Processor - validatexml.invalid.error = Validation failed (NiFi 1.19.1)

o take this. > > On Thu, Feb 9, 2023 at 2:04 AM Bilal Bektaş .invalid> > wrote: > > > Hi Adam and Dan, > > > > Thank you for your quick response. > > > > Ticket number: NIFI-11156 > > > > Best wishes, > > > > --Bilal > &

Re: [discuss] nifi 2.0 and Java 21…

Yes, please. +1 Exactly what Mark said. Virtual threads have potential to be extremely impactful to applications like NiFi. /Adam On Wed, Sep 6, 2023 at 7:26 AM Mark Payne wrote: > Thanks for bringing his up, Joe. > > I would definitely be a +1. I think the new virtual thread concept would > ha

Re: new PackageFlowFile processor

+1 on this as well. It's something I've kind of griped about before (with the loss of PostHTTP). I don't think it would be horrible (as per Joe's concern) to offer a N:1 "bundling" property. It would just have to be stupid simple. No "groups", timeouts, correlation attributes, minimum entries, etc

Re: new PackageFlowFile processor

that transition while PostHTTP is still available on their canvas. Wishful thinking that we can make the entire journey from 1.x to 2.x as smooth as possible, but this could potentially help some. On Fri, Sep 8, 2023 at 10:55 AM Adam Taft wrote: > +1 on this as well. It's something I&

Re: new PackageFlowFile processor

as time allows. > > > > For now, something focused narrowly on FlowFile Version 3 encoding > > seems like the best approach. > > > > I recommend referencing this discussion in a new Jira issue and > > outlining the general design goals. > > > > Regards, >

Re: [discuss] Time for a NiFi 2.0 M1 release?

I'm also hoping that both 1.x and 2.x lines can receive the PackageFlowFile processor that Mike Moser recently proposed. That way, the M1 release and the most recent 1.x release will have a simple (or logical) replacement for PostHTTP. In general, it would be nice to have 1.x lined up with 2.0-M1

Re: UpdateAttribute Failure Relationship

Or better, the failure relationship just doesn't even exist until the property "Has Failure Relationship" is set to True. This involves updating UpdateAttribute to have dynamic relationships (the failure relationships appearing on true), which isn't hard to do in processor code. This has the adva

Re: UpdateAttribute Failure Relationship

>>> > >>>> Regards, > >>>> Matt > >>>> > >>>> > >>>> On Wed, Feb 7, 2024 at 8:11 PM Phillip Lord > >>>> wrote: > >>>> > >>>>> IMO... UpdateAttribute has been around since

Re: [DISCUSS] 1.x Maintenance

Feeling sympathetic to Pierre's point of view here. Picking specifically on the repository encryption issue itself, we have deprecation of a fundamental and well-known capability of NiFi. Repository encryption has been a key highlight and feature for those using NiFi in highly secure enclaves that

Re: [DISCUSS] Introducing NiFi Improvement Proposals

These are all really appreciated concepts, David. Thank you for putting the thoughts and time in on this! Regarding this: > The NiFi REST API does not have quite the same level of concern, but may warrant inclusion. I hear what you're saying. However, the REST API (from my observation/experience)