[
https://issues.apache.org/jira/browse/JENA-1122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15114295#comment-15114295
]
Brian McBride commented on JENA-1122:
-------------------------------------
The main problem I had was figuring out how to manage the static state so it
was consistent with the lifecyle implemented by TextIndexLucene and avoid
memory leaks on long running systems. Hence the call backs. That is an issue
that is common to both API and assembler construction.
The assembler mechanism is not designed to handle graph (or even lattice)
structured composition of components. According to Chris, it is by design that
It does a recursive decent over the structure and assembles a new thing each
time a node is encountered.
Perhaps there is a need for an assembly mechanism designed to handle graph
structures. Would also be useful to have some notion of an assember 'session',
that is the process of building a complete structure, during which session
state could be built up and thrown away at the end.
> Fuseki fails to start if configured with two services that share the same
> dataset with a lucene index.
> ------------------------------------------------------------------------------------------------------
>
> Key: JENA-1122
> URL: https://issues.apache.org/jira/browse/JENA-1122
> Project: Apache Jena
> Issue Type: Bug
> Components: Text
> Affects Versions: Jena 3.0.0, Fuseki 2.3.0
> Reporter: Brian McBride
>
> This problem arises when the assemblers for the two services run. For each
> service, a separate TextIndexLucene object is created. Both of those objects
> try to lock the same Lucene index directory and one fails.
> A proposed fix is to modify the TextDatasetFactory to only create one
> TextIndexLucene object per on disk directory.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
