[
https://issues.apache.org/jira/browse/TIKA-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17743175#comment-17743175
]
Josh Burchard commented on TIKA-4050:
-------------------------------------
Hey Tim. Thanks for the response. I poked around at what you mentioned, but
never quite grokked it. The -Dcf jvm option was specifying the dtikacfg.xml
file, while -Dll specifies the log4jTika.xml file. ${env:tika.server.id} only
spits out "Domino" since that's what I'd set in my config file, so was I
missing a way to get a unique ID?
Anyhow, I came up with a workaround by changing Log4j2's RollingFile fileName
attribute to have this value instead:
fileName="${sys:ll}.${date:yyMMddHHmmssSSSS}". This gets me a new unique
logfile for every child process. It'd be better if log4j2 supported retrieving
the # of seconds since epoch but, alas, they don't.
> Forked child logs are overwritten upon restart
> ----------------------------------------------
>
> Key: TIKA-4050
> URL: https://issues.apache.org/jira/browse/TIKA-4050
> Project: Tika
> Issue Type: Bug
> Components: core
> Affects Versions: 2.8.0
> Environment: Windows 10 Enterprise
> Reporter: Josh Burchard
> Priority: Major
> Attachments: dtikacfg.xml, log4j2-async.xml, log4jTika.xml
>
>
> In my config file I specify a log file path for the forked child to use. A
> problem arises when the child has a problem and the watchdog restarts it
> because the new child overwrites the previous child's log so I lose the
> details about what the child was doing prior to a restart. Requesting that
> logging is preserved for all children while the watchdog is resident.
>
> Reproduction steps:
> [^dtikacfg.xml] [^log4jTika.xml]
> # ^Launch tika server:^
> ^java.exe -Djt="c:\tikatmp0000" -Dll="c:\tika0000.log"
> -Dcf="c:\log4jTika.xml" -jar "c:\tika-server-standard-2.8.0.jar" -c
> "c:\dtikacfg.xml"^
> # ^Peek at the tika0000.log file and take note of the timestamps.^
> # ^Kill the Tika child task and allow the watchdog to restart it.^
> # ^Note that the previous content has been overwritten by log lines with new
> timestamps.^
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
