FAQ
Hi,

The DirectUpdateHandlerOptimizeTest fails on my local box due to too many
open files. The nightly build does not fail so I'm assuming it must be
something specific to my setup. Has anyone else seen this problem on their
local environment?

ulimit -n gives 1024 on my Ubuntu Hardy Heron.

<testcase classname="org.apache.solr.update.DirectUpdateHandlerOptimizeTest"
name="testOptimize" time="5.687">
<error message="java.io.FileNotFoundException:
/tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
(Too many open files)"
type="java.lang.RuntimeException">java.lang.RuntimeException:
java.io.FileNotFoundException:
/tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
(Too many open files)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
at
org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)
at
org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)
Caused by: java.io.FileNotFoundException:
/tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
(Too many open files)
at java.io.RandomAccessFile.open(Native Method)
at java.io.RandomAccessFile.&lt;init&gt;(RandomAccessFile.java:212)
at
org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.&lt;init&gt;(FSDirectory.java:539)
at
org.apache.lucene.store.FSDirectory$FSIndexInput.&lt;init&gt;(FSDirectory.java:569)
at
org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
at
org.apache.lucene.index.TermInfosReader.&lt;init&gt;(TermInfosReader.java:80)
at
org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)
at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)
at
org.apache.lucene.index.MultiSegmentReader.&lt;init&gt;(MultiSegmentReader.java:55)
at
org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
at
org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
at
org.apache.solr.search.SolrIndexSearcher.&lt;init&gt;(SolrIndexSearcher.java:93)
at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
</error>
</testcase>


--
Regards,
Shalin Shekhar Mangar.

Search Discussions

  • Yonik Seeley at Jul 20, 2008 at 9:29 pm
    Does it happen on a fresh checkout?
    I use windows (and cygwin for the familiar command line interface),
    which has higher limits.

    Also watch out for the system-wide limit:
    http://www.cs.wisc.edu/condor/condorg/linux_scalability.html

    If it happens with a fresh checkout, perhaps we could lower the merge
    factor for that test.

    -Yonik

    On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar
    wrote:
    Hi,

    The DirectUpdateHandlerOptimizeTest fails on my local box due to too many
    open files. The nightly build does not fail so I'm assuming it must be
    something specific to my setup. Has anyone else seen this problem on their
    local environment?

    ulimit -n gives 1024 on my Ubuntu Hardy Heron.

    <testcase classname="org.apache.solr.update.DirectUpdateHandlerOptimizeTest"
    name="testOptimize" time="5.687">
    <error message="java.io.FileNotFoundException:
    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)"
    type="java.lang.RuntimeException">java.lang.RuntimeException:
    java.io.FileNotFoundException:
    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
    at
    org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)
    at
    org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)
    Caused by: java.io.FileNotFoundException:
    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at java.io.RandomAccessFile.open(Native Method)
    at java.io.RandomAccessFile.&lt;init&gt;(RandomAccessFile.java:212)
    at
    org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.&lt;init&gt;(FSDirectory.java:539)
    at
    org.apache.lucene.store.FSDirectory$FSIndexInput.&lt;init&gt;(FSDirectory.java:569)
    at
    org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
    at
    org.apache.lucene.index.TermInfosReader.&lt;init&gt;(TermInfosReader.java:80)
    at
    org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
    at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)
    at org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)
    at
    org.apache.lucene.index.MultiSegmentReader.&lt;init&gt;(MultiSegmentReader.java:55)
    at
    org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)
    at
    org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
    at
    org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
    at
    org.apache.solr.search.SolrIndexSearcher.&lt;init&gt;(SolrIndexSearcher.java:93)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
    </error>
    </testcase>


    --
    Regards,
    Shalin Shekhar Mangar.
  • Shalin Shekhar Mangar at Jul 21, 2008 at 3:10 pm
    Yes, it happens on a fresh checkout too.

    cat /proc/sys/fs/file-max gives 204979 on my box. The test which fails is
    testOptimize.

    I increased the file handle limit to 4096 but it still fails. Then I
    increased it to 16384 and the test passed.
    On Mon, Jul 21, 2008 at 2:58 AM, Yonik Seeley wrote:

    Does it happen on a fresh checkout?
    I use windows (and cygwin for the familiar command line interface),
    which has higher limits.

    Also watch out for the system-wide limit:
    http://www.cs.wisc.edu/condor/condorg/linux_scalability.html

    If it happens with a fresh checkout, perhaps we could lower the merge
    factor for that test.

    -Yonik

    On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar
    wrote:
    Hi,

    The DirectUpdateHandlerOptimizeTest fails on my local box due to too many
    open files. The nightly build does not fail so I'm assuming it must be
    something specific to my setup. Has anyone else seen this problem on their
    local environment?

    ulimit -n gives 1024 on my Ubuntu Hardy Heron.

    <testcase
    classname="org.apache.solr.update.DirectUpdateHandlerOptimizeTest"
    name="testOptimize" time="5.687">
    <error message="java.io.FileNotFoundException:
    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)"
    type="java.lang.RuntimeException">java.lang.RuntimeException:
    java.io.FileNotFoundException:
    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
    at
    org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)
    at
    org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)
    Caused by: java.io.FileNotFoundException:
    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at java.io.RandomAccessFile.open(Native Method)
    at
    java.io.RandomAccessFile.&lt;init&gt;(RandomAccessFile.java:212)
    at
    org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.&lt;init&gt;(FSDirectory.java:539)
    at
    org.apache.lucene.store.FSDirectory$FSIndexInput.&lt;init&gt;(FSDirectory.java:569)
    at
    org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
    at
    org.apache.lucene.index.TermInfosReader.&lt;init&gt;(TermInfosReader.java:80)
    at
    org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)
    at
    org.apache.lucene.index.MultiSegmentReader.&lt;init&gt;(MultiSegmentReader.java:55)
    at
    org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)
    at
    org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
    at
    org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
    at
    org.apache.solr.search.SolrIndexSearcher.&lt;init&gt;(SolrIndexSearcher.java:93)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
    </error>
    </testcase>


    --
    Regards,
    Shalin Shekhar Mangar.


    --
    Regards,
    Shalin Shekhar Mangar.
  • Tricia Williams at Jul 29, 2008 at 7:40 pm
    This same thing happens to me since DirectUpdateHandlerOptimizeTest was
    added to the repository.

    How does one increase the file handle limit in ubuntu?

    Thanks,
    Tricia

    Shalin Shekhar Mangar wrote:
    Yes, it happens on a fresh checkout too.

    cat /proc/sys/fs/file-max gives 204979 on my box. The test which fails is
    testOptimize.

    I increased the file handle limit to 4096 but it still fails. Then I
    increased it to 16384 and the test passed.

    On Mon, Jul 21, 2008 at 2:58 AM, Yonik Seeley wrote:

    Does it happen on a fresh checkout?
    I use windows (and cygwin for the familiar command line interface),
    which has higher limits.

    Also watch out for the system-wide limit:
    http://www.cs.wisc.edu/condor/condorg/linux_scalability.html

    If it happens with a fresh checkout, perhaps we could lower the merge
    factor for that test.

    -Yonik

    On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar
    wrote:
    Hi,

    The DirectUpdateHandlerOptimizeTest fails on my local box due to too many
    open files. The nightly build does not fail so I'm assuming it must be
    something specific to my setup. Has anyone else seen this problem on their
    local environment?

    ulimit -n gives 1024 on my Ubuntu Hardy Heron.

    <testcase
    classname="org.apache.solr.update.DirectUpdateHandlerOptimizeTest"
    name="testOptimize" time="5.687">
    <error message="java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)"
    type="java.lang.RuntimeException">java.lang.RuntimeException:
    java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
    at

    org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)
    at

    org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)
    Caused by: java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at java.io.RandomAccessFile.open(Native Method)
    at
    java.io.RandomAccessFile.&lt;init&gt;(RandomAccessFile.java:212)
    at

    org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.&lt;init&gt;(FSDirectory.java:539)
    at

    org.apache.lucene.store.FSDirectory$FSIndexInput.&lt;init&gt;(FSDirectory.java:569)
    at
    org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
    at

    org.apache.lucene.index.TermInfosReader.&lt;init&gt;(TermInfosReader.java:80)
    at
    org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)
    at

    org.apache.lucene.index.MultiSegmentReader.&lt;init&gt;(MultiSegmentReader.java:55)
    at

    org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)
    at

    org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
    at

    org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
    at

    org.apache.solr.search.SolrIndexSearcher.&lt;init&gt;(SolrIndexSearcher.java:93)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
    </error>
    </testcase>


    --
    Regards,
    Shalin Shekhar Mangar.

  • Shalin Shekhar Mangar at Jul 29, 2008 at 7:44 pm
    You can increase it through /etc/security/limits.conf in ubuntu

    On Wed, Jul 30, 2008 at 1:09 AM, Tricia Williams
    wrote:
    This same thing happens to me since DirectUpdateHandlerOptimizeTest was
    added to the repository.

    How does one increase the file handle limit in ubuntu?

    Thanks,
    Tricia


    Shalin Shekhar Mangar wrote:
    Yes, it happens on a fresh checkout too.

    cat /proc/sys/fs/file-max gives 204979 on my box. The test which fails is
    testOptimize.

    I increased the file handle limit to 4096 but it still fails. Then I
    increased it to 16384 and the test passed.

    On Mon, Jul 21, 2008 at 2:58 AM, Yonik Seeley wrote:


    Does it happen on a fresh checkout?
    I use windows (and cygwin for the familiar command line interface),
    which has higher limits.

    Also watch out for the system-wide limit:
    http://www.cs.wisc.edu/condor/condorg/linux_scalability.html

    If it happens with a fresh checkout, perhaps we could lower the merge
    factor for that test.

    -Yonik

    On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar
    wrote:

    Hi,

    The DirectUpdateHandlerOptimizeTest fails on my local box due to too
    many
    open files. The nightly build does not fail so I'm assuming it must be
    something specific to my setup. Has anyone else seen this problem on
    their

    local environment?

    ulimit -n gives 1024 on my Ubuntu Hardy Heron.

    <testcase
    classname="org.apache.solr.update.DirectUpdateHandlerOptimizeTest"

    name="testOptimize" time="5.687">
    <error message="java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii

    (Too many open files)"
    type="java.lang.RuntimeException">java.lang.RuntimeException:
    java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii

    (Too many open files)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
    at

    org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)

    at

    org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)

    Caused by: java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii

    (Too many open files)
    at java.io.RandomAccessFile.open(Native Method)
    at
    java.io.RandomAccessFile.&lt;init&gt;(RandomAccessFile.java:212)

    at

    org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.&lt;init&gt;(FSDirectory.java:539)

    at

    org.apache.lucene.store.FSDirectory$FSIndexInput.&lt;init&gt;(FSDirectory.java:569)

    at
    org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
    at

    org.apache.lucene.index.TermInfosReader.&lt;init&gt;(TermInfosReader.java:80)

    at
    org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)

    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)

    at

    org.apache.lucene.index.MultiSegmentReader.&lt;init&gt;(MultiSegmentReader.java:55)

    at

    org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)

    at

    org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)

    at

    org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)

    at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
    at

    org.apache.solr.search.SolrIndexSearcher.&lt;init&gt;(SolrIndexSearcher.java:93)

    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
    </error>
    </testcase>


    --
    Regards,
    Shalin Shekhar Mangar.



    --
    Regards,
    Shalin Shekhar Mangar.
  • Yonik Seeley at Jul 29, 2008 at 8:13 pm
    I just committed a fix that will make the test use the compound file
    format. Hopefully that will be sufficient.

    -Yonik

    On Tue, Jul 29, 2008 at 3:39 PM, Tricia Williams
    wrote:
    This same thing happens to me since DirectUpdateHandlerOptimizeTest was
    added to the repository.

    How does one increase the file handle limit in ubuntu?

    Thanks,
    Tricia

    Shalin Shekhar Mangar wrote:
    Yes, it happens on a fresh checkout too.

    cat /proc/sys/fs/file-max gives 204979 on my box. The test which fails is
    testOptimize.

    I increased the file handle limit to 4096 but it still fails. Then I
    increased it to 16384 and the test passed.

    On Mon, Jul 21, 2008 at 2:58 AM, Yonik Seeley wrote:

    Does it happen on a fresh checkout?
    I use windows (and cygwin for the familiar command line interface),
    which has higher limits.

    Also watch out for the system-wide limit:
    http://www.cs.wisc.edu/condor/condorg/linux_scalability.html

    If it happens with a fresh checkout, perhaps we could lower the merge
    factor for that test.

    -Yonik

    On Sun, Jul 20, 2008 at 2:59 PM, Shalin Shekhar Mangar
    wrote:
    Hi,

    The DirectUpdateHandlerOptimizeTest fails on my local box due to too
    many
    open files. The nightly build does not fail so I'm assuming it must be
    something specific to my setup. Has anyone else seen this problem on their
    local environment?

    ulimit -n gives 1024 on my Ubuntu Hardy Heron.

    <testcase
    classname="org.apache.solr.update.DirectUpdateHandlerOptimizeTest"
    name="testOptimize" time="5.687">
    <error message="java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)"
    type="java.lang.RuntimeException">java.lang.RuntimeException:
    java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:806)
    at

    org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:368)
    at

    org.apache.solr.update.DirectUpdateHandlerOptimizeTest.testOptimize(DirectUpdateHandlerOptimizeTest.java:62)
    Caused by: java.io.FileNotFoundException:

    /tmp/org.apache.solr.update.DirectUpdateHandlerOptimizeTest-1216580007333/index/_9u.tii
    (Too many open files)
    at java.io.RandomAccessFile.open(Native Method)
    at
    java.io.RandomAccessFile.&lt;init&gt;(RandomAccessFile.java:212)
    at

    org.apache.lucene.store.FSDirectory$FSIndexInput$Descriptor.&lt;init&gt;(FSDirectory.java:539)
    at

    org.apache.lucene.store.FSDirectory$FSIndexInput.&lt;init&gt;(FSDirectory.java:569)
    at
    org.apache.lucene.store.FSDirectory.openInput(FSDirectory.java:478)
    at

    org.apache.lucene.index.TermInfosReader.&lt;init&gt;(TermInfosReader.java:80)
    at
    org.apache.lucene.index.SegmentReader.initialize(SegmentReader.java:319)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:264)
    at
    org.apache.lucene.index.SegmentReader.get(SegmentReader.java:199)
    at

    org.apache.lucene.index.MultiSegmentReader.&lt;init&gt;(MultiSegmentReader.java:55)
    at

    org.apache.lucene.index.DirectoryIndexReader$1.doBody(DirectoryIndexReader.java:93)
    at

    org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:649)
    at

    org.apache.lucene.index.DirectoryIndexReader.open(DirectoryIndexReader.java:81)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:209)
    at org.apache.lucene.index.IndexReader.open(IndexReader.java:173)
    at

    org.apache.solr.search.SolrIndexSearcher.&lt;init&gt;(SolrIndexSearcher.java:93)
    at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:797)
    </error>
    </testcase>


    --
    Regards,
    Shalin Shekhar Mangar.

  • Tricia Williams at Jul 29, 2008 at 8:54 pm
    As of revision 680834 the DirectUpdateHandlerOptimizeTest is still
    failing. I haven't made any changes to the file handle limit on my machine.

    Tricia

    Yonik Seeley wrote:
    I just committed a fix that will make the test use the compound file
    format. Hopefully that will be sufficient.

    -Yonik
  • Yonik Seeley at Jul 29, 2008 at 8:58 pm
    OK, I've now scaled back the test by a factor of 10 (50 segments
    instead of 500).
    -Yonik

    On Tue, Jul 29, 2008 at 4:53 PM, Tricia Williams
    wrote:
    As of revision 680834 the DirectUpdateHandlerOptimizeTest is still failing.
    I haven't made any changes to the file handle limit on my machine.

    Tricia

    Yonik Seeley wrote:
    I just committed a fix that will make the test use the compound file
    format. Hopefully that will be sufficient.

    -Yonik
  • Tricia Williams at Jul 29, 2008 at 9:58 pm
    Works for me!

    I don't really understand the purpose of the test, but it looks like it
    is meant as a weak stress test. If the test is significantly scaled
    back, is the test still accomplishing what it is mean to do? Should the
    onus instead be on the developer to meet a minimum requirement? Would
    this same problem crop up in normal (or even abnormal) usage of Solr
    deployed on a similar system?

    Tricia

    Yonik Seeley wrote:
    OK, I've now scaled back the test by a factor of 10 (50 segments
    instead of 500).
    -Yonik

    On Tue, Jul 29, 2008 at 4:53 PM, Tricia Williams
    wrote:
    As of revision 680834 the DirectUpdateHandlerOptimizeTest is still failing.
    I haven't made any changes to the file handle limit on my machine.

    Tricia

    Yonik Seeley wrote:
    I just committed a fix that will make the test use the compound file
    format. Hopefully that will be sufficient.

    -Yonik

  • Yonik Seeley at Jul 29, 2008 at 10:03 pm
    It looked to me like it was just to test that optimize actually works
    (and that setting maxOptimizeSegments actually worked).

    -Yonik

    On Tue, Jul 29, 2008 at 5:58 PM, Tricia Williams
    wrote:
    Works for me!
    I don't really understand the purpose of the test, but it looks like it is
    meant as a weak stress test. If the test is significantly scaled back, is
    the test still accomplishing what it is mean to do? Should the onus instead
    be on the developer to meet a minimum requirement? Would this same problem
    crop up in normal (or even abnormal) usage of Solr deployed on a similar
    system?

    Tricia

    Yonik Seeley wrote:
    OK, I've now scaled back the test by a factor of 10 (50 segments
    instead of 500).
    -Yonik

    On Tue, Jul 29, 2008 at 4:53 PM, Tricia Williams
    wrote:
    As of revision 680834 the DirectUpdateHandlerOptimizeTest is still
    failing.
    I haven't made any changes to the file handle limit on my machine.

    Tricia

    Yonik Seeley wrote:
    I just committed a fix that will make the test use the compound file
    format. Hopefully that will be sufficient.

    -Yonik

  • Shalin Shekhar Mangar at Jul 30, 2008 at 3:20 am
    Works for me too. Thanks Yonik!

    On Wed, Jul 30, 2008 at 3:28 AM, Tricia Williams
    wrote:
    Works for me!
    I don't really understand the purpose of the test, but it looks like it is
    meant as a weak stress test. If the test is significantly scaled back, is
    the test still accomplishing what it is mean to do? Should the onus instead
    be on the developer to meet a minimum requirement? Would this same problem
    crop up in normal (or even abnormal) usage of Solr deployed on a similar
    system?

    Tricia


    Yonik Seeley wrote:
    OK, I've now scaled back the test by a factor of 10 (50 segments
    instead of 500).
    -Yonik

    On Tue, Jul 29, 2008 at 4:53 PM, Tricia Williams
    wrote:

    As of revision 680834 the DirectUpdateHandlerOptimizeTest is still
    failing.
    I haven't made any changes to the file handle limit on my machine.

    Tricia

    Yonik Seeley wrote:

    I just committed a fix that will make the test use the compound file
    format. Hopefully that will be sufficient.

    -Yonik



    --
    Regards,
    Shalin Shekhar Mangar.
  • Grant Ingersoll at Jul 30, 2008 at 8:27 pm
    For the record, the test was meant to test the new partial optimize
    capabilities by counting the number of segments available after doing
    partial optimizes.

    -Grant
    On Jul 29, 2008, at 5:58 PM, Tricia Williams wrote:

    Works for me!
    I don't really understand the purpose of the test, but it looks like
    it is meant as a weak stress test. If the test is significantly
    scaled back, is the test still accomplishing what it is mean to do?
    Should the onus instead be on the developer to meet a minimum
    requirement? Would this same problem crop up in normal (or even
    abnormal) usage of Solr deployed on a similar system?

    Tricia

    Yonik Seeley wrote:
    OK, I've now scaled back the test by a factor of 10 (50 segments
    instead of 500).
    -Yonik

    On Tue, Jul 29, 2008 at 4:53 PM, Tricia Williams
    wrote:
    As of revision 680834 the DirectUpdateHandlerOptimizeTest is still
    failing.
    I haven't made any changes to the file handle limit on my machine.

    Tricia

    Yonik Seeley wrote:
    I just committed a fix that will make the test use the compound
    file
    format. Hopefully that will be sufficient.

    -Yonik

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupsolr-dev @
categorieslucene
postedJul 20, '08 at 6:59p
activeJul 30, '08 at 8:27p
posts12
users4
websitelucene.apache.org...

People

Translate

site design / logo © 2019 Grokbase