[ 
https://issues.apache.org/jira/browse/LUCENE-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12847063#action_12847063
 ] 

Michael McCandless commented on LUCENE-2328:
--------------------------------------------

Yes please clean as you go Earwin -- those sound great.

{quote}
bq. Must the Dir insist the file is closed in order to sync it?
Well, no, this can be relaxed.
Because default Directory clients - IW+IR will never call sync() on a file they 
didn't close yet.
Also this client behaviour is guaranteed with current implementation - if 
someone calls current sync() on an open file, it will fail on 'new 
RandomAccessFile'?
{quote}

I'd like to allow for this to work in the future, even if current FSDir impls 
cannot sync an open file.  EG conceivably they could reach in and get the RAF 
that IndexOutput has open and sync it.

So I think we just note this as a limitation of FSDir impls today, but, the API 
allows for it?

> IndexWriter.synced  field accumulates data leading to a Memory Leak
> -------------------------------------------------------------------
>
>                 Key: LUCENE-2328
>                 URL: https://issues.apache.org/jira/browse/LUCENE-2328
>             Project: Lucene - Java
>          Issue Type: Bug
>          Components: Index
>    Affects Versions: 2.9.1, 2.9.2, 3.0, 3.0.1
>         Environment: all
>            Reporter: Gregor Kaczor
>            Priority: Minor
>             Fix For: 3.1
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> I am running into a strange OutOfMemoryError. My small test application does
> index and delete some few files. This is repeated for 60k times. Optimization
> is run from every 2k times a file is indexed. Index size is 50KB. I did 
> analyze
> the HeapDumpFile and realized that IndexWriter.synced field occupied more than
> half of the heap. That field is a private HashSet without a getter. Its task 
> is
> to hold files which have been synced already.
> There are two calls to addAll and one call to add on synced but no remove or
> clear throughout the lifecycle of the IndexWriter instance.
> According to the Eclipse Memory Analyzer synced contains 32618 entries which
> look like file names "_e065_1.del" or "_e067.cfs"
> The index directory contains 10 files only.
> I guess synced is holding obsolete data 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to