+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 toge
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 an
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 anal
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 to
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) a
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 UI in sync (make
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
mailto:b...@jhu.edu>> wrote:
I think answering Joe's que
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 nonetheles
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 br
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);
updateScheduledFalse
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 minut
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 invoked infrequent
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 processors
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 sure if there's alread
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 with
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 "./
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 ag
17 matches
Mail list logo