Thanks, that's a good idea, as I would automatically assume if a property supports EL it would work against flowfiles. I see the ticket 3231 was specific to variable registry and explicitly says not flow files. Any particular reason?
On Fri, Jan 26, 2018 at 12:02 PM, Pierre Villard < [email protected]> wrote: > And to add a bit of info on the last remark from Joe, I'm working on > NIFI-4149 to make the scope of EL clearer to users. Didn't have time to > work on it lately but will definitely try to get back to it very soon. > > Pierre > > 2018-01-26 17:14 GMT+01:00 Joe Witt <[email protected]>: > > > Stated differently - it considers what it can glean from variables > > made available other than the flowfile itself. With Apache NiFi 1.5.0 > > that means process group variables, variables set in nifi.properites, > > and environment variables. > > > > We need to make sure that we call this out when we indicate a given > > property supports expression language so the user knows the scope at > > which it will help them. > > > > On Fri, Jan 26, 2018 at 10:44 AM, Marco Gaido <[email protected]> > > wrote: > > > Hi Ryan, > > > > > > probably the reason of the behavior is that EL on PutTCP is enabled but > > it > > > is not run on the incoming flowfile. So it doesn't care the attributes > of > > > your flowfile. It considers only environment variables. > > > > > > Thanks, > > > Marco > > > > > > 2018-01-26 15:56 GMT+01:00 Ryan Ward <[email protected]>: > > > > > >> I'm seeing odd behavior trying to use attributes for the hostname and > > port > > >> fields. > > >> > > >> using ${endpoint_port} (9003) + hardcoded IP results in flowfile > > yielding > > >> failed to process session due to java.lang.NumberFormatException: For > > >> input > > >> string: "": {} > > >> java.lang.NumberFormatException: For input string: "" > > >> at > > >> java.lang.NumberFormatException.forInputString( > > >> NumberFormatException.java:65) > > >> at java.lang.Integer.parseInt(Integer.java:592) > > >> at java.lang.Integer.parseInt(Integer.java:615) > > >> at > > >> org.apache.nifi.attribute.expression.language.StandardPropertyValue. > > >> asInteger(StandardPropertyValue.java:78) > > >> > > >> at org.apache.nifi.processors.standard.PutTCP.createSender > > >> (PutTCP.java:111) > > >> ... > > >> at org.apache.nifi.processors.standard.PutTCP.createSender > > >> (PutTCP.java:179) > > >> > > >> using hardcoded 9003 + ${endpoint} results in flowfile failing due to > > >> connection refused > > >> DEBUG ...No available connections, creating a new one... > > >> ERROR ...No available connections, and unable to create a new one > ....to > > >> failure: java.net.ConnectException: Connection refused > > >> > > >> Adding listenTCP to the cluster on 9003 leaving ${endpoint} and > > hardcoded > > >> port > > >> DEBUG...Connected to local port 23250 > > >> DEBUG....Relinquishing sender > > >> Flow files transferred to success, its unclear where the data went or > > why I > > >> needed to have the nodes listening on this port. Is the attribute > value > > >> being ignored and defaulting to localhost? Watching this behavior via > > >> netstat I could see 127.0.0.1 was indeed connected to itself on 9003. > > Odd > > >> thing is no data came in on the ListenTCP either. > > >> > > >> Thanks, > > >> Ryan > > >> > > >
