[
https://issues.apache.org/jira/browse/TIKA-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137295#comment-18137295
]
Tim Allison commented on TIKA-5025:
-----------------------------------
My :robot: asks about this:
{noformat}
There's one problem worth raising before it merges: the TIKA_SERVER_ prefix
collides with Kubernetes. Kubernetes injects
environment variables for every Service in the namespace, named after the
Service. A Service called tika-server gives every
pod TIKA_SERVER_PORT=tcp://10.x.x.x:9998, TIKA_SERVER_SERVICE_HOST,
TIKA_SERVER_PORT_9998_TCP_ADDR and so on. Under this
PR:
- TIKA_SERVER_PORT maps to the real port field, gets a tcp://... value, and
fails startup with a type error.
- TIKA_SERVER_SERVICE_HOST maps to an unknown field, which the PR also makes
fail startup.
So an existing deployment with a Service named tika-server would stop
starting after upgrading, with no config change.
That's from the PR description and Kubernetes' documented behaviour; I
haven't run it.
The cheapest fixes are a less generic prefix (e.g. TIKA_SERVER_SETTING_), an
explicit allowlist of fields, or warning and
skipping unknown fields instead of failing. The flag (--serverSetting) is
fine as is.
{noformat}
> tika-server: set the request limits from the environment and the command line
> -----------------------------------------------------------------------------
>
> Key: TIKA-5025
> URL: https://issues.apache.org/jira/browse/TIKA-5025
> Project: Tika
> Issue Type: Improvement
> Reporter: Dominik Schmidt
> Priority: Major
>
> Since TIKA-4988 the Docker image runs a thumbnail server with nothing but -e
> TIKA_PRESETS=thumbnail. The first file over 1 GiB brings the config file
> back: maxRequestSizeBytes (TIKA-4991, default 1073741824) lives in the server
> block of the JSON config and can only be changed by mounting a file and
> passing -c. The same goes for its siblings maxInFlightRequestBytes,
> maxRequestReadMillis, maxResponseWriteMillis and maxQueuePauseMillis.
> Measured on 4.2.1-SNAPSHOT with a 1.46 GB MPEG-4 audiobook: PUT
> /unpack/preset/thumbnail answers 413 "Request body exceeds
> maxRequestSizeBytes" from the declared Content-Length alone; with {"server":
> {"maxRequestSizeBytes": 4294967296}, "presets": {"thumbnail": true}} the
> cover comes back in 4 s.
> Proposal: every setting of the server block can be given as
> TIKA_SERVER_<UPPER_SNAKE_CASE> in the environment, e.g.
> TIKA_SERVER_MAX_REQUEST_SIZE_BYTES=4294967296, and as --server-<kebab-case>
> <value> on the command line, following TIKA-4988: both are merged into the
> startup config before the front end and the forked workers load it, so the
> forks keep receiving the resolved config over stdin and never read the
> environment; command line and environment win over the file; an unknown key
> fails startup; the startup log says where a value came from. Sizes accept the
> plain byte count, suffixes (4g) would be nice but are a separate decision.
> Also: the 413 body should name the limit and where to raise it, as the preset
> 404 does, so an operator reads the answer instead of the server log.
> Docs: the server page's limits section and the Docker page get the env form
> next to the config form.
> Related: TIKA-4988 (TIKA_PRESETS), TIKA-4991 (the limits), TIKA-4909 (env
> interpolation inside a config file, which still needs the file).
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
