Re: board report for Apache NiFi - January 2017

+1 LGTM (especially the growth). The email rates are a bit down but percentage-wise, the issues list is closer to 50% of last period where the rest is within "normal" limits. I'm guessing this is due to the holidays? I know I got a lot less done over the past month, perhaps because of putting

board report for Apache NiFi - January 2017

Team, I was running late on getting this together so have gone ahead and submitted it. But here is the board report I submitted for us this month. Very cool to see continued growth of our PMC and committer group and the quality release cadence. Thanks all! ## Description: - Apache NiFi is

Re: [DISCUSS] Run Once scheduling

I think it is a matter of the model in one's head. If one thinks of a continuous activation paradigm the green arrow versus red square indicate what you point out. On the other hand in an ad-hoc run-once paradigm the green arrow is a nice succinct indicator of what has not run yet. In an

Re: problems with custom controller services, and other comments

Michael Sorry took a while, but we just had one of our guys reporting the same symptoms and as Bryan suggested it was actually a problem in the POM, specifically the POM file for NAR modules of your custom processor. Basically once your processor is referencing the service it’s NRA module has

Re: [DISCUSS] Run Once scheduling

Naz The green arrow vs red square says "scheduled to execute" vs "not scheduled to execute". For most processors, such as those which take input flow files from a connection, even if they're scheduled to run they're not going to be executed unless there is work to do (data sitting in the queue)

Re: [DISCUSS] Run Once scheduling

Correction, that was the processor scheduler’s stopProcessor() method that needs to be invoked so the UI shows that the processor is stopped. Naz Irizarry MITRE Corp. 617-893-0074 > On Jan 12, 2017, at 2:08 PM, Irizarry Jr., Nazario wrote: > > Yes, we found that to keep the

Re: [DISCUSS] Run Once scheduling

Yes, we found that to keep the UI in sync (make sure it looks stopped after it runs once) the flow controller's stopProcessor() method has to be called. Naz Irizarry MITRE Corp. 617-893-0074 On Jan 12, 2017, at 1:41 PM, Brandon DeVries > wrote: I think

Re: [DISCUSS] Run Once scheduling

The users that I work with are in the data-analytic space. Without NiFi what they tend to do is to build scripts, often shell scripts that they edit and modify from run to run. Thus for this class of user it is not really about continuous flows. But, the connect-the-box metaphor is

Re: [DISCUSS] Run Once scheduling

What tends to happen with these infrequent flows is that not only are they infrequent but they also tend to change from one run to the next. Thus the first time there might be a string of processes but the next time (based on lessons learned from the first time) the run is modified, or a new

Re: [DISCUSS] Run Once scheduling

I think answering Joe's question is step one. However, I was curious and tried something: public void onTrigger(...){ if(!isSheduled()){ return; } FlowFile flowFile = session.get() if (flowFile == null){ return; } session.transfer(flowFile, REL_SUCCESS);

Re: [DISCUSS] Run Once scheduling

I was just about to suggest the same. Run-once would be a bit counter intuitive to the flow processing as a concept. Basically think of it this way; Flow or parts of it have only two states - RUNNING or STOPPED. In the RUNNING state it processes the data as it arrives (every second, every

Re: [DISCUSS] Run Once scheduling

Naz, Why not just leave all the processes running? If the data only arrives periodically that is ok, right? Thanks Joe On Thu, Jan 12, 2017 at 10:54 AM, Irizarry Jr., Nazario wrote: > On a project that I am on we have been looking at using NiFi for > orchestrations that are

[DISCUSS] Run Once scheduling

On a project that I am on we have been looking at using NiFi for orchestrations that are invoked infrequently. For example, once a month a new data input product becomes available and then one wants to run it through a set of processing steps that can be nicely implemented using NiFi

Re: transportProtocol in flow.xml.gz?

Hey Joe, This is definitely a known issue and I'm fairly certain there is a JIRA for it, but can't find it since JIRA is having issues. As you mentioned, it should not adversely affect anything though. -Bryan On Thu, Jan 12, 2017 at 8:24 AM, Joe Gresock wrote: > I'm not

transportProtocol in flow.xml.gz?

I'm not sure if there's already a ticket (JIRA issue search appears to be down), but I'm seeing this in my nifi-bootstrap.log upon startup: 2017-01-12 13:19:52,373 ERROR [NiFi logging handler] org.apache.nifi.StdErr [Error] :19215:30: cvc-complex-type.2.4.a: Invalid content was found starting

Re: Where does javax.net.debug output go?

Ok, I narrowed it down and found that when I specify an external directory as the conf directory, nifi-bootstrap.log isn't written to (though it is created). In this scenario, the other log files work just fine, it's just the nifi-bootstrap.log that doesn't work. To reproduce this, I replaced

FOSDEM 2017 Open Source Conference - Brussels

Hello Everyone This email is to tell you about ASF participation at FOSDEM. The event will be held in Brussels on 4^th & 5^th February 2017 and we are hoping that many people from our ASF projects will be there. https://fosdem.org/2017/ Attending FOSDEM is completely free and the ASF will