[
https://issues.apache.org/jira/browse/JENA-1136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15140584#comment-15140584
]
Rob Vesse edited comment on JENA-1136 at 2/10/16 9:54 AM:
----------------------------------------------------------
Did you verify whether PID 23588 existed and was alive?
Please see the FAQ on this error -
https://jena.apache.org/documentation/tdb/faqs.html#lock-exception
If you got this error then TDB detected that the TDB database had been locked
by PID 23588 and that the process with the PID still appeared to be running.
If this was not the case then there may be a bug in the alive process checking
that is perhaps specific to your environment.
We use {{ps -p PID}} to check for process aliveness so if you see this issue
again please run that command with the reported PID and report on what output
was seen.
Also what do you mean when you say Tomcat was restarted? Did you stop and then
start Tomcat or is this some other kind of restart i.e. via the Tomcat Host
Manager APIs?
Personally I've seen issues in the past where Tomcat takes a while to stop
(longer than the default 5 seconds that the Tomcat scripts wait for) that can
mean that when you start it up again the previous Tomcat process is not yet
dead which would explain the kind of behaviour you see. You can try using the
{{-n X}} argument to the Tomcat scripts to increase the shutdown wait time.
We should probably also mark the TDB lock file as {{deleteOnExit()}} though if
the JVM is not shutting down fast enough currently then that will not resolve
your problem
was (Author: rvesse):
Did you verify whether PID 23588 existed and was alive?
Please see the FAQ on this error -
https://jena.apache.org/documentation/tdb/faqs.html#lock-exception
If you got this error then TDB detected that the TDB database had been locked
by PID 23588 and that the process with the PID still appeared to be running.
If this was not the case then there may be a bug in the alive process checking
that is perhaps specific to your environment.
We use {{ps -p PID}} to check for process aliveness so if you see this issue
again please run that command with the reported PID and report on what output
was seen.
Also what do you mean when you say Tomcat was restarted? Did you stop and then
start Tomcat or is this some other kind of restart i.e. via the Tomcat Host
Manager APIs?
Personally I've seen issues in the past where Tomcat takes a while to stop
(longer than the default 5 seconds) that can mean that when you start it up
again the previous Tomcat process is not yet dead which would explain the kind
of behaviour you see. You can try using the {{-n X}} argument to the Tomcat
scripts to increase the shutdown wait time.
We should probably also mark the TDB lock file as {{deleteOnExit()}} though if
the JVM is not shutting down fast enough currently then that will not resolve
your problem
> Stopping Fuseki under Tomcat seems not to remove tdb and lucene locks
> ---------------------------------------------------------------------
>
> Key: JENA-1136
> URL: https://issues.apache.org/jira/browse/JENA-1136
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
> Affects Versions: Fuseki 2.4.0
> Environment: CentOS 5.x
> Reporter: Joachim Neubert
> Assignee: Rob Vesse
>
> When restarting Tomcat with the latest Fuseki snapshot
> (apache-jena-fuseki-2.4.0-20160209.095958-47.tar.gz), the application can't
> be started:
> {noformat}
> [2016-02-10 06:48:04] Config INFO FUSEKI_HOME=/opt/fuseki
> [2016-02-10 06:48:04] Config INFO FUSEKI_BASE=/opt/fuseki2/run
> [2016-02-10 06:48:04] Config INFO Shiro file:
> file:///opt/fuseki2/run/shiro.ini
> [2016-02-10 06:48:04] Config INFO Context path = /fuseki
> [2016-02-10 06:48:04] Config INFO Configuration file:
> /opt/fuseki2/run/config.ttl
> [2016-02-10 06:48:04] Server ERROR Exception in initialization: Can't
> open database at location /opt/apache-jena-fuseki-2.4.0-SNAPSHOT/run/system/
> as it is already
> locked by the process with PID 23588. TDB databases do not permit concurrent
> usage across JVMs so in order to prevent possible data corruption you cannot
> open this loc
> ation from the JVM that does not own the lock for the dataset
> Feb 10, 2016 6:48:04 AM org.apache.catalina.core.StandardContext startInternal
> {noformat}
> After manually deleting all tdb.lock files, it barks on the text indexes:
> {noformat}
> [2016-02-10 06:53:49] Config INFO FUSEKI_HOME=/opt/fuseki
> [2016-02-10 06:53:49] Config INFO FUSEKI_BASE=/opt/fuseki2/run
> [2016-02-10 06:53:49] Config INFO Shiro file:
> file:///opt/fuseki2/run/shiro.ini
> [2016-02-10 06:53:49] Config INFO Context path = /fuseki
> [2016-02-10 06:53:49] Config INFO Configuration file:
> /opt/fuseki2/run/config.ttl
> [2016-02-10 06:53:51] Server ERROR Exception in initialization: caught:
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out:
> NativeFSLock@/opt/thes/var/stw/9.0/tdb_lucene/write.lock
> {noformat}
> After deleting these manually, too, Fuseki starts. (So I've added the cleanup
> temporarily to my tomcat stop function in the service definition file.)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
