[
https://issues.apache.org/jira/browse/JENA-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15124968#comment-15124968
]
ASF GitHub Bot commented on JENA-1104:
--------------------------------------
Github user afs commented on the pull request:
https://github.com/apache/jena/pull/123#issuecomment-177243620
This PR protects against multiple creation of a text index (JENA-1104), not
against two calls to create the same dataset for two services in Fuseki. By
chance, TDB is less prone to problems if that happens but that is luck.
General datasets e.g. with inference graphs, SDB or plain in-memory datasets
are likely exposed to problems.
Let's solve the immediate issue described in JENA-1122, then see if
JENA-1104 needs addressing or whether the situations where it can still happen
are uninteresting or have other problems in which case the application must be
responsible for creating the index only once.
For the record, there are some specific items with the current PR that I
would like clarified or refuted before this code is used to address JENA-1107,
if that is still needed.
1: `TextIndexLucene.close` is not reference counted.
* Create text index -> T1
* Create text index -> T2 (which is T1, shared)
* Close T2.
* Any T1 code will now crash - the index is closed.
2: Using WeakReferences and managing `close()` seems to be duplicating
lifecycle management.
I am not clear that the WeakReference to the Lucene index helps because
there are no finalizers, so GC fnalization does not tidy up lucene. A freed
WeakReference would cause a new attempt to create the index but it will hit the
state lock.
3: Creation by `createLuceneIndex` is not thread safe. It has a
get-create-put timing hole.
4: Need to be clear on the contract for "same `Directory`, different Lucene
configuration (`TextIndexConfig`)".
> LockObtainFailedException for text index
> ----------------------------------------
>
> Key: JENA-1104
> URL: https://issues.apache.org/jira/browse/JENA-1104
> Project: Apache Jena
> Issue Type: Bug
> Components: Fuseki
> Affects Versions: Fuseki 2.3.1
> Environment: CentOS 5.11
> Java 1.8.0_45-b14
> Tomcat 7.0.62
> Reporter: Joachim Neubert
>
> When starting Fuseki2 under Tomcat, on Centos 5 I get an exception which I
> have not seen on Centos 7:
> {quote}
> SEVERE: Exception sending context initialized event to listener instance of
> class org.apache.jena.fuseki.server.FusekiServerListener
> org.apache.jena.assembler.exceptions.AssemblerException: caught:
> org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out:
> NativeFSLock@/opt/thes/var/gn
> d/2015-10-13/tdb_lucene/write.lock:
> java.nio.channels.OverlappingFileLockException
> doing:
> root: file:///opt/fuseki2/run/configuration/gnd.ttl#gndIndex with type:
> http://jena.apache.org/text#TextIndexLucene assembler class: class
> org.apache.jena.query.tex
> t.assembler.TextIndexLuceneAssembler
> root: file:///opt/fuseki2/run/configuration/gnd.ttl#gnd with type:
> http://jena.apache.org/text#TextDataset assembler class: class
> org.apache.jena.query.text.assembl
> er.TextDatasetAssembler
> at
> org.apache.jena.assembler.assemblers.AssemblerGroup$PlainAssemblerGroup.openBySpecificType(AssemblerGroup.java:138)
> ...
> {quote}
> The very strange thing is that tomcat actually *has* created the write.lock
> file in that directory (which I had removed before).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
