[ 
https://issues.apache.org/jira/browse/TIKA-5025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18137320#comment-18137320
 ] 

ASF GitHub Bot commented on TIKA-5025:
--------------------------------------

dschmidt commented on PR #3519:
URL: https://github.com/apache/tika/pull/3519#issuecomment-6608165058

   Good catch, thanks. The prefix is `TIKA_SERVER_SETTING_` now (ab1f350d21); 
the test puts `TIKA_SERVER_PORT=tcp://...`, `TIKA_SERVER_SERVICE_HOST` and 
`TIKA_SERVER_PORT_9998_TCP_ADDR` into the environment and expects them ignored, 
and the docs say why the prefix is this long. Unknown fields under the new 
prefix still fail startup, since nothing but an operator writes them.




> 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)

Reply via email to