Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-10588

SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection failure caused by concurrent core reload.

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 6.6, 7.0
    • Component/s: None
    • Security Level: Public (Default Security Level. Issues are Public)
    • Labels:
      None

      Description

      https://builds.apache.org/job/Lucene-Solr-Tests-master/1788/testReport/junit/junit.framework/TestSuite/org_apache_solr_cloud_SolrCloudExampleTest/

      this NPE, even it might be quite reasonable itself, breaks core reload, and applying config param. I'm not sure, how it 's related causes to these constant failures.

      1. consoleFull.html.zip
        217 kB
        Mikhail Khludnev
      2. SOLR-10588.patch
        3 kB
        Mikhail Khludnev
      3. SOLR-10588.patch
        2 kB
        Mikhail Khludnev

        Issue Links

          Activity

          Hide
          mkhludnev Mikhail Khludnev added a comment - - edited
             [junit4]   2> org.apache.solr.common.SolrException: Unable to reload core [gettingstarted_shard1_replica2]
             [junit4]   2> 	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1197)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)
             [junit4]   2> 	at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
             [junit4]   2> 	at java.lang.Thread.run(Thread.java:745)
             [junit4]   2> Caused by: java.lang.NullPointerException
             [junit4]   2> 	at org.apache.solr.metrics.SolrMetricManager.loadShardReporters(SolrMetricManager.java:1032)
             [junit4]   2> 	at org.apache.solr.metrics.SolrCoreMetricManager.loadReporters(SolrCoreMetricManager.java:89)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.<init>(SolrCore.java:896)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.reload(SolrCore.java:647)
             [junit4]   2> 	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184)
             [junit4]   2> 	... 3 more
             [junit4]   2> 1614982 INFO  (Solr
          
          

          and this is another one

             [junit4]   2> 1614982 ERROR (SolrConfigHandler-refreshconf) [n:127.0.0.1:49705_ c:gettingstarted s:shard1 r:core_node4 x:gettingstarted_shard1_replica2] o.a.s.h.SolrConfigHandler Unable to refresh conf 
             [junit4]   2> org.apache.solr.common.SolrException: Unable to reload core [gettingstarted_shard1_replica2]
             [junit4]   2> 	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1197)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)
             [junit4]   2> 	at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
             [junit4]   2> 	at java.lang.Thread.run(Thread.java:745)
             [junit4]   2> Caused by: java.lang.NullPointerException
             [junit4]   2> 	at org.apache.solr.metrics.SolrMetricManager.loadShardReporters(SolrMetricManager.java:1032)
             [junit4]   2> 	at org.apache.solr.metrics.SolrCoreMetricManager.loadReporters(SolrCoreMetricManager.java:89)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.<init>(SolrCore.java:896)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.reload(SolrCore.java:647)
             [junit4]   2> 	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184)
             [junit4]   2> 	... 3 more
             [junit4]   2> 1614982 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.core.gettingstarted.shard1.replica1, tag=1820687374
             [junit4]   2> 1614982 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.collection.gettingstarted.shard1.leader, tag=1820687374
             [junit4]   2> 1614983 ERROR (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Unable to refresh conf 
             [junit4]   2> org.apache.solr.common.SolrException: Unable to reload core [gettingstarted_shard1_replica1]
             [junit4]   2> 	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1197)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)
             [junit4]   2> 	at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
             [junit4]   2> 	at java.lang.Thread.run(Thread.java:745)
             [junit4]   2> Caused by: org.apache.solr.common.SolrException
             [junit4]   2> 	at org.apache.solr.core.SolrCore.<init>(SolrCore.java:1001)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.reload(SolrCore.java:647)
             [junit4]   2> 	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184)
             [junit4]   2> 	... 3 more
             [junit4]   2> Caused by: java.lang.NullPointerException
             [junit4]   2> 	at org.apache.solr.core.SolrCore.initRestManager(SolrCore.java:2779)
             [junit4]   2> 	at org.apache.solr.core.SolrCore.<init>(SolrCore.java:976)
             [junit4]   2> 	... 5 more
             [junit4]   2> 1615009 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:56894_ c:gettingstarted s:shard2 r:core_node1 x:gettingstarted_shard2_replica2] o.a.s.c.CoreContainer Reloading SolrCore 'gettingstarted_shard2_replica2' using configuration from collection gettingstarted
          
          Show
          mkhludnev Mikhail Khludnev added a comment - - edited [junit4] 2> org.apache.solr.common.SolrException: Unable to reload core [gettingstarted_shard1_replica2] [junit4] 2> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1197) [junit4] 2> at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949) [junit4] 2> at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225) [junit4] 2> at java.lang. Thread .run( Thread .java:745) [junit4] 2> Caused by: java.lang.NullPointerException [junit4] 2> at org.apache.solr.metrics.SolrMetricManager.loadShardReporters(SolrMetricManager.java:1032) [junit4] 2> at org.apache.solr.metrics.SolrCoreMetricManager.loadReporters(SolrCoreMetricManager.java:89) [junit4] 2> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:896) [junit4] 2> at org.apache.solr.core.SolrCore.reload(SolrCore.java:647) [junit4] 2> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184) [junit4] 2> ... 3 more [junit4] 2> 1614982 INFO (Solr and this is another one [junit4] 2> 1614982 ERROR (SolrConfigHandler-refreshconf) [n:127.0.0.1:49705_ c:gettingstarted s:shard1 r:core_node4 x:gettingstarted_shard1_replica2] o.a.s.h.SolrConfigHandler Unable to refresh conf [junit4] 2> org.apache.solr.common.SolrException: Unable to reload core [gettingstarted_shard1_replica2] [junit4] 2> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1197) [junit4] 2> at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949) [junit4] 2> at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225) [junit4] 2> at java.lang. Thread .run( Thread .java:745) [junit4] 2> Caused by: java.lang.NullPointerException [junit4] 2> at org.apache.solr.metrics.SolrMetricManager.loadShardReporters(SolrMetricManager.java:1032) [junit4] 2> at org.apache.solr.metrics.SolrCoreMetricManager.loadReporters(SolrCoreMetricManager.java:89) [junit4] 2> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:896) [junit4] 2> at org.apache.solr.core.SolrCore.reload(SolrCore.java:647) [junit4] 2> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184) [junit4] 2> ... 3 more [junit4] 2> 1614982 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.core.gettingstarted.shard1.replica1, tag=1820687374 [junit4] 2> 1614982 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.m.SolrMetricManager Closing metric reporters for registry=solr.collection.gettingstarted.shard1.leader, tag=1820687374 [junit4] 2> 1614983 ERROR (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Unable to refresh conf [junit4] 2> org.apache.solr.common.SolrException: Unable to reload core [gettingstarted_shard1_replica1] [junit4] 2> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1197) [junit4] 2> at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949) [junit4] 2> at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225) [junit4] 2> at java.lang. Thread .run( Thread .java:745) [junit4] 2> Caused by: org.apache.solr.common.SolrException [junit4] 2> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:1001) [junit4] 2> at org.apache.solr.core.SolrCore.reload(SolrCore.java:647) [junit4] 2> at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184) [junit4] 2> ... 3 more [junit4] 2> Caused by: java.lang.NullPointerException [junit4] 2> at org.apache.solr.core.SolrCore.initRestManager(SolrCore.java:2779) [junit4] 2> at org.apache.solr.core.SolrCore.<init>(SolrCore.java:976) [junit4] 2> ... 5 more [junit4] 2> 1615009 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:56894_ c:gettingstarted s:shard2 r:core_node1 x:gettingstarted_shard2_replica2] o.a.s.c.CoreContainer Reloading SolrCore 'gettingstarted_shard2_replica2' using configuration from collection gettingstarted
          Hide
          mkhludnev Mikhail Khludnev added a comment - - edited

          what's really questionable is double core reload.

             [junit4]   2> 1613694 INFO  (TEST-SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection-seed#[D64D4AF1644074DE]) [    ] o.a.s.c.SolrCloudExampleTest Sending set-property 'updateHandler.autoSoftCommit.maxTime'=3000 to SolrCLI.ConfigTool.
             [junit4]   1> 
             [junit4]   1> POSTing request to Config API: http://127.0.0.1:50975//gettingstarted/config
             [junit4]   1> {"set-property":{"updateHandler.autoSoftCommit.maxTime":"3000"}}
             [junit4]   2> 1613699 INFO  (qtp1233100485-18318) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Executed config commands successfully and persisted to ZK [{"set-property":{"updateHandler.autoSoftCommit.maxTime":"3000"}}]
             [junit4]   2> 1613699 INFO  (qtp1233100485-18318) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Waiting up to 30 secs for 4 replicas to set the property overlay to be of version 0 for collection gettingstarted
             [junit4]   2> 1613700 INFO  (Thread-5447) [n:127.0.0.1:56894_    ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard2_replica2
             [junit4]   2> 1613701 INFO  (Thread-5447) [n:127.0.0.1:56894_    ] o.a.s.c.SolrCore core reload gettingstarted_shard2_replica2
             [junit4]   2> 1613702 INFO  (Thread-5449) [n:127.0.0.1:57043_    ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard1_replica1
             [junit4]   2> 1613702 INFO  (Thread-5450) [n:127.0.0.1:49705_    ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard1_replica2
             [junit4]   2> 1613703 INFO  (Thread-5449) [n:127.0.0.1:57043_    ] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica1
             [junit4]   2> 1613704 INFO  (Thread-5450) [n:127.0.0.1:49705_    ] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica2
             [junit4]   2> 1613706 INFO  (Thread-5448) [n:127.0.0.1:32921_    ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard2_replica1
             [junit4]   2> 1613711 INFO  (Thread-5448) [n:127.0.0.1:32921_    ] o.a.s.c.SolrCore core reload gettingstarted_shard2_replica1
          

          Config change is posted to Zk and it seems it triggers core reload by zk listener registered at SolrCore.registerConfListener(). I guess this because of Thread-54* names.
          but then it happens again by SolrConfigHandler.Command.handleGET()

             [junit4]   2> 1613952 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:49705_ c:gettingstarted s:shard1 r:core_node4 x:gettingstarted_shard1_replica2] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica2
             [junit4]   2> 1613937 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard1_replica1
             [junit4]   2> 1613955 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica1
             [junit4]   2> 1613956 INFO  (SolrConfigHandler-refreshconf) [n:127.0.0.1:32921_ c:gettingstarted s:shard2 r:core_node2 x:gettingstarted_shard2_replica1] o.a.s.c.SolrCore core reload gettingstarted_shard2_replica1
          

          then script triggers deletes

             [junit4]   1> Deleting collection 'gettingstarted' using command:
             [junit4]   1> http://127.0.0.1:50975/admin/collections?action=DELETE&name=gettingstarted
          

          and deleting is actually on going while SolrConfigHandler-refreshconf reloads config, and breaks with NPE and this might cause a leak.
          What we also can see from leakage dump, that leaked objects are created with core create command, but not made during reload.
          UPD, there is one leak from reloading threads:

          org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor
          	at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42)
          	at org.apache.solr.core.SolrCore.<init>(SolrCore.java:883)
          	at org.apache.solr.core.SolrCore.reload(SolrCore.java:647)
          	at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184)
          	at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949)
          	at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225)
          	at java.lang.Thread.run(Thread.java:745)
          

          The question is: should it really reload core twice? Can't SolrConfigHandler.Command.handleGET be synchronous? or pollable with async? cc Noble Paul

          Show
          mkhludnev Mikhail Khludnev added a comment - - edited what's really questionable is double core reload. [junit4] 2> 1613694 INFO (TEST-SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection-seed#[D64D4AF1644074DE]) [ ] o.a.s.c.SolrCloudExampleTest Sending set-property 'updateHandler.autoSoftCommit.maxTime'=3000 to SolrCLI.ConfigTool. [junit4] 1> [junit4] 1> POSTing request to Config API: http: //127.0.0.1:50975//gettingstarted/config [junit4] 1> { "set-property" :{ "updateHandler.autoSoftCommit.maxTime" : "3000" }} [junit4] 2> 1613699 INFO (qtp1233100485-18318) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Executed config commands successfully and persisted to ZK [{ "set-property" :{ "updateHandler.autoSoftCommit.maxTime" : "3000" }}] [junit4] 2> 1613699 INFO (qtp1233100485-18318) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.h.SolrConfigHandler Waiting up to 30 secs for 4 replicas to set the property overlay to be of version 0 for collection gettingstarted [junit4] 2> 1613700 INFO ( Thread -5447) [n:127.0.0.1:56894_ ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard2_replica2 [junit4] 2> 1613701 INFO ( Thread -5447) [n:127.0.0.1:56894_ ] o.a.s.c.SolrCore core reload gettingstarted_shard2_replica2 [junit4] 2> 1613702 INFO ( Thread -5449) [n:127.0.0.1:57043_ ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard1_replica1 [junit4] 2> 1613702 INFO ( Thread -5450) [n:127.0.0.1:49705_ ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard1_replica2 [junit4] 2> 1613703 INFO ( Thread -5449) [n:127.0.0.1:57043_ ] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica1 [junit4] 2> 1613704 INFO ( Thread -5450) [n:127.0.0.1:49705_ ] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica2 [junit4] 2> 1613706 INFO ( Thread -5448) [n:127.0.0.1:32921_ ] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard2_replica1 [junit4] 2> 1613711 INFO ( Thread -5448) [n:127.0.0.1:32921_ ] o.a.s.c.SolrCore core reload gettingstarted_shard2_replica1 Config change is posted to Zk and it seems it triggers core reload by zk listener registered at SolrCore.registerConfListener() . I guess this because of Thread-54* names. but then it happens again by SolrConfigHandler.Command.handleGET() [junit4] 2> 1613952 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:49705_ c:gettingstarted s:shard1 r:core_node4 x:gettingstarted_shard1_replica2] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica2 [junit4] 2> 1613937 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.c.SolrCore config update listener called for core gettingstarted_shard1_replica1 [junit4] 2> 1613955 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:57043_ c:gettingstarted s:shard1 r:core_node3 x:gettingstarted_shard1_replica1] o.a.s.c.SolrCore core reload gettingstarted_shard1_replica1 [junit4] 2> 1613956 INFO (SolrConfigHandler-refreshconf) [n:127.0.0.1:32921_ c:gettingstarted s:shard2 r:core_node2 x:gettingstarted_shard2_replica1] o.a.s.c.SolrCore core reload gettingstarted_shard2_replica1 then script triggers deletes [junit4] 1> Deleting collection 'gettingstarted' using command: [junit4] 1> http: //127.0.0.1:50975/admin/collections?action=DELETE&name=gettingstarted and deleting is actually on going while SolrConfigHandler-refreshconf reloads config, and breaks with NPE and this might cause a leak. What we also can see from leakage dump, that leaked objects are created with core create command, but not made during reload. UPD , there is one leak from reloading threads: org.apache.solr.common.util.ObjectReleaseTracker$ObjectTrackerException: org.apache.solr.common.util.ExecutorUtil$MDCAwareThreadPoolExecutor at org.apache.solr.common.util.ObjectReleaseTracker.track(ObjectReleaseTracker.java:42) at org.apache.solr.core.SolrCore.<init>(SolrCore.java:883) at org.apache.solr.core.SolrCore.reload(SolrCore.java:647) at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:1184) at org.apache.solr.core.SolrCore.lambda$getConfListener$18(SolrCore.java:2949) at org.apache.solr.handler.SolrConfigHandler$Command.lambda$handleGET$0(SolrConfigHandler.java:225) at java.lang. Thread .run( Thread .java:745) The question is: should it really reload core twice? Can't SolrConfigHandler.Command.handleGET be synchronous? or pollable with async? cc Noble Paul
          Hide
          mkhludnev Mikhail Khludnev added a comment -

          The worst thing is that I can't reproduce it locally with 🐜 beast.

          Show
          mkhludnev Mikhail Khludnev added a comment - The worst thing is that I can't reproduce it locally with 🐜 beast.
          Hide
          mkhludnev Mikhail Khludnev added a comment -

          SOLR-10588.patch excludes concurrent core reload at SolrCore.getConfListener()'s ƛ by the way they are already excluded at SolrConfigHandler.Command.handleGET()'s ƛ.. but wait..the later already calls the former. Well.. now it works only because of holy reentrancy.

          This might probably miss some overlapping config updates. And (if it works at all), SolrConfigHandler.reloadLock should probably be elevated to somewhere in SolrCore, or even to CoreContainer.

          $1bn question

          Who can confirm that this fix is effective?

          Show
          mkhludnev Mikhail Khludnev added a comment - SOLR-10588.patch excludes concurrent core reload at SolrCore.getConfListener()'s ƛ by the way they are already excluded at SolrConfigHandler.Command.handleGET()'s ƛ .. but wait..the later already calls the former. Well.. now it works only because of holy reentrancy. This might probably miss some overlapping config updates. And (if it works at all), SolrConfigHandler.reloadLock should probably be elevated to somewhere in SolrCore , or even to CoreContainer . $1bn question Who can confirm that this fix is effective?
          Hide
          erickerickson Erick Erickson added a comment -

          At least it's in the same ballpark. Shalin Shekhar Mangar's comments may shed some light on this.

          Mikhail: I can get SolrCloudExapmleTest to fail on my system, I'll give this a spin momentarily.

          Erick

          Show
          erickerickson Erick Erickson added a comment - At least it's in the same ballpark. Shalin Shekhar Mangar 's comments may shed some light on this. Mikhail: I can get SolrCloudExapmleTest to fail on my system, I'll give this a spin momentarily. Erick
          Hide
          erickerickson Erick Erickson added a comment -

          OK, 2,000 runs and
          > no NPEs
          > no test failures

          I was usually able to get 1-2% failure rate before this patch, so LGTM.

          And note that I did not run any tests except SolrCloudExampleTest.

          Show
          erickerickson Erick Erickson added a comment - OK, 2,000 runs and > no NPEs > no test failures I was usually able to get 1-2% failure rate before this patch, so LGTM. And note that I did not run any tests except SolrCloudExampleTest.
          Hide
          mkhludnev Mikhail Khludnev added a comment -

          Erick Erickson, thank you very much!
          Since it makes noise in CI, I can commit this today or tomorrow after it passes whole suite, and then come back to better design in SOLR-10594.
          How does it sound?

          Show
          mkhludnev Mikhail Khludnev added a comment - Erick Erickson , thank you very much! Since it makes noise in CI, I can commit this today or tomorrow after it passes whole suite, and then come back to better design in SOLR-10594 . How does it sound?
          Hide
          mkhludnev Mikhail Khludnev added a comment -

          I run solr/core tests. Got 36 failures from Payload/Similarity. I suppose it's going to be fixed soon. So, I'm ready to commit. Are there any concerns?

          Show
          mkhludnev Mikhail Khludnev added a comment - I run solr/core tests. Got 36 failures from Payload/Similarity. I suppose it's going to be fixed soon. So, I'm ready to commit. Are there any concerns?
          Hide
          mkhludnev Mikhail Khludnev added a comment -

          Tests passed. I'm ready to commit the fix.

          Show
          mkhludnev Mikhail Khludnev added a comment - Tests passed. I'm ready to commit the fix.
          Hide
          ehatcher Erik Hatcher added a comment -

          Got 36 failures from Payload/Similarity

          Sorry Mikhail! My bad, sorry for the hassle that delayed you here.

          Show
          ehatcher Erik Hatcher added a comment - Got 36 failures from Payload/Similarity Sorry Mikhail! My bad, sorry for the hassle that delayed you here.
          Hide
          mkhludnev Mikhail Khludnev added a comment -

          No problem, Erik Hatcher. Any concerns about committing this fix?

          Show
          mkhludnev Mikhail Khludnev added a comment - No problem, Erik Hatcher . Any concerns about committing this fix?
          Hide
          ehatcher Erik Hatcher added a comment -

          Looks good, Mikhail Khludnev. Cosmetic, but since you asked and I looked at the patch here, I'd remove the space "progress" and the period in the info log.

          Show
          ehatcher Erik Hatcher added a comment - Looks good, Mikhail Khludnev . Cosmetic, but since you asked and I looked at the patch here, I'd remove the space "progress" and the period in the info log.
          Hide
          erickerickson Erick Erickson added a comment -

          bq: Since it makes noise in CI, I can commit this today or tomorrow after it passes whole suite,

          Suits me perfectly...

          Show
          erickerickson Erick Erickson added a comment - bq: Since it makes noise in CI, I can commit this today or tomorrow after it passes whole suite, Suits me perfectly...
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit cbd3b02cda1ce9d42cf78f7571bc96a8af4fe219 in lucene-solr's branch refs/heads/master from Mikhail Khludnev
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cbd3b02 ]

          SOLR-10588: Prevent redundant double core reload on config update.

          Show
          jira-bot ASF subversion and git services added a comment - Commit cbd3b02cda1ce9d42cf78f7571bc96a8af4fe219 in lucene-solr's branch refs/heads/master from Mikhail Khludnev [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=cbd3b02 ] SOLR-10588 : Prevent redundant double core reload on config update.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 4901daee85acd867bd120f3f77c41821ab2aa7fb in lucene-solr's branch refs/heads/branch_6x from Mikhail Khludnev
          [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4901dae ]

          SOLR-10588: Prevent redundant double core reload on config update.

          Show
          jira-bot ASF subversion and git services added a comment - Commit 4901daee85acd867bd120f3f77c41821ab2aa7fb in lucene-solr's branch refs/heads/branch_6x from Mikhail Khludnev [ https://git-wip-us.apache.org/repos/asf?p=lucene-solr.git;h=4901dae ] SOLR-10588 : Prevent redundant double core reload on config update.

            People

            • Assignee:
              Unassigned
              Reporter:
              mkhludnev Mikhail Khludnev
            • Votes:
              0 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development