Solr
  1. Solr
  2. SOLR-4852

If sharedLib is set to lib, classloader fails to find classes in lib

    Details

    • Type: Bug Bug
    • Status: Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 4.4
    • Fix Version/s: 4.9, 5.0
    • Component/s: None
    • Labels:
      None
    • Environment:

      Description

      I have some jars in the lib directory under solr.solr.home - DIH, ICU, and MySQL. If I set sharedLib in solr.xml to "lib" then the ICUTokenizer class is not found, even though the jar is loaded (twice) during Solr startup. If I set sharedLib to another location that doesn't exist, the jars are only loaded once and there is no problem.

      I'm using the old-style solr.xml on branch_4x revision 1485566.

      1. SOLR-4852-test-failhard.txt
        384 kB
        Shawn Heisey
      2. SOLR-4852.patch
        2 kB
        Shawn Heisey
      3. SOLR-4852.patch
        1 kB
        Shawn Heisey

        Issue Links

          Activity

          Hide
          Shawn Heisey added a comment -

          If sharedLib is "lib" then this is the log, and it fails to load ICUTokenizer.

          INFO  - 2013-05-22 22:41:15.932; org.apache.solr.core.SolrResourceLoader; using system property solr.solr.home: /index/solr4
          INFO  - 2013-05-22 22:41:15.941; org.apache.solr.core.CoreContainer$Initializer; looking for solr config file: /index/solr4/solr.xml
          INFO  - 2013-05-22 22:41:15.947; org.apache.solr.core.CoreContainer; New CoreContainer 1473971679
          INFO  - 2013-05-22 22:41:15.947; org.apache.solr.core.CoreContainer; Loading CoreContainer using Solr Home: '/index/solr4/'
          INFO  - 2013-05-22 22:41:15.947; org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for directory: '/index/solr4/'
          INFO  - 2013-05-22 22:41:15.949; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/icu4j-49.1.jar' to classloader
          INFO  - 2013-05-22 22:41:15.949; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader
          INFO  - 2013-05-22 22:41:15.951; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-22 22:41:15.952; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-22 22:41:16.250; org.apache.solr.core.CoreContainer; loading shared library: /index/solr4/lib
          INFO  - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/icu4j-49.1.jar' to classloader
          INFO  - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader
          INFO  - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader
          <snip>
          ERROR - 2013-05-22 22:41:16.939; org.apache.solr.common.SolrException; null:java.lang.NoClassDefFoundError: org/apache/lucene/analysis/icu/segmentation/ICUTokenizer
                  at java.lang.Class.getDeclaredConstructors0(Native Method)
                  at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413)
                  at java.lang.Class.getConstructor0(Class.java:2723)
                  at java.lang.Class.getConstructor(Class.java:1676)
                  at org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:550)
                  at org.apache.solr.schema.FieldTypePluginLoader$2.create(FieldTypePluginLoader.java:342)
                  at org.apache.solr.schema.FieldTypePluginLoader$2.create(FieldTypePluginLoader.java:335)
                  at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151)
                  at org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:362)
                  at org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:86)
                  at org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:43)
                  at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151)
                  at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:467)
                  at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:164)
                  at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:55)
                  at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:69)
                  at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:727)
                  at org.apache.solr.core.CoreContainer.create(CoreContainer.java:765)
                  at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:426)
                  at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:421)
                  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
                  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
                  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
                  at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
                  at java.util.concurrent.FutureTask.run(FutureTask.java:166)
                  at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
                  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
                  at java.lang.Thread.run(Thread.java:722)
          Caused by: java.lang.ClassNotFoundException: org.apache.lucene.analysis.icu.segmentation.ICUTokenizer
                  at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
                  at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
                  at java.security.AccessController.doPrivileged(Native Method)
                  at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
                  at java.lang.ClassLoader.loadClass(ClassLoader.java:423)
                  at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:789)
                  at java.lang.ClassLoader.loadClass(ClassLoader.java:356)
                  ... 28 more
          
          Show
          Shawn Heisey added a comment - If sharedLib is "lib" then this is the log, and it fails to load ICUTokenizer. INFO - 2013-05-22 22:41:15.932; org.apache.solr.core.SolrResourceLoader; using system property solr.solr.home: /index/solr4 INFO - 2013-05-22 22:41:15.941; org.apache.solr.core.CoreContainer$Initializer; looking for solr config file: /index/solr4/solr.xml INFO - 2013-05-22 22:41:15.947; org.apache.solr.core.CoreContainer; New CoreContainer 1473971679 INFO - 2013-05-22 22:41:15.947; org.apache.solr.core.CoreContainer; Loading CoreContainer using Solr Home: '/index/solr4/' INFO - 2013-05-22 22:41:15.947; org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for directory: '/index/solr4/' INFO - 2013-05-22 22:41:15.949; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/icu4j-49.1.jar' to classloader INFO - 2013-05-22 22:41:15.949; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader INFO - 2013-05-22 22:41:15.951; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-22 22:41:15.952; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-22 22:41:16.250; org.apache.solr.core.CoreContainer; loading shared library: /index/solr4/lib INFO - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/icu4j-49.1.jar' to classloader INFO - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader INFO - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-22 22:41:16.251; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader <snip> ERROR - 2013-05-22 22:41:16.939; org.apache.solr.common.SolrException; null:java.lang.NoClassDefFoundError: org/apache/lucene/analysis/icu/segmentation/ICUTokenizer at java.lang.Class.getDeclaredConstructors0(Native Method) at java.lang.Class.privateGetDeclaredConstructors(Class.java:2413) at java.lang.Class.getConstructor0(Class.java:2723) at java.lang.Class.getConstructor(Class.java:1676) at org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:550) at org.apache.solr.schema.FieldTypePluginLoader$2.create(FieldTypePluginLoader.java:342) at org.apache.solr.schema.FieldTypePluginLoader$2.create(FieldTypePluginLoader.java:335) at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151) at org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:362) at org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:86) at org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:43) at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151) at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:467) at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:164) at org.apache.solr.schema.IndexSchemaFactory.create(IndexSchemaFactory.java:55) at org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:69) at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:727) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:765) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:426) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:421) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:722) Caused by: java.lang.ClassNotFoundException: org.apache.lucene.analysis.icu.segmentation.ICUTokenizer at java.net.URLClassLoader$1.run(URLClassLoader.java:366) at java.net.URLClassLoader$1.run(URLClassLoader.java:355) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:354) at java.lang.ClassLoader.loadClass(ClassLoader.java:423) at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:789) at java.lang.ClassLoader.loadClass(ClassLoader.java:356) ... 28 more
          Hide
          Shawn Heisey added a comment -

          If sharedLib is "foo" (which doesn't exist) then this is the log, and everything works. The jars are only loaded once.

          INFO  - 2013-05-22 22:35:56.404; org.apache.solr.core.SolrResourceLoader; using system property solr.solr.home: /index/solr4
          INFO  - 2013-05-22 22:35:56.413; org.apache.solr.core.CoreContainer$Initializer; looking for solr config file: /index/solr4/solr.xml
          INFO  - 2013-05-22 22:35:56.419; org.apache.solr.core.CoreContainer; New CoreContainer 1473971679
          INFO  - 2013-05-22 22:35:56.419; org.apache.solr.core.CoreContainer; Loading CoreContainer using Solr Home: '/index/solr4/'
          INFO  - 2013-05-22 22:35:56.419; org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for directory: '/index/solr4/'
          INFO  - 2013-05-22 22:35:56.421; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/icu4j-49.1.jar' to classloader
          INFO  - 2013-05-22 22:35:56.421; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader
          INFO  - 2013-05-22 22:35:56.424; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-22 22:35:56.424; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-22 22:35:56.718; org.apache.solr.core.CoreContainer; loading shared library: /index/solr4/foo
          WARN  - 2013-05-22 22:35:56.718; org.apache.solr.core.SolrResourceLoader; Can't find (or read) directory to add to classloader: foo (resolved as: /index/solr4/foo).
          
          Show
          Shawn Heisey added a comment - If sharedLib is "foo" (which doesn't exist) then this is the log, and everything works. The jars are only loaded once. INFO - 2013-05-22 22:35:56.404; org.apache.solr.core.SolrResourceLoader; using system property solr.solr.home: /index/solr4 INFO - 2013-05-22 22:35:56.413; org.apache.solr.core.CoreContainer$Initializer; looking for solr config file: /index/solr4/solr.xml INFO - 2013-05-22 22:35:56.419; org.apache.solr.core.CoreContainer; New CoreContainer 1473971679 INFO - 2013-05-22 22:35:56.419; org.apache.solr.core.CoreContainer; Loading CoreContainer using Solr Home: '/index/solr4/' INFO - 2013-05-22 22:35:56.419; org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for directory: '/index/solr4/' INFO - 2013-05-22 22:35:56.421; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/icu4j-49.1.jar' to classloader INFO - 2013-05-22 22:35:56.421; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader INFO - 2013-05-22 22:35:56.424; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-22 22:35:56.424; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-22 22:35:56.718; org.apache.solr.core.CoreContainer; loading shared library: /index/solr4/foo WARN - 2013-05-22 22:35:56.718; org.apache.solr.core.SolrResourceLoader; Can't find (or read) directory to add to classloader: foo (resolved as: /index/solr4/foo).
          Hide
          Shawn Heisey added a comment - - edited

          This setup has worked perfectly with all 3.x and 4.x versions up through 4.3.0. I suspect that the sharedLib bugfix that went into 4.3.1 is behind this problem.

          Show
          Shawn Heisey added a comment - - edited This setup has worked perfectly with all 3.x and 4.x versions up through 4.3.0. I suspect that the sharedLib bugfix that went into 4.3.1 is behind this problem.
          Hide
          Robert Muir added a comment -

          Im not sure there is a problem: I think its correct now and was broken before. Your setup just relies upon broken behavior... don't use the same directory as both a top-level lib/ and a per-core lib/

          Show
          Robert Muir added a comment - Im not sure there is a problem: I think its correct now and was broken before. Your setup just relies upon broken behavior... don't use the same directory as both a top-level lib/ and a per-core lib/
          Hide
          Shawn Heisey added a comment -

          Robert Muir - thanks. I did wonder if it might have been buggy before. Having this issue here for others to find may help someone, even if it's decided that this isn't a bug.

          I am a little mystified by the fact that it can't find a class just because it has loaded the jar twice, though. I am not well-versed in classloader behavior ... is that expected?

          Show
          Shawn Heisey added a comment - Robert Muir - thanks. I did wonder if it might have been buggy before. Having this issue here for others to find may help someone, even if it's decided that this isn't a bug. I am a little mystified by the fact that it can't find a class just because it has loaded the jar twice, though. I am not well-versed in classloader behavior ... is that expected?
          Hide
          Robert Muir added a comment -

          I'm not mystified. you just didnt give the full exception. ICU has a lot more than classes in its jars, lots of resources, SPI modules, etc. Its fairly complex. I wouldnt load it twice.

          Show
          Robert Muir added a comment - I'm not mystified. you just didnt give the full exception. ICU has a lot more than classes in its jars, lots of resources, SPI modules, etc. Its fairly complex. I wouldnt load it twice.
          Hide
          Shawn Heisey added a comment - - edited

          Would there be any value in trying to detect when the sharedLib value resolves to the same path as the lib under solr.solr.home, or detecting when a jar is loaded twice? If SOLR-4495 is implemented, such checking could become even more important, because someone might list the same path as relative and absolute and not realize they've made a mistake.

          Show
          Shawn Heisey added a comment - - edited Would there be any value in trying to detect when the sharedLib value resolves to the same path as the lib under solr.solr.home, or detecting when a jar is loaded twice? If SOLR-4495 is implemented, such checking could become even more important, because someone might list the same path as relative and absolute and not realize they've made a mistake.
          Hide
          Robert Muir added a comment -

          I think if it could be correctly implemented, it might be useful. But i'm not sure its as simple as checking the parent URLClassloader's list of URLS, because you are suggesting a more complex equality such as relative vs absolute paths.

          And besides that still wouldn't detect a lot of problems:

          • jar has different version (ICU-4.0 vs 4.0.1)
          • jar is the same but physically somewhere else on the file system
          • jar is different but has same class/resource names (i'm looking at you logging jars)
          Show
          Robert Muir added a comment - I think if it could be correctly implemented, it might be useful. But i'm not sure its as simple as checking the parent URLClassloader's list of URLS, because you are suggesting a more complex equality such as relative vs absolute paths. And besides that still wouldn't detect a lot of problems: jar has different version (ICU-4.0 vs 4.0.1) jar is the same but physically somewhere else on the file system jar is different but has same class/resource names (i'm looking at you logging jars)
          Hide
          Shawn Heisey added a comment -

          And besides that still wouldn't detect a lot of problems:

          • jar has different version (ICU-4.0 vs 4.0.1)
          • jar is the same but physically somewhere else on the file system
          • jar is different but has same class/resource names (i'm looking at you logging jars)

          It's true that we can't detect all possible problems. In cases where File objects are being used, doing a getCanonicalPath() comparison each time a lib folder is added would catch many misconfigs, including the mistake that I made. If it's possible, comparing getCanonicalPath() on each jar would catch more.

          Show
          Shawn Heisey added a comment - And besides that still wouldn't detect a lot of problems: jar has different version (ICU-4.0 vs 4.0.1) jar is the same but physically somewhere else on the file system jar is different but has same class/resource names (i'm looking at you logging jars) It's true that we can't detect all possible problems. In cases where File objects are being used, doing a getCanonicalPath() comparison each time a lib folder is added would catch many misconfigs, including the mistake that I made. If it's possible, comparing getCanonicalPath() on each jar would catch more.
          Hide
          Shawn Heisey added a comment -

          First crack at a patch. It doesn't work - it results in a test failure as well as similar exceptions when I have sharedLib="lib" in my solr.xml. I will investigate why it doesn't work, but if anyone else has any ideas, feel free to share.

          Show
          Shawn Heisey added a comment - First crack at a patch. It doesn't work - it results in a test failure as well as similar exceptions when I have sharedLib="lib" in my solr.xml. I will investigate why it doesn't work, but if anyone else has any ideas, feel free to share.
          Hide
          Shawn Heisey added a comment -

          Updated patch. Tests now pass, using sharedLib="lib" now works because it skips loading the duplicates. Doesn't yet have CHANGES.txt.

          Show
          Shawn Heisey added a comment - Updated patch. Tests now pass, using sharedLib="lib" now works because it skips loading the duplicates. Doesn't yet have CHANGES.txt.
          Hide
          Shawn Heisey added a comment -

          While testing the latest patch, I came across another situation that appears to be a separate bug. This problem happens with a vanilla branch_4x, but also happens with my patch.

          What I did was set sharedLib to foo, then moved icu4j-49.1.jar from lib to foo, both under solr.solr.home. Some of my jars were in the automatically added lib, and one of them was in the explicitly stated foo.

          Splitting the libs in this way resulted in the following log output, followed by the same exception mentioned in a comment above - it was unable to find ICUTokenizer.

          INFO  - 2013-05-25 02:25:09.890; org.apache.solr.core.CoreContainer; New CoreContainer 1473971679
          INFO  - 2013-05-25 02:25:09.891; org.apache.solr.core.CoreContainer; Loading CoreContainer using Solr Home: '/index/solr4/'
          INFO  - 2013-05-25 02:25:09.891; org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for directory: '/index/solr4/'
          INFO  - 2013-05-25 02:25:09.893; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader
          INFO  - 2013-05-25 02:25:09.893; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-25 02:25:09.895; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader
          INFO  - 2013-05-25 02:25:10.306; org.apache.solr.core.CoreContainer; loading shared library: /index/solr4/foo
          INFO  - 2013-05-25 02:25:10.306; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/foo/icu4j-49.1.jar' to classloader
          

          At first I was thinking it might be an object visibility problem, so I tried making replaceClassLoader synchronized and then tried making classLoader volatile, neither change made it work. If all of the jars are in either lib or foo, then everything works.

          Show
          Shawn Heisey added a comment - While testing the latest patch, I came across another situation that appears to be a separate bug. This problem happens with a vanilla branch_4x, but also happens with my patch. What I did was set sharedLib to foo, then moved icu4j-49.1.jar from lib to foo, both under solr.solr.home. Some of my jars were in the automatically added lib, and one of them was in the explicitly stated foo. Splitting the libs in this way resulted in the following log output, followed by the same exception mentioned in a comment above - it was unable to find ICUTokenizer. INFO - 2013-05-25 02:25:09.890; org.apache.solr.core.CoreContainer; New CoreContainer 1473971679 INFO - 2013-05-25 02:25:09.891; org.apache.solr.core.CoreContainer; Loading CoreContainer using Solr Home: '/index/solr4/' INFO - 2013-05-25 02:25:09.891; org.apache.solr.core.SolrResourceLoader; new SolrResourceLoader for directory: '/index/solr4/' INFO - 2013-05-25 02:25:09.893; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/mysql-connector-java-5.1.22-bin.jar' to classloader INFO - 2013-05-25 02:25:09.893; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/solr-dataimporthandler-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-25 02:25:09.895; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/lib/lucene-analyzers-icu-4.4-SNAPSHOT.jar' to classloader INFO - 2013-05-25 02:25:10.306; org.apache.solr.core.CoreContainer; loading shared library: /index/solr4/foo INFO - 2013-05-25 02:25:10.306; org.apache.solr.core.SolrResourceLoader; Adding 'file:/index/solr4/foo/icu4j-49.1.jar' to classloader At first I was thinking it might be an object visibility problem, so I tried making replaceClassLoader synchronized and then tried making classLoader volatile, neither change made it work. If all of the jars are in either lib or foo, then everything works.
          Hide
          Robert Muir added a comment -

          -1 to this lenient patch. If someone has a .configuration error, fail hard.

          Show
          Robert Muir added a comment - -1 to this lenient patch. If someone has a .configuration error, fail hard.
          Hide
          Shawn Heisey added a comment -

          When I use RuntimeException to fail hard because of a duplicate URL, two existing Solr tests fail.

          I'm beginning to think that this is a problem specific to the ICU analysis components, something subtle that happens when the classloader is replaced.

          Show
          Shawn Heisey added a comment - When I use RuntimeException to fail hard because of a duplicate URL, two existing Solr tests fail. I'm beginning to think that this is a problem specific to the ICU analysis components, something subtle that happens when the classloader is replaced.
          Hide
          Erick Erickson added a comment -

          Sorry, got the wrong one when closing JIRAs related to SOLR-4910

          Show
          Erick Erickson added a comment - Sorry, got the wrong one when closing JIRAs related to SOLR-4910
          Hide
          Steve Rowe added a comment -

          Bulk move 4.4 issues to 4.5 and 5.0

          Show
          Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
          Hide
          Shawn Heisey added a comment - - edited

          There may be some confusion about what's going on with this issue.

          This issue affects 4.3 and later. Summary: If you are putting jars in solrhome/lib then you must remove any sharedLib setting that points at this directory, either with "lib" or an explicit path. Also, you cannot put some jars in solrhome/lib and others in a location specified by sharedLib - they must all be in the same location.

          The same config won't work on 4.2.1 and earlier if you are putting jars in solrhome/lib. The sharedLib attribute must exist and point at that location, or you will see that the classloader loads the jars, but the classes in those jars are not found when the config or schema tries to use them. This part is something I learned today while trying to work with the older version.

          I've been told that the behavior documented in this issue is not actually a problem. I personally disagree with that assessment, but there is a workaround available. We probably need some minor documentation changes.

          Show
          Shawn Heisey added a comment - - edited There may be some confusion about what's going on with this issue. This issue affects 4.3 and later. Summary: If you are putting jars in solrhome/lib then you must remove any sharedLib setting that points at this directory, either with "lib" or an explicit path. Also, you cannot put some jars in solrhome/lib and others in a location specified by sharedLib - they must all be in the same location. The same config won't work on 4.2.1 and earlier if you are putting jars in solrhome/lib. The sharedLib attribute must exist and point at that location, or you will see that the classloader loads the jars, but the classes in those jars are not found when the config or schema tries to use them. This part is something I learned today while trying to work with the older version. I've been told that the behavior documented in this issue is not actually a problem. I personally disagree with that assessment, but there is a workaround available. We probably need some minor documentation changes.
          Hide
          Uwe Schindler added a comment -

          Move issue to Solr 4.9.

          Show
          Uwe Schindler added a comment - Move issue to Solr 4.9.
          Hide
          Ahmet Arslan added a comment -

          This is not all about loading same jar twice. Here is an interesting finding.

          I remove all lib directives in example solrconfig.xml and put icu4j-53.1.jar and lucene-analyzers-icu-4.8.1.jar into collection1/lib folder.

          solr.ICUFoldingFilterFactory works file.

          Just add following line to solrconfig.xml

            <lib dir="../../../dist/" regex="solr-velocity-\d.*\.jar" />
          

          bum it fails. I have a feeling that this is nothing to do with twice loading. It looks line order of processed lib directives causing something.

          Show
          Ahmet Arslan added a comment - This is not all about loading same jar twice. Here is an interesting finding. I remove all lib directives in example solrconfig.xml and put icu4j-53.1.jar and lucene-analyzers-icu-4.8.1.jar into collection1/lib folder. solr.ICUFoldingFilterFactory works file. Just add following line to solrconfig.xml <lib dir= "../../../dist/" regex= "solr-velocity-\d.*\.jar" /> bum it fails. I have a feeling that this is nothing to do with twice loading. It looks line order of processed lib directives causing something.
          Hide
          Ahmet Arslan added a comment -

          In above setting no duplicate jars loaded. Only one explicit lib directive is defined in solrconfig.xml along with implicit one. core/lib. following lines printed during startup.

          1751 [coreLoadExecutor-4-thread-1] INFO  org.apache.solr.core.SolrResourceLoader  – new SolrResourceLoader for directory: '/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/'
          1752 [coreLoadExecutor-4-thread-1] INFO  org.apache.solr.core.SolrResourceLoader  – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/lib/.DS_Store' to classloader
          1752 [coreLoadExecutor-4-thread-1] INFO  org.apache.solr.core.SolrResourceLoader  – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/lib/icu4j-53.1.jar' to classloader
          1752 [coreLoadExecutor-4-thread-1] INFO  org.apache.solr.core.SolrResourceLoader  – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/lib/lucene-analyzers-icu-4.8.1.jar' to classloader
          1833 [coreLoadExecutor-4-thread-1] INFO  org.apache.solr.core.SolrConfig  – Adding specified lib dirs to ClassLoader
          1835 [coreLoadExecutor-4-thread-1] INFO  org.apache.solr.core.SolrResourceLoader  – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/dist/solr-velocity-4.8.1.jar' to classloader
          
          

          This fails for no reason. By the way why does this load non - jar hidden .DS file :
          4.8.1/example/solr/collection1/lib/.DS_Store' to classloader

          Show
          Ahmet Arslan added a comment - In above setting no duplicate jars loaded. Only one explicit lib directive is defined in solrconfig.xml along with implicit one. core/lib. following lines printed during startup. 1751 [coreLoadExecutor-4-thread-1] INFO org.apache.solr.core.SolrResourceLoader – new SolrResourceLoader for directory: '/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/' 1752 [coreLoadExecutor-4-thread-1] INFO org.apache.solr.core.SolrResourceLoader – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/lib/.DS_Store' to classloader 1752 [coreLoadExecutor-4-thread-1] INFO org.apache.solr.core.SolrResourceLoader – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/lib/icu4j-53.1.jar' to classloader 1752 [coreLoadExecutor-4-thread-1] INFO org.apache.solr.core.SolrResourceLoader – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/example/solr/collection1/lib/lucene-analyzers-icu-4.8.1.jar' to classloader 1833 [coreLoadExecutor-4-thread-1] INFO org.apache.solr.core.SolrConfig – Adding specified lib dirs to ClassLoader 1835 [coreLoadExecutor-4-thread-1] INFO org.apache.solr.core.SolrResourceLoader – Adding 'file:/Users/iorixxx/Desktop/solr-4.8.1/dist/solr-velocity-4.8.1.jar' to classloader This fails for no reason. By the way why does this load non - jar hidden .DS file : 4.8.1/example/solr/collection1/lib/.DS_Store' to classloader
          Hide
          Shawn Heisey added a comment -

          Another theory I've considered is that the problem is caused by the resource loader object being replaced, which from my research apparently has to be done anytime you need to add another directory or list of jars. This theory would be disproved by a setup that has more than one <lib> directive and uses classes in jars from both locations ... and there are probably some of those out there.

          I willingly admit that I do not understand what causes the problems that I documented here. I looked into the Solr code and poked around the Java 7 API javadocs, but I wasn't able to make sense of it.

          Show
          Shawn Heisey added a comment - Another theory I've considered is that the problem is caused by the resource loader object being replaced, which from my research apparently has to be done anytime you need to add another directory or list of jars. This theory would be disproved by a setup that has more than one <lib> directive and uses classes in jars from both locations ... and there are probably some of those out there. I willingly admit that I do not understand what causes the problems that I documented here. I looked into the Solr code and poked around the Java 7 API javadocs, but I wasn't able to make sense of it.
          Hide
          Uwe Schindler added a comment -

          Hi Shawn, this is the issue here: I explain the problem in the linked issue: SOLR-6188

          Show
          Uwe Schindler added a comment - Hi Shawn, this is the issue here: I explain the problem in the linked issue: SOLR-6188

            People

            • Assignee:
              Unassigned
              Reporter:
              Shawn Heisey
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:

                Development