I passed this along to the primary developers - Thanks Mike!
Best Regards
John
> On Dec 3, 2020, at 1:11 PM, Mike Thomsen wrote:
>
> One of my colleagues ran into a similar situation, and all that was
> required to fix it was to make ReplaceText work line by line. When you
> do that, you
One of my colleagues ran into a similar situation, and all that was
required to fix it was to make ReplaceText work line by line. When you
do that, you shouldn't run into any issues.
On Thu, Dec 3, 2020 at 1:04 PM jgunvaldson wrote:
>
> Just looking for an opinion
>
> Knowing (for one example)
I am honestly not sure if it is required - but it is probably a good idea.
Please let us know what you find using those.
Also, definitely we should change that flow to avoid large memory
consumption. Want to share more details on the input data and config that
results in this?
On Thu, Dec 3,
Thanks Joe,
I am getting the general opinion that on OOM restart is not optional, must be
done. In that case I am going to also look at some of the following
-XX:+ExitOnOutOfMemoryError
-XX:+CrashOnOutOfMemoryError
ExitOnOutOfMemoryError
When you enable this option, the JVM exits on the first
John,
First, as a general rule it is usually very doable to build flows which are
very stream oriented rather than entire file oriented. That processor by
its nature isn't friendly in this way if configured to work with large
memory chunks. Alternatives often exist.
Second, I do think it is
Just looking for an opinion
Knowing (for one example) that ReplaceText Processor can be very memory
intensive with large files - we are finding it more and more common to wake up
to an Out of Memory error like the following
2020-12-03 15:07:21,748ZUTC ERROR [Timer-Driven Process Thread-31]
