Bit of a plug for tika-helm here folks...
Horizontal pod autoscaling [0] is available (off by default) and can be
configured via values.yaml or overridden on the CLI.
This would mean that the availability to a tika-server would still be available
in the event that one particular pod went down
Ahh, my bad, I thought it was a system nofile limit. Thanks for the
correction, Tim.
--
Best regards,
Konstantin Gribov.
On Wed, Mar 8, 2023 at 11:31 PM Tim Allison wrote:
> HIT_MAX_FILES is expected. We designed that in to periodically
> restart the server to avoid memory leaks in badly
; From: Tim Allison
> Date: Wednesday, 8 March 2023, 23:30
> To: user@tika.apache.org
> Subject: [EXTERNAL] - Re: Tika server crashes
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you recognize the sender and kn
calling it is not enough.
From: Tim Allison
Date: Wednesday, 8 March 2023, 23:30
To: user@tika.apache.org
Subject: [EXTERNAL] - Re: Tika server crashes
CAUTION: This email originated from outside of the organization. Do not click
links or open attachments unless you recognize the sender and know
HIT_MAX_FILES is expected. We designed that in to periodically
restart the server to avoid memory leaks in badly behaving parsers.
You can configure a value for the max file threshold if necessary.
The restart failed, and that's a problem. Let me look into the code,
I thought we offered more
Hello, Artur.
How many concurrent requests did you have and are you running Tika Server
on Windows? And what kind of files did you use?
You may have hit number of open files limit due to lot of reasons starting
from known Windows issue (JVM process holds file descriptors for mmaped
files until
Hello!
I have a few questions related to Tika server.
We’ve started using tika server in our environment. While testing reliability
of the tika-server we found it crashes during fork and can’t fork anymore until
restart the main process. Is this known problem?
In order to start tika-server we
