[
https://issues.apache.org/jira/browse/JENA-95?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13085075#comment-13085075
]
Simon Helsen commented on JENA-95:
----------------------------------
yes, release would reflect it better. As for a test case, I understand it would
help and I may get around to this, but I was currently in evaluation mode only
and have other systems to test. (note that I filed other defects because I am
unable to finish the evaluation).
As for recovery going on, perhaps that is a possibility, although I am not sure
why since all previous transactions were closed. OTOH, I run into this around
the same time the corrupted index is surfacing, which is why perhaps there is a
relation. Now, even if there was a recovery going on, I would expect that the
recovery is suspect when expel (or perhaps release) is invoked and restarted
the next time I connect, so perhaps, if the behavior is enhanced like this,
this particular problem would go away?
> journal.jrl is not released when expelling a alocation
> ------------------------------------------------------
>
> Key: JENA-95
> URL: https://issues.apache.org/jira/browse/JENA-95
> Project: Jena
> Issue Type: Bug
> Components: TDB
> Reporter: Simon Helsen
> Priority: Critical
>
> whenever I call StoreConnection.expel(location) it seems that something is
> holding on to journal.jrl in location
> Caused by:
> java.io.IOException: Could not delete
> D:\jfsDev\working_dir\indices\4cb718ffab6047639c383cf9582633dc\jfs-rdfindex\journal.jrnl
> at java.lang.Throwable.<init>(Throwable.java:67)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
