[
https://issues.apache.org/jira/browse/TIKA-3293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17357742#comment-17357742
]
Tilman Hausherr commented on TIKA-3293:
---------------------------------------
in the "main" build, testBadJVMArgs() fails on windows 10, the result is -1
instead of 255 (before rev 918aff0 the code tested for -1). But I think the -1
is also a "successful" test result, here's what I see in the log output when
these are activated:
{noformat}
SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further
details.
Error occurred during initialization of VM
Initial heap size set to a larger value than the maximum heap size
java.util.concurrent.ExecutionException: java.lang.RuntimeException: Failed to
start forked process -- forked is not alive
at java.util.concurrent.FutureTask.report(FutureTask.java:122)
at java.util.concurrent.FutureTask.get(FutureTask.java:192)
at
org.apache.tika.server.core.TikaServerCli.mainLoop(TikaServerCli.java:116)
at
org.apache.tika.server.core.TikaServerCli.execute(TikaServerCli.java:88)
at org.apache.tika.server.core.TikaServerCli.main(TikaServerCli.java:66)
Caused by: java.lang.RuntimeException: Failed to start forked process -- forked
is not alive
at
org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.<init>(TikaServerWatchDog.java:245)
at
org.apache.tika.server.core.TikaServerWatchDog$ForkedProcess.<init>(TikaServerWatchDog.java:210)
at
org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:117)
at
org.apache.tika.server.core.TikaServerWatchDog.call(TikaServerWatchDog.java:50)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
> Move most commandline options for tika-server into a config file in 2.0.0
> -------------------------------------------------------------------------
>
> Key: TIKA-3293
> URL: https://issues.apache.org/jira/browse/TIKA-3293
> Project: Tika
> Issue Type: Task
> Reporter: Tim Allison
> Priority: Major
>
> We now have a huge amount of commandline options for tika-server. I propose
> moving them into a config file. Given that TikaConfig doesn't mind elements
> that it isn't looking for, we can add this to a tika-config.xml file.
>
> I tried to extend TikaConfig, and it was, um, non-trivial. So, this proposal
> would have tika-server and tikaconfig reading the same file twice and looking
> for different elements.
>
> Any objections?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
