Solr
  1. Solr
  2. SOLR-4373

In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1, 4.2
    • Fix Version/s: 4.2
    • Component/s: multicore
    • Labels:

      Description

      Having lib directives in the solrconfig.xml files of multiple cores can cause problems when using multi-threaded core initialization – which is the default starting with Solr 4.1.

      The problem manifests itself as init errors in the logs related to not being able to find classes located in plugin jars, even though earlier log messages indicated that those jars had been added to the classpath.

      One work around is to set coreLoadThreads="1" in your solr.xml file – forcing single threaded core initialization. For example...

      <?xml version="1.0" encoding="utf-8" ?>
      <solr coreLoadThreads="1">
        <cores adminPath="/admin/cores">
          <core name="core1" instanceDir="core1" />
          <core name="core2" instanceDir="core2" />
        </cores>
      </solr>
      

      (Similar problems may occur if multiple cores are initialized concurrently using the /admin/cores handler)

      1. multicore-bug.zip
        16 kB
        Alexandre Rafalovitch
      2. testscript.sh
        1 kB
        Rene Nederhand

        Issue Links

          Activity

          Hide
          Alexandre Rafalovitch added a comment -

          Full Solr setup with two cores showing the problem. Disable the second core in solr.xml to make the problem go away. Log files for both scenarios are included.

          Show
          Alexandre Rafalovitch added a comment - Full Solr setup with two cores showing the problem. Disable the second core in solr.xml to make the problem go away. Log files for both scenarios are included.
          Hide
          Hoss Man added a comment -

          Damn.....

          I can reproduce this problem in 4.1, but not with 4.0, leading me to suspect that it is probably caused by the changes in SOLR-4063 to initialize SolrCore's in parallel.

          adding coreLoadThreads="1" to the <solr/> element in solr.xml seems to be work around for this problem, (reinforcing my suspicion) but it may not be a complete work around since that should just make the order of operations deterministic – any impacts of later cores on earlier cores should still be evident, but even if i re-order the cores in your test case, i see no problem using coreLoadThreads="1".

          I attempted to create a more trivial example of this problem by having multiple cores refer to lib paths with different dir names containing different stopword files with the same name (my motivation being to create something that could be used in a junit test w/o needing to build special jars) and could not reproduce the problem ... which confuses me.

          my current best guess is that maybe the problem is caused by a combination of concurrent SolrCore/SolrResourceLoader init and the "reloadLuceneSPI()" hook in SolrResourceLoader ... i'm looking at NamedSPILoader.reload and thinking that doesn't look thread safe – but i'm not sure if it's expected to be?

          ...Hmm...

          I tried a quick experiment of modifying NamedSPILoader.reload to be synchronized, on the theory that the cause of this problem was interleaved requests to that method from multiple threads that where reading "this.services", processing it, and then writing a new "this.services" in a "last thread wins" fashion... but that didn't seem to solve the problem.

          The more i look at NamedSPILoader, the less i understand it and how it's used in the context of Solr ... because it's not clear to me how classes using NamedSPILoader, which are themselves loaded by the "webapp classloader" (ie: in the solr.war) ensure that the correct SPI Service is returned in the context of a child classloader in situations where there are multiple child classloaders (ie: SolrCores) that might have conflicting SPI classes. From what i can see, if classloaderA and classloaerB each load their own (possibly differnet) copy ICUFoldingFilterFactory, they're both going to collide in the LinkedHashMap that NamedSPILoader maintains ... right? Is this related to the current bug, or is this perhaps a diff bug?

          (or maybe i just understand SPI even less then i think .. which is not much)

          Show
          Hoss Man added a comment - Damn..... I can reproduce this problem in 4.1, but not with 4.0, leading me to suspect that it is probably caused by the changes in SOLR-4063 to initialize SolrCore's in parallel. adding coreLoadThreads="1" to the <solr/> element in solr.xml seems to be work around for this problem, (reinforcing my suspicion) but it may not be a complete work around since that should just make the order of operations deterministic – any impacts of later cores on earlier cores should still be evident, but even if i re-order the cores in your test case, i see no problem using coreLoadThreads="1" . I attempted to create a more trivial example of this problem by having multiple cores refer to lib paths with different dir names containing different stopword files with the same name (my motivation being to create something that could be used in a junit test w/o needing to build special jars) and could not reproduce the problem ... which confuses me. my current best guess is that maybe the problem is caused by a combination of concurrent SolrCore/SolrResourceLoader init and the "reloadLuceneSPI()" hook in SolrResourceLoader ... i'm looking at NamedSPILoader.reload and thinking that doesn't look thread safe – but i'm not sure if it's expected to be? ...Hmm... I tried a quick experiment of modifying NamedSPILoader.reload to be synchronized, on the theory that the cause of this problem was interleaved requests to that method from multiple threads that where reading "this.services", processing it, and then writing a new "this.services" in a "last thread wins" fashion... but that didn't seem to solve the problem. The more i look at NamedSPILoader, the less i understand it and how it's used in the context of Solr ... because it's not clear to me how classes using NamedSPILoader, which are themselves loaded by the "webapp classloader" (ie: in the solr.war) ensure that the correct SPI Service is returned in the context of a child classloader in situations where there are multiple child classloaders (ie: SolrCores) that might have conflicting SPI classes. From what i can see, if classloaderA and classloaerB each load their own (possibly differnet) copy ICUFoldingFilterFactory, they're both going to collide in the LinkedHashMap that NamedSPILoader maintains ... right? Is this related to the current bug, or is this perhaps a diff bug? (or maybe i just understand SPI even less then i think .. which is not much)
          Hide
          Alexandre Rafalovitch added a comment -

          I am unable to get the problem go away by using coreLoadThreads="1":
          <cores adminPath="/admin/cores" coreLoadThreads="1">

          Where do the cores store their libraries? Why should core2 see the core1's structure for the library at all? Do they get ClassLoaders mixed up somehow? Is there a way to catch the modifications to whatever that structure is and dump the stack trace at modification time? Just thinking aloud.

          Show
          Alexandre Rafalovitch added a comment - I am unable to get the problem go away by using coreLoadThreads="1": <cores adminPath="/admin/cores" coreLoadThreads="1"> Where do the cores store their libraries? Why should core2 see the core1's structure for the library at all? Do they get ClassLoaders mixed up somehow? Is there a way to catch the modifications to whatever that structure is and dump the stack trace at modification time? Just thinking aloud.
          Hide
          Hoss Man added a comment -

          Mark: i really don't have anything to offer on this issue beyond the comments i already posted ... based on my testing it really seems like this is caused by SOLR-4063, but that may be totally off base since aledandre couldn't make the problem go away using hte workarround i thought i found (ie: forcing single threaded core init)

          since i couldn't reproduce a similar collision between multicores with a simple stopwords file loaded from the classpath, it also seems likeley that this relates to SPI loading: but since i don't really understand at all how NamedSPILoader works in a multiclassloader application (and since my experiements in forcing synchronization on it didn't solve the problem for me) i'm at a dead in there as well

          Show
          Hoss Man added a comment - Mark: i really don't have anything to offer on this issue beyond the comments i already posted ... based on my testing it really seems like this is caused by SOLR-4063 , but that may be totally off base since aledandre couldn't make the problem go away using hte workarround i thought i found (ie: forcing single threaded core init) since i couldn't reproduce a similar collision between multicores with a simple stopwords file loaded from the classpath, it also seems likeley that this relates to SPI loading: but since i don't really understand at all how NamedSPILoader works in a multiclassloader application (and since my experiements in forcing synchronization on it didn't solve the problem for me) i'm at a dead in there as well
          Hide
          Mark Miller added a comment -

          Oh, I don't plan on looking into it. Just assigned it to so that it wasn't forgotten and you seemed to have some knowledge in this area. I don't really have a need for more than a single lib dir ever pretty much.

          Show
          Mark Miller added a comment - Oh, I don't plan on looking into it. Just assigned it to so that it wasn't forgotten and you seemed to have some knowledge in this area. I don't really have a need for more than a single lib dir ever pretty much.
          Hide
          Alexandre Rafalovitch added a comment -

          I have just rechecked and I still have the problem with coreLoadThreads=1 setting under Solr 4.1. Every time I start Solr a different subset of cores fails. I think reloading a core triggers this as well, though it is harder to check.

          I have the whole set of examples structured around getting this to work (each example is a separate core). Is there something I can do to help troubleshooting this? I haven't tried working with Solr source yet, but I am a Java developer and can dig around if there is some sort of information at where library references are stored.

          Show
          Alexandre Rafalovitch added a comment - I have just rechecked and I still have the problem with coreLoadThreads=1 setting under Solr 4.1. Every time I start Solr a different subset of cores fails. I think reloading a core triggers this as well, though it is harder to check. I have the whole set of examples structured around getting this to work (each example is a separate core). Is there something I can do to help troubleshooting this? I haven't tried working with Solr source yet, but I am a Java developer and can dig around if there is some sort of information at where library references are stored.
          Hide
          Uwe Schindler added a comment -

          Hoss: The concurrency issue in NamedSPILoader can indeed be solved by making the reload method synchonized. The services field is volatile, so readers will in any case see the correct value. The thread safety problem is inside this method.

          Show
          Uwe Schindler added a comment - Hoss: The concurrency issue in NamedSPILoader can indeed be solved by making the reload method synchonized. The services field is volatile, so readers will in any case see the correct value. The thread safety problem is inside this method.
          Hide
          Alexandre Rafalovitch added a comment -

          Isn't that for SPIs only? Does that cover TokenFactories, etc? I think the libraries actually use SolrResourceLoader#reloadLuceneSPI instead.

          I wonder if the problem is related to SolrResourceLoader#createClassLoader:

              if ( null == parent ) {
                parent = Thread.currentThread().getContextClassLoader();
              }
          

          How does this work with multiple threads?

          Show
          Alexandre Rafalovitch added a comment - Isn't that for SPIs only? Does that cover TokenFactories, etc? I think the libraries actually use SolrResourceLoader#reloadLuceneSPI instead. I wonder if the problem is related to SolrResourceLoader#createClassLoader: if ( null == parent ) { parent = Thread .currentThread().getContextClassLoader(); } How does this work with multiple threads?
          Hide
          Hoss Man added a comment -

          There appear to be a few things going on here...

          • LUCENE-4796: there is at least one confirmed thread safety issue here with NamedSPILoader which i've spun off into it's own Jira. combined with concurrent loading of SolrCore's this could definitely cause a problem. Note however that while working on this issue i previously experimented with "fixing" the synchronization problem in NamedSPILoader but it didn't seem to resolve this issue – i may have just botched my fix or testing, or there may be a secondary compounding issue.
          • Even if LUCENE-4796 is the root cause of this issue, that doens't explain why my previous suggested work around doens't work for alex, since forcing single threaded SolrCore initalization should make the synchroniztaion of that method moot.
          • Based on my IRC discussion with Uwe, it seems like my overall understanding of NamedSPILoader is correct. Which means, if i'm understanidng things correctly: now that lucene uses this class (and SPI loadin in general) at a low level, Solr fundementally won't be able to support individual SolrCores loading plugins with the same name, but different implementaions – ie: different versions of a plugin in different solrcores. I may be wrong about this, and it may not even remotely related to the problem at hand, but i wanted to point it out for the record since prior to using SPI in Lucene this is something that worked in Solr. (Honestly: it's not even clear to me in the new world order if it's safe for two different SolrClore's to load the same plugin in their individual class loaders – needs more careful testing ... we may need to start encouraging people to move away from leading plugins at the SolrCore level and instead load them using the sharedLib)
          Show
          Hoss Man added a comment - There appear to be a few things going on here... LUCENE-4796 : there is at least one confirmed thread safety issue here with NamedSPILoader which i've spun off into it's own Jira. combined with concurrent loading of SolrCore's this could definitely cause a problem. Note however that while working on this issue i previously experimented with "fixing" the synchronization problem in NamedSPILoader but it didn't seem to resolve this issue – i may have just botched my fix or testing, or there may be a secondary compounding issue. Even if LUCENE-4796 is the root cause of this issue, that doens't explain why my previous suggested work around doens't work for alex, since forcing single threaded SolrCore initalization should make the synchroniztaion of that method moot. Based on my IRC discussion with Uwe, it seems like my overall understanding of NamedSPILoader is correct. Which means, if i'm understanidng things correctly: now that lucene uses this class (and SPI loadin in general) at a low level, Solr fundementally won't be able to support individual SolrCores loading plugins with the same name, but different implementaions – ie: different versions of a plugin in different solrcores. I may be wrong about this, and it may not even remotely related to the problem at hand, but i wanted to point it out for the record since prior to using SPI in Lucene this is something that worked in Solr. (Honestly: it's not even clear to me in the new world order if it's safe for two different SolrClore's to load the same plugin in their individual class loaders – needs more careful testing ... we may need to start encouraging people to move away from leading plugins at the SolrCore level and instead load them using the sharedLib)
          Hide
          Hoss Man added a comment -

          Alex:

          I just noticed something in one of your earlier comments...

          I am unable to get the problem go away by using coreLoadThreads="1": <cores adminPath="/admin/cores" coreLoadThreads="1">

          ...the "coreLoadThreads" option should be on the <solr/> element, not the <cores/> element, can you please test that again?

          Other comments..

          Is there something I can do to help troubleshooting this? I haven't tried working with Solr source yet, but I am a Java developer and can dig around if there is some sort of information at where library references are stored.

          primarily we build up a ClassLoader per SolrCore in SOlrResourceLoader, each of which hangs off of the parent classloader for the webapp – but the use of SPI in lucene complicates things in ways i still don't fully understand.

          Isn't that for SPIs only? Does that cover TokenFactories

          Yes, many of the various factories in Solr are handled using SPI now (take a look at SolrResourceLoader.reloadLuceneSPI())

          Show
          Hoss Man added a comment - Alex: I just noticed something in one of your earlier comments... I am unable to get the problem go away by using coreLoadThreads="1": <cores adminPath="/admin/cores" coreLoadThreads="1"> ...the "coreLoadThreads" option should be on the <solr/> element, not the <cores/> element, can you please test that again? Other comments.. Is there something I can do to help troubleshooting this? I haven't tried working with Solr source yet, but I am a Java developer and can dig around if there is some sort of information at where library references are stored. primarily we build up a ClassLoader per SolrCore in SOlrResourceLoader, each of which hangs off of the parent classloader for the webapp – but the use of SPI in lucene complicates things in ways i still don't fully understand. Isn't that for SPIs only? Does that cover TokenFactories Yes, many of the various factories in Solr are handled using SPI now (take a look at SolrResourceLoader.reloadLuceneSPI())
          Hide
          Alexandre Rafalovitch added a comment -

          Ok, adding the flag on solr element seems to have fixed the problem. My bad. Does it mean we know where the problem is?

          However, on the other point, I don't see NamedSPILoader being called from SolrResourceLoader.reloadLuceneSPI(). Rather, I see AnalysisSPILoader. Not sure if the difference is significant.

          Show
          Alexandre Rafalovitch added a comment - Ok, adding the flag on solr element seems to have fixed the problem. My bad. Does it mean we know where the problem is? However, on the other point, I don't see NamedSPILoader being called from SolrResourceLoader.reloadLuceneSPI(). Rather, I see AnalysisSPILoader. Not sure if the difference is significant.
          Hide
          Uwe Schindler added a comment -

          This is how it is called, just indirect.

          Show
          Uwe Schindler added a comment - This is how it is called, just indirect.
          Hide
          Hoss Man added a comment -

          My bad. Does it mean we know where the problem is?

          it means a few things...

          1) it confirms the problem you were seeing realted to multi-thread core reloading
          2) it means we're seeing consistent results, which narrows down the possible causes (before it looked like there may be two causes of a single symptom: one related to multi-threaded loading that i could reproduce, and one unknown that you could reproduce, now it seems more likeley that they are the same
          3) it means we have a config based work arround for users who encounter this problem w/o requiring a code patch.

          Can you try out the patch Uwe posted to LUCENE-4796? his comments there helped me realize why my earlier attempts at fixing this bug didn't work for me, and with his most recent patch i can't reproduce this problem. would be good to have your feedback.

          Show
          Hoss Man added a comment - My bad. Does it mean we know where the problem is? it means a few things... 1) it confirms the problem you were seeing realted to multi-thread core reloading 2) it means we're seeing consistent results, which narrows down the possible causes (before it looked like there may be two causes of a single symptom: one related to multi-threaded loading that i could reproduce, and one unknown that you could reproduce, now it seems more likeley that they are the same 3) it means we have a config based work arround for users who encounter this problem w/o requiring a code patch. Can you try out the patch Uwe posted to LUCENE-4796 ? his comments there helped me realize why my earlier attempts at fixing this bug didn't work for me, and with his most recent patch i can't reproduce this problem. would be good to have your feedback.
          Hide
          Uwe Schindler added a comment -

          The problem is in AnalysisSPILoader (not NamedSPILoader). The thread safetly issue is not really the problem (it might be problem). The bug is in incorrect copypasted code in AnalysisSPILoader: The reload() method throws away all already loaded SPIs and starts with an empty list. I fixed it in LUCENE-4796.

          Uwe

          Show
          Uwe Schindler added a comment - The problem is in AnalysisSPILoader (not NamedSPILoader). The thread safetly issue is not really the problem (it might be problem). The bug is in incorrect copypasted code in AnalysisSPILoader: The reload() method throws away all already loaded SPIs and starts with an empty list. I fixed it in LUCENE-4796 . Uwe
          Hide
          Alexandre Rafalovitch added a comment -

          I am trying to build the distribution to confirm, but - since it is my first time - not sure what sequence of ant commands to run to get fully functioning example directory with all the dist and contrib libraries in place. *run-example* does not seem to generate the dist/contrib libraries and I am not using subversion for *distrib* command.

          Wiki seems to be silent on that as well. Is there a new developer guide somewhere?

          Show
          Alexandre Rafalovitch added a comment - I am trying to build the distribution to confirm, but - since it is my first time - not sure what sequence of ant commands to run to get fully functioning example directory with all the dist and contrib libraries in place. * run-example * does not seem to generate the dist/contrib libraries and I am not using subversion for * distrib * command. Wiki seems to be silent on that as well. Is there a new developer guide somewhere?
          Hide
          Rene Nederhand added a comment -

          You have to do an "ant example" in the solr directory.

          Glad this problem seems to be solved. This bug already cost me a lot of
          hours...

          On Tue, Feb 26, 2013 at 2:58 PM, Alexandre Rafalovitch (JIRA) <

          Show
          Rene Nederhand added a comment - You have to do an "ant example" in the solr directory. Glad this problem seems to be solved. This bug already cost me a lot of hours... On Tue, Feb 26, 2013 at 2:58 PM, Alexandre Rafalovitch (JIRA) <
          Hide
          Alexandre Rafalovitch added a comment -

          "ant example" does not build additional libraries in dist and contrib directories. And that's what I am using for the test.

          I guess I can change the path in the test to use pre-built libraries from downloaded distribution, but would still be useful to know how to build the whole lot.

          Show
          Alexandre Rafalovitch added a comment - "ant example" does not build additional libraries in dist and contrib directories. And that's what I am using for the test. I guess I can change the path in the test to use pre-built libraries from downloaded distribution, but would still be useful to know how to build the whole lot.
          Hide
          Rene Nederhand added a comment -

          Sorry, I thought this would be clear from the readme. This is what I do (in
          Linux):

          svn co http://svn.apache.org/repos/asf/lucene/dev/trunk/
          lucene-trunkcd lucene_trunk*# Apply patches (e.g. patch -p0 <
          SOLR-3808-4.1-1.patch)*# It might be necessary to to a "ant
          ivy-bootstrap" first# Based on ant 1.8.4
          ant compilecd solr
          ant example
          ant dist

          On Tue, Feb 26, 2013 at 3:24 PM, Alexandre Rafalovitch (JIRA) <

          Show
          Rene Nederhand added a comment - Sorry, I thought this would be clear from the readme. This is what I do (in Linux): svn co http://svn.apache.org/repos/asf/lucene/dev/trunk/ lucene-trunkcd lucene_trunk*# Apply patches (e.g. patch -p0 < SOLR-3808 -4.1-1.patch)*# It might be necessary to to a "ant ivy-bootstrap" first# Based on ant 1.8.4 ant compilecd solr ant example ant dist On Tue, Feb 26, 2013 at 3:24 PM, Alexandre Rafalovitch (JIRA) <
          Hide
          Commit Tag Bot added a comment -

          [trunk commit] Uwe Schindler
          http://svn.apache.org/viewvc?view=revision&revision=1450275

          LUCENE-4796, SOLR-4373: Fix concurrency issue in NamedSPILoader and AnalysisSPILoader when doing concurrent core loads in multicore Solr configs

          Show
          Commit Tag Bot added a comment - [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1450275 LUCENE-4796 , SOLR-4373 : Fix concurrency issue in NamedSPILoader and AnalysisSPILoader when doing concurrent core loads in multicore Solr configs
          Hide
          Uwe Schindler added a comment -

          I think this should be solved by LUCENE-4796, which is committed now. I keep this issue open until somebody confirms, that the fix is working for Solr.

          Show
          Uwe Schindler added a comment - I think this should be solved by LUCENE-4796 , which is committed now. I keep this issue open until somebody confirms, that the fix is working for Solr.
          Hide
          Commit Tag Bot added a comment -

          [branch_4x commit] Uwe Schindler
          http://svn.apache.org/viewvc?view=revision&revision=1450276

          Merged revision(s) 1450275 from lucene/dev/trunk:
          LUCENE-4796, SOLR-4373: Fix concurrency issue in NamedSPILoader and AnalysisSPILoader when doing concurrent core loads in multicore Solr configs

          Show
          Commit Tag Bot added a comment - [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revision&revision=1450276 Merged revision(s) 1450275 from lucene/dev/trunk: LUCENE-4796 , SOLR-4373 : Fix concurrency issue in NamedSPILoader and AnalysisSPILoader when doing concurrent core loads in multicore Solr configs
          Hide
          Rene Nederhand added a comment -

          I'm still experiencing the same problems (rev 1450937): Libraries cannot be found.

          Moreover, the workaround by adding coreLoadThreads="1" to solr.xml does not work in SolrCloud. I get: "SolrCloud requires a value of at least 2 in solr.xml for coreLoadThreads".

          One additional observation: The first time I create a core it fails, however the second time it succeeds. Does anyone knows why it happens? FYI: I am attaching the test script I am using to upload, link the config and create the cores.

          Show
          Rene Nederhand added a comment - I'm still experiencing the same problems (rev 1450937): Libraries cannot be found. Moreover, the workaround by adding coreLoadThreads="1" to solr.xml does not work in SolrCloud. I get: "SolrCloud requires a value of at least 2 in solr.xml for coreLoadThreads". One additional observation: The first time I create a core it fails, however the second time it succeeds. Does anyone knows why it happens? FYI: I am attaching the test script I am using to upload, link the config and create the cores.
          Hide
          Rene Nederhand added a comment -

          Test script to create a collection, upload/link a config and create two cores.

          Show
          Rene Nederhand added a comment - Test script to create a collection, upload/link a config and create two cores.
          Hide
          Hoss Man added a comment -

          I'm still experiencing the same problems (rev 1450937): Libraries cannot be found.

          ...

          The first time I create a core it fails, however the second time it succeeds.

          On the same instance? or do you mean you get an error creating shard1 on port 8080, but when you create shard2 on 8081 that works?

          That sounds like it is a probably a distinct, semi-related, bug.

          can you please file a new jira, and include: both the svn rev and branch you are using (trunk vs 4x), the details of the configs you are using, the details of the errors you get (full logs would be nice so we can see the core startup info), and when/where you get those errors in the process of your script (ie: is it when creating the collection? linking the config to the collection? creating the cores?)

          Show
          Hoss Man added a comment - I'm still experiencing the same problems (rev 1450937): Libraries cannot be found. ... The first time I create a core it fails, however the second time it succeeds. On the same instance? or do you mean you get an error creating shard1 on port 8080, but when you create shard2 on 8081 that works? That sounds like it is a probably a distinct, semi-related, bug. can you please file a new jira, and include: both the svn rev and branch you are using (trunk vs 4x), the details of the configs you are using, the details of the errors you get (full logs would be nice so we can see the core startup info), and when/where you get those errors in the process of your script (ie: is it when creating the collection? linking the config to the collection? creating the cores?)
          Hide
          Alexandre Rafalovitch added a comment -

          I thought this one was fixed?

          Show
          Alexandre Rafalovitch added a comment - I thought this one was fixed?
          Hide
          Mark Miller added a comment -

          Dunno - no one has resolved it yet.

          Show
          Mark Miller added a comment - Dunno - no one has resolved it yet.
          Hide
          Alexandre Rafalovitch added a comment -

          I think it was fixed in span-off LUCENE-4796 by Uwe and Hoss. But they are not watching this one.

          Show
          Alexandre Rafalovitch added a comment - I think it was fixed in span-off LUCENE-4796 by Uwe and Hoss. But they are not watching this one.
          Hide
          Uwe Schindler added a comment -

          I left this one open, because I wanted a confirmation that the spun off issue resolved this one, too. But there was no clear confirmation on this. So it might be fixed in 4.2 ore not until somebody confirms.

          Show
          Uwe Schindler added a comment - I left this one open, because I wanted a confirmation that the spun off issue resolved this one, too. But there was no clear confirmation on this. So it might be fixed in 4.2 ore not until somebody confirms.
          Hide
          Hoss Man added a comment -

          I'm calling this resolved.

          we had one comment about a possible related issue, but the symptoms didn't match, and as far as i can tell the request for additional details to reproduce (in a new issue) was never responded to.

          Show
          Hoss Man added a comment - I'm calling this resolved. we had one comment about a possible related issue, but the symptoms didn't match, and as far as i can tell the request for additional details to reproduce (in a new issue) was never responded to.
          Hide
          Rene Nederhand added a comment -

          I was the one reporting an issue with the fix, but as it seems I must have made an error somewhere as I tried really hard to reproduce the error in a brand new SolrCloud installation, but wasn't able to. Let's call this resolved.

          Show
          Rene Nederhand added a comment - I was the one reporting an issue with the fix, but as it seems I must have made an error somewhere as I tried really hard to reproduce the error in a brand new SolrCloud installation, but wasn't able to. Let's call this resolved.
          Hide
          Alexandre Rafalovitch added a comment -

          I confirm that this is fixed in 4.2 with my original test case setup.

          Show
          Alexandre Rafalovitch added a comment - I confirm that this is fixed in 4.2 with my original test case setup.
          Hide
          Uwe Schindler added a comment -

          Closed after release.

          Show
          Uwe Schindler added a comment - Closed after release.

            People

            • Assignee:
              Hoss Man
              Reporter:
              Alexandre Rafalovitch
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development