Lucene - Core
  1. Lucene - Core
  2. LUCENE-5463

Make RamUsageEstimator.(human)sizeOf(Object) a forbidden API

    Details

    • Type: Task Task
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.8
    • Component/s: None
    • Labels:
      None
    • Lucene Fields:
      New

      Description

      We have had a few issues with RamUsageEstimator recently so I think we should consider making the sizeOf(Object) and humanSizeOf(Object) methods forbidden under src/java (however still allowed for tests as it is handy to check the size computations which are done "manually"). However, sizeOf(byte[]), shallowSizeOf(Class), etc. remain useful so I think we should keep them allowed.

      1. LUCENE-5463.patch
        16 kB
        Adrien Grand
      2. LUCENE-5463.patch
        3 kB
        Robert Muir
      3. LUCENE-5463-2.patch
        10 kB
        Adrien Grand
      4. LUCENE-5463-2.patch
        9 kB
        Adrien Grand

        Activity

        Hide
        Simon Willnauer added a comment -

        +1

        Show
        Simon Willnauer added a comment - +1
        Hide
        Robert Muir added a comment -

        quick patch: I tried to clean things up so its clear which rules apply to:
        1) both source and test code
        2) just source code
        3) just test code

        some things fail that we must deal with:

        [forbidden-apis] Reading bundled API signatures: jdk-system-out
        [forbidden-apis] Reading API signatures: /home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/rue.txt
        [forbidden-apis] Loading classes to check...
        [forbidden-apis] Scanning for API signatures and dependencies...
        [forbidden-apis] Forbidden method invocation: org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) [slow]
        [forbidden-apis]   in org.apache.lucene.util.RamUsageEstimator (RamUsageEstimator.java:586)
        [forbidden-apis] Forbidden method invocation: org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) [slow]
        [forbidden-apis]   in org.apache.lucene.search.CachingWrapperFilter (CachingWrapperFilter.java:163)
        [forbidden-apis] Forbidden method invocation: org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) [slow]
        [forbidden-apis]   in org.apache.lucene.search.FieldCache$CacheEntry (FieldCache.java:496)
        [forbidden-apis] Scanned 1411 (and 173 related) class file(s) for forbidden API invocations (in 0.16s), 3 error(s).
        
        Show
        Robert Muir added a comment - quick patch: I tried to clean things up so its clear which rules apply to: 1) both source and test code 2) just source code 3) just test code some things fail that we must deal with: [forbidden-apis] Reading bundled API signatures: jdk-system-out [forbidden-apis] Reading API signatures: /home/rmuir/workspace/lucene-trunk/lucene/tools/forbiddenApis/rue.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) [slow] [forbidden-apis] in org.apache.lucene.util.RamUsageEstimator (RamUsageEstimator.java:586) [forbidden-apis] Forbidden method invocation: org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) [slow] [forbidden-apis] in org.apache.lucene.search.CachingWrapperFilter (CachingWrapperFilter.java:163) [forbidden-apis] Forbidden method invocation: org.apache.lucene.util.RamUsageEstimator#sizeOf(java.lang.Object) [slow] [forbidden-apis] in org.apache.lucene.search.FieldCache$CacheEntry (FieldCache.java:496) [forbidden-apis] Scanned 1411 (and 173 related) class file(s) for forbidden API invocations (in 0.16s), 3 error(s).
        Hide
        Robert Muir added a comment -

        Personally i dont like whats going on in CachingWrapperFilter. Maybe Filter should have an explicit method for this?

        as far as FieldCache... whatever goes

        Show
        Robert Muir added a comment - Personally i dont like whats going on in CachingWrapperFilter. Maybe Filter should have an explicit method for this? as far as FieldCache... whatever goes
        Hide
        Adrien Grand added a comment -

        I think it would be great to have a ramBytesUsed method on filters. That is needed anyway if you want to take the memory size into account for evictions.

        Show
        Adrien Grand added a comment - I think it would be great to have a ramBytesUsed method on filters. That is needed anyway if you want to take the memory size into account for evictions.
        Hide
        Hoss Man added a comment -

        as far as FieldCache... whatever goes

        Probably safe to white list that usage right? It's use is only if the caller explicitly asked for the estimated size of the cache entries to be computed (and then cached in the entry)

        Perhaps...

        • whitelist that usage in 4x
        • mark those FieldCache methods as deprecated in 4x, with pointers telling callers how to go use RamUsageEstimator on the cache entries directly if they want that info.
        • remove those methods (and their whitelisted use of RamUsageEstimator) in 5.x

        ?

        Show
        Hoss Man added a comment - as far as FieldCache... whatever goes Probably safe to white list that usage right? It's use is only if the caller explicitly asked for the estimated size of the cache entries to be computed (and then cached in the entry) Perhaps... whitelist that usage in 4x mark those FieldCache methods as deprecated in 4x, with pointers telling callers how to go use RamUsageEstimator on the cache entries directly if they want that info. remove those methods (and their whitelisted use of RamUsageEstimator) in 5.x ?
        Hide
        Adrien Grand added a comment -

        Here is a new patch iterating on Robert's:

        • RamUsageEstimator, FieldCache.CacheEntry, CachingWrapperFilter and MemoryIndex (lucene/memory) are excluded from the forbidden checks on RamUsageEstimator
        • CachedOrdinalsReader (lucene/facets) and the suggesters (lucene/suggest) have been fixed to use less costly memory estimations.

        I think it would be nice to have memory usage estimations on filters in order to be able to remove CachingWrapperFilter from the exclusions but since this would be a large change, I'd rather do it as a separate issue.

        Show
        Adrien Grand added a comment - Here is a new patch iterating on Robert's: RamUsageEstimator, FieldCache.CacheEntry, CachingWrapperFilter and MemoryIndex (lucene/memory) are excluded from the forbidden checks on RamUsageEstimator CachedOrdinalsReader (lucene/facets) and the suggesters (lucene/suggest) have been fixed to use less costly memory estimations. I think it would be nice to have memory usage estimations on filters in order to be able to remove CachingWrapperFilter from the exclusions but since this would be a large change, I'd rather do it as a separate issue.
        Hide
        Robert Muir added a comment -

        +1, looks good.

        Show
        Robert Muir added a comment - +1, looks good.
        Hide
        Simon Willnauer added a comment -

        Thanks so much adrien! +1 to commit

        Show
        Simon Willnauer added a comment - Thanks so much adrien! +1 to commit
        Hide
        ASF subversion and git services added a comment -

        Commit 1571384 from Adrien Grand in branch 'dev/trunk'
        [ https://svn.apache.org/r1571384 ]

        LUCENE-5463: RUE.(human)sizeOf(Object) is now a forbidden API.

        Show
        ASF subversion and git services added a comment - Commit 1571384 from Adrien Grand in branch 'dev/trunk' [ https://svn.apache.org/r1571384 ] LUCENE-5463 : RUE.(human)sizeOf(Object) is now a forbidden API.
        Hide
        ASF subversion and git services added a comment -

        Commit 1571386 from Adrien Grand in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1571386 ]

        LUCENE-5463: RUE.(human)sizeOf(Object) is now a forbidden API.

        Show
        ASF subversion and git services added a comment - Commit 1571386 from Adrien Grand in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1571386 ] LUCENE-5463 : RUE.(human)sizeOf(Object) is now a forbidden API.
        Hide
        Uwe Schindler added a comment -

        There is a problem with this commit: You renamed "-check-forbidden-base" to "-check-forbidden-all", but missed to also rename the "overwrite" target in solr's common-build. The one there should also be renamed, otherwise its never executed!

        By this commit we lost the common-io checks in Solr.

        Also can we add a more verbose "defaultMessage" to rue.txt. This is too short and is not a real "error-like message". Something like: "This method is slow at runtime."

        Show
        Uwe Schindler added a comment - There is a problem with this commit: You renamed "-check-forbidden-base" to "-check-forbidden-all", but missed to also rename the "overwrite" target in solr's common-build. The one there should also be renamed, otherwise its never executed! By this commit we lost the common-io checks in Solr. Also can we add a more verbose "defaultMessage" to rue.txt. This is too short and is not a real "error-like message". Something like: "This method is slow at runtime."
        Hide
        Uwe Schindler added a comment -

        We should also change the Maven build to reflect the new checks.

        Show
        Uwe Schindler added a comment - We should also change the Maven build to reflect the new checks.
        Hide
        Adrien Grand added a comment -

        Thanks for the review Uwe, I'll fix.

        Show
        Adrien Grand added a comment - Thanks for the review Uwe, I'll fix.
        Hide
        Uwe Schindler added a comment -

        As you see in Solr this one is no longer executed:

        -check-forbidden-all:
        [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7
        [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7
        [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr2\lucene\tools\forbiddenApis\base.txt
        [forbidden-apis] Loading classes to check...
        [forbidden-apis] Scanning for API signatures and dependencies...
        [forbidden-apis] Scanned 2065 (and 1353 related) class file(s) for forbidden API invocations (in 1.59s), 0 error(s).
        
        -check-forbidden-tests:
        [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr2\lucene\tools\forbiddenApis\tests.txt
        [forbidden-apis] Loading classes to check...
        [forbidden-apis] Scanning for API signatures and dependencies...
        [forbidden-apis] Scanned 627 (and 890 related) class file(s) for forbidden API invocations (in 0.46s), 0 error(s).
        
        -check-forbidden-sysout:
        
        -check-forbidden-rue:
        [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr2\lucene\tools\forbiddenApis\rue.txt
        [forbidden-apis] Loading classes to check...
        [forbidden-apis] Scanning for API signatures and dependencies...
        [forbidden-apis] Scanned 1438 (and 1043 related) class file(s) for forbidden API invocations (in 0.55s), 0 error(s).
        
        -check-forbidden-sources:
        

        vs before:

        -check-forbidden-base:
        [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7
        [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7
        [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1
        [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\tools\forbiddenApis\base.txt
        [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\tools\forbiddenApis\servlet-api
        .txt
        [forbidden-apis] Loading classes to check...
        [forbidden-apis] Scanning for API signatures and dependencies...
        [forbidden-apis] Scanned 2063 (and 1356 related) class file(s) for forbidden API invocations (in 1.33s), 0 error(s).
        
        -check-forbidden-tests:
        [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\tools\forbiddenApis\tests.txt
        [forbidden-apis] Loading classes to check...
        [forbidden-apis] Scanning for API signatures and dependencies...
        [forbidden-apis] Scanned 625 (and 889 related) class file(s) for forbidden API invocations (in 0.47s), 0 error(s).
        
        -check-forbidden-sysout:
        
        Show
        Uwe Schindler added a comment - As you see in Solr this one is no longer executed: -check-forbidden-all: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7 [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr2\lucene\tools\forbiddenApis\base.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Scanned 2065 (and 1353 related) class file(s) for forbidden API invocations (in 1.59s), 0 error(s). -check-forbidden-tests: [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr2\lucene\tools\forbiddenApis\tests.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Scanned 627 (and 890 related) class file(s) for forbidden API invocations (in 0.46s), 0 error(s). -check-forbidden-sysout: -check-forbidden-rue: [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr2\lucene\tools\forbiddenApis\rue.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Scanned 1438 (and 1043 related) class file(s) for forbidden API invocations (in 0.55s), 0 error(s). -check-forbidden-sources: vs before: -check-forbidden-base: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7 [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1 [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\tools\forbiddenApis\base.txt [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\tools\forbiddenApis\servlet-api .txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Scanned 2063 (and 1356 related) class file(s) for forbidden API invocations (in 1.33s), 0 error(s). -check-forbidden-tests: [forbidden-apis] Reading API signatures: C:\Users\Uwe Schindler\Projects\lucene\trunk-lusolr1\lucene\tools\forbiddenApis\tests.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Scanned 625 (and 889 related) class file(s) for forbidden API invocations (in 0.47s), 0 error(s). -check-forbidden-sysout:
        Hide
        Uwe Schindler added a comment - - edited

        In my opinion, the target should be named "-check-forbidden-core" instead of "-check-forbidden-sources". This would be more in line with "compile-core" targets and so on. We generally speak of "core" and "test" in our build files.

        Show
        Uwe Schindler added a comment - - edited In my opinion, the target should be named "-check-forbidden-core" instead of "-check-forbidden-sources". This would be more in line with "compile-core" targets and so on. We generally speak of "core" and "test" in our build files.
        Hide
        Uwe Schindler added a comment - - edited

        There is an additional bug in the commit:
        The static overload for String size is just wrong, see the recent failure:

        REGRESSION:  org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads
        
        Error Message:
        expected:<48> but was:<56>
        
        Stack Trace:
        java.lang.AssertionError: expected:<48> but was:<56>
        	at __randomizedtesting.SeedInfo.seed([E123F914DF5BE037:BA7853CB2A89A039]:0)
        	at org.junit.Assert.fail(Assert.java:93)
        	at org.junit.Assert.failNotEquals(Assert.java:647)
        	at org.junit.Assert.assertEquals(Assert.java:128)
        	at org.junit.Assert.assertEquals(Assert.java:472)
        	at org.junit.Assert.assertEquals(Assert.java:456)
        	at org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads(TestRamUsageEstimator.java:91)
        

        The code uses an internal assumption on how a string is built internally. This assumption may not be correct for all JVMs. There is nothing in the JDK spec that specifies how a String should look like internally. Especially if it is a substring of another string: in that case the array is larger than string.length(). So the code is just wrong (in addition to this failure).

        The static overload is just incorrect then, so please remove it or make it use correct sizes, e.g. when the measured string is a substring of another one. Or if the JDK uses another internal String representation. The latter can be checked out before by inspecting string internals on the RUE startup.

        Show
        Uwe Schindler added a comment - - edited There is an additional bug in the commit: The static overload for String size is just wrong, see the recent failure: REGRESSION: org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads Error Message: expected:<48> but was:<56> Stack Trace: java.lang.AssertionError: expected:<48> but was:<56> at __randomizedtesting.SeedInfo.seed([E123F914DF5BE037:BA7853CB2A89A039]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.util.TestRamUsageEstimator.testStaticOverloads(TestRamUsageEstimator.java:91) The code uses an internal assumption on how a string is built internally. This assumption may not be correct for all JVMs. There is nothing in the JDK spec that specifies how a String should look like internally. Especially if it is a substring of another string: in that case the array is larger than string.length(). So the code is just wrong (in addition to this failure). The static overload is just incorrect then, so please remove it or make it use correct sizes, e.g. when the measured string is a substring of another one. Or if the JDK uses another internal String representation. The latter can be checked out before by inspecting string internals on the RUE startup.
        Hide
        Adrien Grand added a comment -

        Uwe Schindler I tried to fix the issues that you raised, let me know if these fixes are not good. I have very little experience with our Maven build so the way I added the rue.txt APIs to the set of forbidden APIs may not be the right one.

        Show
        Adrien Grand added a comment - Uwe Schindler I tried to fix the issues that you raised, let me know if these fixes are not good. I have very little experience with our Maven build so the way I added the rue.txt APIs to the set of forbidden APIs may not be the right one.
        Hide
        Uwe Schindler added a comment -

        Thanks for a first quick fix... I will merge your patch into my current work. The Maven fixes were just more a hint for Use account "steve_rowe" instead, I have not much more insight on the maven build like you!

        Just removing the test is a bad idea -> RUE#sizeOf(String) has more problems! I would prefer to first revert the commit and let's start with more close review!

        Show
        Uwe Schindler added a comment - Thanks for a first quick fix... I will merge your patch into my current work. The Maven fixes were just more a hint for Use account "steve_rowe" instead , I have not much more insight on the maven build like you! Just removing the test is a bad idea -> RUE#sizeOf(String) has more problems! I would prefer to first revert the commit and let's start with more close review!
        Hide
        Adrien Grand added a comment -

        just removing the test

        My bad, the patch was also supposed to remove the impl. See updated patch.

        Show
        Adrien Grand added a comment - just removing the test My bad, the patch was also supposed to remove the impl. See updated patch.
        Hide
        Uwe Schindler added a comment -

        For the changed default message:

        @defaultMessage This method is useful for testing but is slow at runtime
        

        You message was applied to both signatures, but the message did not fit for the second signature. If you want a separate message per signature, you can use:

        Class#method(params) @ Any method specific message
        

        In that case, the default message is ignored.

        Show
        Uwe Schindler added a comment - For the changed default message: @defaultMessage This method is useful for testing but is slow at runtime You message was applied to both signatures, but the message did not fit for the second signature. If you want a separate message per signature, you can use: Class#method(params) @ Any method specific message In that case, the default message is ignored.
        Hide
        Adrien Grand added a comment -

        I would prefer to first revert the commit and let's start with more close review!

        Whatever works for you works for me as well! I'll revert and upload a merged patch.

        Show
        Adrien Grand added a comment - I would prefer to first revert the commit and let's start with more close review! Whatever works for you works for me as well! I'll revert and upload a merged patch.
        Hide
        Uwe Schindler added a comment -

        My bad, the patch was also supposed to remove the impl. See updated patch.

        Ok. Thanks. See also my signature file comment, otherwise looks fine - no new patch needed. I have no idea if maven now works correct. Mabye Steve takes a look.

        Show
        Uwe Schindler added a comment - My bad, the patch was also supposed to remove the impl. See updated patch. Ok. Thanks. See also my signature file comment, otherwise looks fine - no new patch needed. I have no idea if maven now works correct. Mabye Steve takes a look.
        Hide
        Uwe Schindler added a comment -

        If you remove the incorrect String size method, I am fine! So no need to revert.

        Show
        Uwe Schindler added a comment - If you remove the incorrect String size method, I am fine! So no need to revert.
        Hide
        Adrien Grand added a comment -

        no new patch needed

        Just to be sure, are you saying there is no need to revert and I can just commit this second patch?

        Show
        Adrien Grand added a comment - no new patch needed Just to be sure, are you saying there is no need to revert and I can just commit this second patch?
        Hide
        Adrien Grand added a comment -

        OK, I got it, thanks!

        Show
        Adrien Grand added a comment - OK, I got it, thanks!
        Hide
        Uwe Schindler added a comment -

        Yes. Sorry for consufeness.

        My problem was the String size method which was not correct:

        • In Java 6, substrings share the same array like the original. It just allocates a new String object with a different offset and size, but the same underlying array. This may cause problems like we have seen in the test
        • In Java 7+, substrings are copied, so this is no longer an issue. But we still cannot be sure about memory requirements, because Strings may have a different internal layout.
        Show
        Uwe Schindler added a comment - Yes. Sorry for consufeness. My problem was the String size method which was not correct: In Java 6, substrings share the same array like the original. It just allocates a new String object with a different offset and size, but the same underlying array. This may cause problems like we have seen in the test In Java 7+, substrings are copied, so this is no longer an issue. But we still cannot be sure about memory requirements, because Strings may have a different internal layout.
        Hide
        ASF subversion and git services added a comment -

        Commit 1571493 from Adrien Grand in branch 'dev/trunk'
        [ https://svn.apache.org/r1571493 ]

        LUCENE-5463: Unbreak forbidden APIs for Solr, remove broken RUE.sizeOf(String) and add new forbidden APIs to the Maven build.

        Show
        ASF subversion and git services added a comment - Commit 1571493 from Adrien Grand in branch 'dev/trunk' [ https://svn.apache.org/r1571493 ] LUCENE-5463 : Unbreak forbidden APIs for Solr, remove broken RUE.sizeOf(String) and add new forbidden APIs to the Maven build.
        Hide
        ASF subversion and git services added a comment -

        Commit 1571494 from Adrien Grand in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1571494 ]

        LUCENE-5463: Unbreak forbidden APIs for Solr, remove broken RUE.sizeOf(String) and add new forbidden APIs to the Maven build.

        Show
        ASF subversion and git services added a comment - Commit 1571494 from Adrien Grand in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1571494 ] LUCENE-5463 : Unbreak forbidden APIs for Solr, remove broken RUE.sizeOf(String) and add new forbidden APIs to the Maven build.
        Hide
        Uwe Schindler added a comment -

        Thanks Adrien. After looking one more time on the Solr task, I think this one should be "-check-forbidden-all", because it applies to core and tests.

        I will fix this in a moment, sorry.

        Show
        Uwe Schindler added a comment - Thanks Adrien. After looking one more time on the Solr task, I think this one should be "-check-forbidden-all", because it applies to core and tests. I will fix this in a moment, sorry.
        Hide
        ASF subversion and git services added a comment -

        Commit 1571495 from Uwe Schindler in branch 'dev/trunk'
        [ https://svn.apache.org/r1571495 ]

        LUCENE-5463: Correct Solr forbidden checks

        Show
        ASF subversion and git services added a comment - Commit 1571495 from Uwe Schindler in branch 'dev/trunk' [ https://svn.apache.org/r1571495 ] LUCENE-5463 : Correct Solr forbidden checks
        Hide
        ASF subversion and git services added a comment -

        Commit 1571496 from Uwe Schindler in branch 'dev/branches/branch_4x'
        [ https://svn.apache.org/r1571496 ]

        Merged revision(s) 1571495 from lucene/dev/trunk:
        LUCENE-5463: Correct Solr forbidden checks

        Show
        ASF subversion and git services added a comment - Commit 1571496 from Uwe Schindler in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1571496 ] Merged revision(s) 1571495 from lucene/dev/trunk: LUCENE-5463 : Correct Solr forbidden checks
        Hide
        Adrien Grand added a comment -

        Marking as resolved... Thanks Uwe for your scrutiny!

        Show
        Adrien Grand added a comment - Marking as resolved... Thanks Uwe for your scrutiny!
        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:
            Adrien Grand
            Reporter:
            Adrien Grand
          • Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development