Thanks, I didn't realize that undoing the lock would be that simple. I
got it to work, and I then got arq.larq to return a list of literals
based on a Lucene query string.
arq.larq -help mentions a --strict option to "operate in strict SPARQL
mode," but there's no way to actually pass arq.larq an actual SPARQL
query, right? It just searches the indexed literals? That alone is cool,
but I wanted to make sure I'm not missing anything.
thanks,
Bob
On 5/9/2011 6:20 AM, Paolo Castagna wrote:
Hi Bob,
if no process is trying to write to that index,
what happens if you manually delete the write.lock?
Do you still have the error?
Paolo
Bob DuCharme wrote:
>Maybe a stale lock? Is more than one process trying to write to this
index?
No, I even rebooted to make sure that no processes are doing anything
with that index or directory, and I still get that error message with
that command.
thanks,
Bob
On 5/8/2011 6:06 PM, Damian Steer wrote:
On 8 May 2011, at 22:56, Bob DuCharme wrote:
When I enter the following, in which larqndx is a subdirectory,
java -cp %CP% arq.larqbuilder --larq=larqndx --graph mydata.rdf
I get the errors shown below. Can the --graph parameter be a file,
or do I need an assembler description file to specify the data to
index?
Hi Bob,
To be honest it looks to me like your problem lies elsewhere:
Caused by: org.apache.lucene.store.LockObtainFailedException: Lock
obtain timed
out: SimpleFSLock@C:\bob\dev\xml\rdf\larqtest\larqndx\write.lock
at org.apache.lucene.store.Lock.obtain(Lock.java:85)
Maybe a stale lock? Is more than one process trying to write to this
index?
Damian
