Thanks for following up Russ and glad you're making progress.
On Oct 13, 2016 5:36 PM, "Russell Bateman" <
russell.bate...@perfectsearchcorp.com> wrote:
> As promised, and as embarrassing as it seems now, I'm reporting what
> happened...
>
> It appears that one of our IT guys failed to type /G/
As promised, and as embarrassing as it seems now, I'm reporting what
happened...
It appears that one of our IT guys failed to type /G/ when he created
the swap partition on this staging server and it ended up sized at 128M
instead of 128G. (Fortunately, it's not a production server and I
Just a sanity check, number of open file handles increased as per
quickstart document? Might need much more for your flow.
Another tip, when your server experiences undesired hiccups like that try
running 'nifi.sh dump save-in-this-file.txt' and investigate/share where
NiFi threads are being held
We use the templating to create FHIR XML, in this case, a
...
construct that includes a base-64 encoding of a PDF, the flowfile
contents coming into the templating processor. These can get to be
megabytes in size though our sample data was just under 1Mb.
Yesterday, I
Russ,
As Jeff points out lack of available threads could be a factor flow
slower processing times but this would manifest itself by you seeing
that the processor isn't running very often. If it is that the
process itself when executing takes much longer than on the other box
then it is probably
Russel,
This sounds like it's an environmental issue. Are you able to see the heap
usage on the production machine? Are there enough available threads to get
the throughput you are observing when you run locally? Have you
double-checked the scheduling tab on the processor config to make sure
