Solr
  1. Solr
  2. SOLR-5714

You should be able to use one pool of memory for multiple collection's HDFS block caches.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.8, 6.0
    • Component/s: None
    • Labels:
      None

      Description

      Currently, you have to specify how much direct memory to allocate per SolrCore. This can be inefficient, and has some negative consequences - for instance, when replicating, many times two HDFS directories will exist for the same index briefly, which will double the RAM used for that SolrCore.

      1. SOLR-5714.patch
        42 kB
        Mark Miller
      2. SOLR-5714.patch
        40 kB
        Mark Miller
      3. SOLR-5714.patch
        40 kB
        Mark Miller
      4. SOLR-5714.patch
        21 kB
        Mark Miller

        Activity

        Hide
        Mark Miller added a comment -

        This patch adds a new init param to HdfsDirectoryFactory that allows it to use a global block cache rather than a block cache per SolrCore instance. It defaults to false if not present in solrconfig.xml for back compatibility. The latest solrconfig.xml will default it to true.

        A future improvement I'd like to make is the ability to configure some of the hdfs stuff at the solr.xml level, but I don't want to tie that into this issue.

        First cut attached.

        Show
        Mark Miller added a comment - This patch adds a new init param to HdfsDirectoryFactory that allows it to use a global block cache rather than a block cache per SolrCore instance. It defaults to false if not present in solrconfig.xml for back compatibility. The latest solrconfig.xml will default it to true. A future improvement I'd like to make is the ability to configure some of the hdfs stuff at the solr.xml level, but I don't want to tie that into this issue. First cut attached.
        Hide
        Hoss Man added a comment -

        It defaults to false if not present in solrconfig.xml for back compatibility. The latest solrconfig.xml will default it to true.

        Why not just make the implicit default (if not present in config) contingent on the luceneMatchVersion? if < 4.7, default=false; else default=true ?

        Show
        Hoss Man added a comment - It defaults to false if not present in solrconfig.xml for back compatibility. The latest solrconfig.xml will default it to true. Why not just make the implicit default (if not present in config) contingent on the luceneMatchVersion? if < 4.7, default=false; else default=true ?
        Hide
        Mark Miller added a comment -

        Yeah, will do.

        Show
        Mark Miller added a comment - Yeah, will do.
        Hide
        Mark Miller added a comment -

        Why not just make the implicit default (if not present in config) contingent on the luceneMatchVersion? if < 4.7, default=false; else default=true ?

        On further thought, I'm not sure I prefer that. It's kind of a special case - the global cache is created with the settings for the first directoryFactory that is created. It seems more normal for this to be per instance by default, and so I still kind of think it's best to default it to on, but require it to be there explicitly for that. It feels right that if you take it away, the configuration would apply per instance.

        And then clean it up eventually by allowing it to be configured via solr.xml or something.

        Show
        Mark Miller added a comment - Why not just make the implicit default (if not present in config) contingent on the luceneMatchVersion? if < 4.7, default=false; else default=true ? On further thought, I'm not sure I prefer that. It's kind of a special case - the global cache is created with the settings for the first directoryFactory that is created. It seems more normal for this to be per instance by default, and so I still kind of think it's best to default it to on, but require it to be there explicitly for that. It feels right that if you take it away, the configuration would apply per instance. And then clean it up eventually by allowing it to be configured via solr.xml or something.
        Hide
        Mark Miller added a comment -

        Here is a patch with an additional HDFS test.

        It creates N collections, all using the block cache with read and write caching and it concurrently adds and deletes documents for all of them and then does a search to check the counts.

        Show
        Mark Miller added a comment - Here is a patch with an additional HDFS test. It creates N collections, all using the block cache with read and write caching and it concurrently adds and deletes documents for all of them and then does a search to check the counts.
        Hide
        Gregory Chanan added a comment - - edited

        It's not clear this would cause any bugs, but the handling of creating the blockCache is unclear.

        The assignment:

                blockCache = createBlockCache(numberOfBlocksPerBank, blockSize, bankCount,directAllocation, slabSize, bufferSize, bufferCount);
        

        has no effect because the (static) blockCache is actually set in createBlockCache, independent of whether this is static or not:

        blockCache = new BlockCache(metrics, directAllocation, totalMemory, slabSize, blockSize);
        

        Probably should make the blockCache in createBlockCache a local variable to the function, not sharing a name with the static version.
        Same here, it would be better to rename:

        BlockCache blockCache = getBlockDirectoryCache
        

        Edit: actually I think this could cause a bug. What if one solrconfig.xml uses the global cache and another doesn't. The one that doesn't can overwrite the first's cache.

        Show
        Gregory Chanan added a comment - - edited It's not clear this would cause any bugs, but the handling of creating the blockCache is unclear. The assignment: blockCache = createBlockCache(numberOfBlocksPerBank, blockSize, bankCount,directAllocation, slabSize, bufferSize, bufferCount); has no effect because the (static) blockCache is actually set in createBlockCache, independent of whether this is static or not: blockCache = new BlockCache(metrics, directAllocation, totalMemory, slabSize, blockSize); Probably should make the blockCache in createBlockCache a local variable to the function, not sharing a name with the static version. Same here, it would be better to rename: BlockCache blockCache = getBlockDirectoryCache Edit: actually I think this could cause a bug. What if one solrconfig.xml uses the global cache and another doesn't. The one that doesn't can overwrite the first's cache.
        Hide
        Mark Miller added a comment -

        Thanks Greg! That static name shadowing was definitely hiding some silliness there.

        I've renamed the blockCache field to globalBlockCache and put in local variables where they belong.

        Show
        Mark Miller added a comment - Thanks Greg! That static name shadowing was definitely hiding some silliness there. I've renamed the blockCache field to globalBlockCache and put in local variables where they belong.
        Hide
        Gregory Chanan added a comment -

        New change looks good to me.

        A couple of questions:

        • Is there a test that checks that the global block cache is actually used? I see that its turned on randomly, so we know turning it on doesn't break things, but does it actually do what it says it does?
        • Are there any downsides to using a global block cache? In the motivation above, it's to promote sharing on the same index, but we are sharing globally. Why not share on just the same index?
        Show
        Gregory Chanan added a comment - New change looks good to me. A couple of questions: Is there a test that checks that the global block cache is actually used? I see that its turned on randomly, so we know turning it on doesn't break things, but does it actually do what it says it does? Are there any downsides to using a global block cache? In the motivation above, it's to promote sharing on the same index, but we are sharing globally. Why not share on just the same index?
        Hide
        Mark Miller added a comment -

        Adds testing that asserts that all the BlockCache instances for each SolrCore are the same instance when global cache is on and checks for different instances as it jumps through each SolrCore when the global cache is off.

        Show
        Mark Miller added a comment - Adds testing that asserts that all the BlockCache instances for each SolrCore are the same instance when global cache is on and checks for different instances as it jumps through each SolrCore when the global cache is off.
        Hide
        Mark Miller added a comment -

        Are there any downsides to using a global block cache? In the motivation above, it's to promote sharing on the same index, but we are sharing globally. Why not share on just the same index?

        There are not a lot of downsides. Perhaps some extra contention if you have a ton of collections and perhaps different LRU behavior across collections than you might want for some use cases. I think by and large, the benefits of one global pool of memory will out weigh those smaller issues by a good extent. Trying to figure out how much to give each collection is fairly difficult - and some collections may be starving for RAM at certain times while other collections are using very little of their pre allocated RAM. Unless you have so much RAM that you can just give gobs of it to each SolrCore, I imagine one pool will be much more user friendly and efficient in the standard case.

        Show
        Mark Miller added a comment - Are there any downsides to using a global block cache? In the motivation above, it's to promote sharing on the same index, but we are sharing globally. Why not share on just the same index? There are not a lot of downsides. Perhaps some extra contention if you have a ton of collections and perhaps different LRU behavior across collections than you might want for some use cases. I think by and large, the benefits of one global pool of memory will out weigh those smaller issues by a good extent. Trying to figure out how much to give each collection is fairly difficult - and some collections may be starving for RAM at certain times while other collections are using very little of their pre allocated RAM. Unless you have so much RAM that you can just give gobs of it to each SolrCore, I imagine one pool will be much more user friendly and efficient in the standard case.
        Hide
        Mark Miller added a comment -

        To add a bit: I wanted to do this even before realizing the same index issue - because these caches allocate the memory up front, users have already been running into issues when trying to use multiple collections. The same index issue just made matters even worse because it wouldn't like be an issue until the worse time - during recovery.

        By and large though, I think we will have fewer user issues if they can simply decide up front how much RAM they can dedicate to HDFS caching and let Solr work out the rest across their collections. It's more dynamic and takes a large burden off the user.

        Show
        Mark Miller added a comment - To add a bit: I wanted to do this even before realizing the same index issue - because these caches allocate the memory up front, users have already been running into issues when trying to use multiple collections. The same index issue just made matters even worse because it wouldn't like be an issue until the worse time - during recovery. By and large though, I think we will have fewer user issues if they can simply decide up front how much RAM they can dedicate to HDFS caching and let Solr work out the rest across their collections. It's more dynamic and takes a large burden off the user.
        Hide
        Gregory Chanan added a comment -

        lgtm +1.

        Show
        Gregory Chanan added a comment - lgtm +1.
        Hide
        ASF subversion and git services added a comment -

        Commit 1573847 from Mark Miller in branch 'dev/trunk'
        [ https://svn.apache.org/r1573847 ]

        SOLR-5714: You can now use one pool of memory for for the HDFS block cache that all collections share.

        Show
        ASF subversion and git services added a comment - Commit 1573847 from Mark Miller in branch 'dev/trunk' [ https://svn.apache.org/r1573847 ] SOLR-5714 : You can now use one pool of memory for for the HDFS block cache that all collections share.
        Hide
        ASF subversion and git services added a comment -

        Commit 1573849 from Mark Miller in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1573849 ]

        SOLR-5714: You can now use one pool of memory for for the HDFS block cache that all collections share.

        Show
        ASF subversion and git services added a comment - Commit 1573849 from Mark Miller in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1573849 ] SOLR-5714 : You can now use one pool of memory for for the HDFS block cache that all collections share.
        Hide
        Mark Miller added a comment -

        Thanks for the review Greg!

        Show
        Mark Miller added a comment - Thanks for the review Greg!
        Hide
        Markus Jelsma added a comment -

        Mark, the SVN log pointed me to this issue, did you forget to add/commit StopableIndexingThread? Many unit tests fail to compile due to StopableIndexingThread.

        Show
        Markus Jelsma added a comment - Mark, the SVN log pointed me to this issue, did you forget to add/commit StopableIndexingThread? Many unit tests fail to compile due to StopableIndexingThread.
        Hide
        Mark Miller added a comment -

        Hey Markus, not sure what you are seeing. Looking at the commit tags above:

        "lucene/dev/trunk/solr/test-framework/src/java/org/apache/solr/cloud/StopableIndexingThread.java added"

        Show
        Mark Miller added a comment - Hey Markus, not sure what you are seeing. Looking at the commit tags above: "lucene/dev/trunk/solr/test-framework/src/java/org/apache/solr/cloud/StopableIndexingThread.java added"
        Hide
        Markus Jelsma added a comment -

        Hi Mark! I get stuff like:

        common.compile-test:
            [javac] Compiling 365 source files to /home/markus/src/solr/trunk/solr/build/solr-core/classes/test
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:35: error: cannot find symbol
            [javac] import org.apache.solr.cloud.StopableIndexingThread;
            [javac]                             ^
            [javac]   symbol:   class StopableIndexingThread
            [javac]   location: package org.apache.solr.cloud
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyNothingIsSafeTest.java:134: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer,String,boolean)
            [javac]         StopableIndexingThread indexThread = new StopableIndexingThread(controlClient, cloudClient, Integer.toString(i), true);
            [javac]                                              ^
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean,int) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyNothingIsSafeTest.java:273: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer,String,boolean)
            [javac]       super(controlClient, cloudClient, id, doDeletes);
            [javac]       ^
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean,int) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/ChaosMonkeySafeLeaderTest.java:111: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer,String,boolean)
            [javac]       StopableIndexingThread indexThread = new StopableIndexingThread(controlClient, cloudClient, Integer.toString(i), true);
            [javac]                                            ^
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean,int) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/RecoveryZkTest.java:69: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer,String,boolean,int)
            [javac]     indexThread = new StopableIndexingThread(controlClient, cloudClient, "1", true, maxDoc);
            [javac]                   ^
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean,int) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/RecoveryZkTest.java:72: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer,String,boolean,int)
            [javac]     indexThread2 = new StopableIndexingThread(controlClient, cloudClient, "2", true, maxDoc);
            [javac]                    ^
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean,int) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac]     constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread(String,boolean) is not applicable
            [javac]       (actual and formal argument lists differ in length)
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:102: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package
            [javac]     List<StopableIndexingThread> threads = new ArrayList<StopableIndexingThread>();
            [javac]          ^
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:102: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package
            [javac]     List<StopableIndexingThread> threads = new ArrayList<StopableIndexingThread>();
            [javac]                                                          ^
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:107: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package
            [javac]       StopableIndexingThread indexThread = new StopableIndexingThread(null, server, "1", true, docCount);
            [javac]       ^
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:107: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package
            [javac]       StopableIndexingThread indexThread = new StopableIndexingThread(null, server, "1", true, docCount);
            [javac]                                                ^
            [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:113: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package
            [javac]     for (StopableIndexingThread thread : threads) {
            [javac]          ^
            [javac] Note: Some input files use or override a deprecated API.
            [javac] Note: Recompile with -Xlint:deprecation for details.
            [javac] Note: Some input files use unchecked or unsafe operations.
            [javac] Note: Recompile with -Xlint:unchecked for details.
            [javac] 11 errors
        
        
        Show
        Markus Jelsma added a comment - Hi Mark! I get stuff like: common.compile-test: [javac] Compiling 365 source files to /home/markus/src/solr/trunk/solr/build/solr-core/classes/test [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:35: error: cannot find symbol [javac] import org.apache.solr.cloud.StopableIndexingThread; [javac] ^ [javac] symbol: class StopableIndexingThread [javac] location: package org.apache.solr.cloud [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyNothingIsSafeTest.java:134: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer, String , boolean ) [javac] StopableIndexingThread indexThread = new StopableIndexingThread(controlClient, cloudClient, Integer .toString(i), true ); [javac] ^ [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean , int ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/ChaosMonkeyNothingIsSafeTest.java:273: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer, String , boolean ) [javac] super (controlClient, cloudClient, id, doDeletes); [javac] ^ [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean , int ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/ChaosMonkeySafeLeaderTest.java:111: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer, String , boolean ) [javac] StopableIndexingThread indexThread = new StopableIndexingThread(controlClient, cloudClient, Integer .toString(i), true ); [javac] ^ [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean , int ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/RecoveryZkTest.java:69: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer, String , boolean , int ) [javac] indexThread = new StopableIndexingThread(controlClient, cloudClient, "1" , true , maxDoc); [javac] ^ [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean , int ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/RecoveryZkTest.java:72: error: no suitable constructor found for StopableIndexingThread(SolrServer,CloudSolrServer, String , boolean , int ) [javac] indexThread2 = new StopableIndexingThread(controlClient, cloudClient, "2" , true , maxDoc); [javac] ^ [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean , int ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] constructor AbstractFullDistribZkTestBase.StopableIndexingThread.AbstractFullDistribZkTestBase.StopableIndexingThread( String , boolean ) is not applicable [javac] (actual and formal argument lists differ in length) [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:102: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package [javac] List<StopableIndexingThread> threads = new ArrayList<StopableIndexingThread>(); [javac] ^ [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:102: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package [javac] List<StopableIndexingThread> threads = new ArrayList<StopableIndexingThread>(); [javac] ^ [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:107: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package [javac] StopableIndexingThread indexThread = new StopableIndexingThread( null , server, "1" , true , docCount); [javac] ^ [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:107: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package [javac] StopableIndexingThread indexThread = new StopableIndexingThread( null , server, "1" , true , docCount); [javac] ^ [javac] /home/markus/src/solr/trunk/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsWriteToMultipleCollectionsTest.java:113: error: AbstractFullDistribZkTestBase.StopableIndexingThread is not public in AbstractFullDistribZkTestBase; cannot be accessed from outside package [javac] for (StopableIndexingThread thread : threads) { [javac] ^ [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. [javac] 11 errors
        Hide
        Mark Miller added a comment -

        Are you doing a clean first?

        Show
        Mark Miller added a comment - Are you doing a clean first?
        Hide
        Markus Jelsma added a comment -

        I remove the build directory. I just tried again and it failed. However, i did another svn up and i finally got the correct update. It sometimes happens that multiple svn ups do not download all files of the revision, perhaps because im using the EU svn?

        Show
        Markus Jelsma added a comment - I remove the build directory. I just tried again and it failed. However, i did another svn up and i finally got the correct update. It sometimes happens that multiple svn ups do not download all files of the revision, perhaps because im using the EU svn?
        Hide
        Uwe Schindler added a comment -

        Close issue after release of 4.8.0

        Show
        Uwe Schindler added a comment - Close issue after release of 4.8.0

          People

          • Assignee:
            Mark Miller
            Reporter:
            Mark Miller
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development