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

Robert Muir commented on LUCENE-6072:
-------------------------------------

Also, not to justify the craziness, but i dont think we can trust the JDK to 
implement these "pass thru" ones.

Every one they do (FilterInputStream, FilterOutputStream, FilterReader) has 
horrible performance / delegation bugs.

I found this out because when i initially developed this, i used 
FilterInputStream and FilterOutputStream, and suddenly like 10% of tests had 
beating hearts and were taking forever. After profiling tests, its because if 
you subclass these classes (even to just intercept 'close' or whatever), then 
suddenly all bytes are being written/read one byte at a time, and i think even 
boxed inside byte[1]'s and so on. 

> Use mock filesystem in tests
> ----------------------------
>
>                 Key: LUCENE-6072
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6072
>             Project: Lucene - Core
>          Issue Type: Test
>            Reporter: Robert Muir
>         Attachments: LUCENE-6072.patch, LUCENE-6072.patch, LUCENE-6072.patch
>
>
> We went through the trouble to convert to NIO.2, but we don't take advantage 
> of it in tests...
> Since everything boils down to LuceneTestCase's temp dir (which is just 
> Path), we can wrap the filesystem with useful stuff:
> * detect file handle leaks (better than mockdir: not just index files)
> * act like windows (don't delete open files, case-insensitivity, etc)
> * verbosity (add what is going on to infostream for debugging)
> I prototyped some of this in a patch. Currently it makes a chain like this:
> {code}
>   private FileSystem initializeFileSystem() {
>     FileSystem fs = FileSystems.getDefault();
>     if (LuceneTestCase.VERBOSE) {
>       fs = new VerboseFS(fs,
>                 new PrintStreamInfoStream(System.out)).getFileSystem(null);
>     }
>     fs = new LeakFS(fs).getFileSystem(null);
>     fs = new WindowsFS(fs).getFileSystem(null);
>     return fs.provider().getFileSystem(URI.create("file:///"));
>   }
> {code}
> Some things to figure out:
> * I don't think we want to wrap all the time (worry about hiding bugs)
> * its currently a bit lenient (e.g. these filesystems allow calling toFile, 
> which can "escape" and allow you to do broken things). But only 2 or 3 tests 
> really need File, so we could fix that.
> * its currently complicated and messy (i blame the jdk api here, but maybe we 
> can simplify it)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to