The way you set it up initially is what I'd thought would have done
the trick. Perhaps we're not ordering the arguments in the same
manner supplied. Will need to look into that.
Thanks
Joe
On Wed, Dec 14, 2016 at 9:00 PM, Russell Bateman wrote:
> Of course, as many have done, I've run Java app
I'd be very curious to see if changing the limits addresses the issue.
The OOME can certainly be an issue, as well. Once that gets thrown anywhere
in the JVM, it's hard to vouch for the stability of the JVM at all.
Seeing the claimant count drop to 0 then back up to 1, 2, and down to 1, 0 again
is
Matt,
This is where it gets interesting. The issue only arises when nginx is
used as a reverse proxy for a *clustered* NiFi (within a trusted
environment using http). In fact, it even occurs when the reverse proxy
upstream points to only one of the nifi nodes in the cluster. Moreover,
the probl
Of course, as many have done, I've run Java applications with JFR
enabled using these options against this very JVM (jdk1.8.0_112). So, it
isn't a problem for the JVM I'm using. I haven't finished digging down
into ProcessBuilder, or deeper, to figure out why these options are not
getting love.
I agree the limits sound low and will address that tomorrow.
I'm not seeing FileNotFound or NoSuchFile.
Here's an example file:
grep 1481763927251 logs/nifi-app.log
2016-12-14 17:05:27,277 DEBUG [Timer-Driven Process Thread-36]
o.a.n.c.r.c.StandardResourceClaimManager Incrementing claimant count
OK, so these are generally the default values for most linux systems. These are
a little low,
though for what NiFi recommends and often needs. With these settings, you can
easily run
out of open file handles. When this happens, trying to access a file will
return a FileNotFoundException
even tho
We haven't let the disk hit 100% in a while, but it's been crossing 90%. We
haven't seen the "Unable to checkpoint" message in the last 24 hours.
$ ulimit -Hn
4096
$ ulimit -Sn
1024
I will work on tracking a specific file next.
On Wed, Dec 14, 2016 at 8:17 PM, Alan Jackoway wrote:
> At first
Alan,
No, the number should correspond to the number of Resource Claims (i.e., files
on disk
in the Content Repository). The files are generally written to until they reach
around 10 MB
or so. So a back-of-napkin calculation is that the number you have there is the
total amount
of data written
At first I thought that the drained messages always said 0, but that's not
right. What should the total number of claims drained be? The number of
flowfiles that made it through the system? If so, I think our number is low:
$ grep "StandardResourceClaimManager Drained" nifi-app_2016-12-14* | grep
Alan,
Some things that I would look into:
* Did you see the same ERROR as below: Unable to checkpoint FlowFile Repository
due to ...?
If so, did this occur before you ran out of disk space, or only after you ran
out of disk space?
* What do you get when you run "ulimit -Hn" and "ulimit -Sn"
Some updates:
* We fixed the issue with missing transfer relationships, and this did not
go away.
* We saw this a few minutes ago when the queue was at 0.
What should I be looking for in the logs to figure out the issue?
Thanks,
Alan
On Mon, Dec 12, 2016 at 12:45 PM, Alan Jackoway wrote:
> In
Rick,
The signature of the endpoint that accepts a template upload has not
changed (other than the path). Are you running a NiFi cluster in the
trusted environment or is it a standalone instance? Is the issue when you
attempt to upload the template or when you attempt to drop the template on
your
Hey Joe,
Yup, I will take on RM duties for 1.0.1
Joe
- - - - - - Joseph Percivalllinkedin.com/in/Percivalle: joeperciv...@yahoo.com
On Wednesday, December 14, 2016, 3:13:09 PM EST, Joe Witt
wrote:Team,
There are a few important behavior fixes for template generation and
import with controller
Team,
There are a few important behavior fixes for template generation and
import with controller services, fine grained authorization logic, and
publishing to kafka. These fixes are all in the
nifi-1.2.0-SNAPSHOT/master but these also make sense to get backported
to nifi 1.1.1 and nifi 1.0.1 as
Running Apache NiFi 0.7.1, we see clients rejected due to OCSP revocation
of their certificates but we think we are seeing instances where servers
using OCSP revoked certificates are still able to connect to a cluster.
Should OCSP revocation cause these servers to be rejected by the cluster?
Coul
I am using an nginx reverse proxy in front of NiFi 1.1.x. Here are the
important details. First, nginx is using basic auth and SSL. Second, NiFi
is running in a trusted environment without SSL. We successfully used the
same layout for NiFi 0.7.x without issue. However, starting with 1.0.x and
c
I've doctored /conf/bootstrap.conf/ to contain these additional lines:
java.arg.15=-XX:+UnlockCommercialFeatures
java.arg.16=-XX:+FlightRecorder
java.arg.17=-XX:StartFlightRecording=duration=120m,filename=recording.jfr
In the end, NiFi's grumpy about this and won't start (from
/logs/
17 matches
Mail list logo
