Solr
  1. Solr
  2. SOLR-6188

solr.ICUFoldingFilterFactory causes NoClassDefFoundError: o/a/l/a/icu/ICUFoldingFilter

    Details

      Description

      When fully qualified class name is used in schema.xml

      org.apache.lucene.analysis.icu.ICUFoldingFilterFactory

      it works. However as documented in confluence and wiki, when solr.ICUFoldingFilterFactory is used it throws following exception.

      This is true for both released 4.8.1 version and trunk r1604168
      following type works :

          
           <fieldType name="folded2" class="solr.TextField">
            <analyzer>
              <tokenizer class="solr.StandardTokenizerFactory"/>
              <filter class="org.apache.lucene.analysis.icu.ICUFoldingFilterFactory"/>
            </analyzer>
          </fieldType>
      

      this does not :

      
       <fieldType name="folded" class="solr.TextField">
            <analyzer>
              <tokenizer class="solr.StandardTokenizerFactory"/>
              <filter class="solr.ICUFoldingFilterFactory"/>
            </analyzer>
          </fieldType>
      
      257 [main] ERROR org.apache.solr.core.SolrCore  – Error loading core:java.util.concurrent.ExecutionException: java.lang.NoClassDefFoundError: org/apache/lucene/analysis/icu/ICUFoldingFilter
      	at java.util.concurrent.FutureTask.report(FutureTask.java:122)
      	at java.util.concurrent.FutureTask.get(FutureTask.java:188)
      	at org.apache.solr.core.CoreContainer.load(CoreContainer.java:301)
      	at org.apache.solr.servlet.SolrDispatchFilter.createCoreContainer(SolrDispatchFilter.java:190)
      	at org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:137)
      	at org.eclipse.jetty.servlet.FilterHolder.doStart(FilterHolder.java:119)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
      	at org.eclipse.jetty.servlet.ServletHandler.initialize(ServletHandler.java:719)
      	at org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:265)
      	at org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1252)
      	at org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:710)
      	at org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:494)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
      	at org.eclipse.jetty.deploy.bindings.StandardStarter.processBinding(StandardStarter.java:39)
      	at org.eclipse.jetty.deploy.AppLifeCycle.runBindings(AppLifeCycle.java:186)
      	at org.eclipse.jetty.deploy.DeploymentManager.requestAppGoal(DeploymentManager.java:494)
      	at org.eclipse.jetty.deploy.DeploymentManager.addApp(DeploymentManager.java:141)
      	at org.eclipse.jetty.deploy.providers.ScanningAppProvider.fileAdded(ScanningAppProvider.java:145)
      	at org.eclipse.jetty.deploy.providers.ScanningAppProvider$1.fileAdded(ScanningAppProvider.java:56)
      	at org.eclipse.jetty.util.Scanner.reportAddition(Scanner.java:609)
      	at org.eclipse.jetty.util.Scanner.reportDifferences(Scanner.java:540)
      	at org.eclipse.jetty.util.Scanner.scan(Scanner.java:403)
      	at org.eclipse.jetty.util.Scanner.doStart(Scanner.java:337)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
      	at org.eclipse.jetty.deploy.providers.ScanningAppProvider.doStart(ScanningAppProvider.java:121)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
      	at org.eclipse.jetty.deploy.DeploymentManager.startAppProvider(DeploymentManager.java:555)
      	at org.eclipse.jetty.deploy.DeploymentManager.doStart(DeploymentManager.java:230)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
      	at org.eclipse.jetty.util.component.AggregateLifeCycle.doStart(AggregateLifeCycle.java:81)
      	at org.eclipse.jetty.server.handler.AbstractHandler.doStart(AbstractHandler.java:58)
      	at org.eclipse.jetty.server.handler.HandlerWrapper.doStart(HandlerWrapper.java:96)
      	at org.eclipse.jetty.server.Server.doStart(Server.java:280)
      	at org.eclipse.jetty.util.component.AbstractLifeCycle.start(AbstractLifeCycle.java:64)
      	at org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1259)
      	at java.security.AccessController.doPrivileged(Native Method)
      	at org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1182)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
      	at java.lang.reflect.Method.invoke(Method.java:606)
      	at org.eclipse.jetty.start.Main.invokeMain(Main.java:473)
      	at org.eclipse.jetty.start.Main.start(Main.java:615)
      	at org.eclipse.jetty.start.Main.main(Main.java:96)
      Caused by: java.lang.NoClassDefFoundError: org/apache/lucene/analysis/icu/ICUFoldingFilter
      	at java.lang.Class.getDeclaredConstructors0(Native Method)
      	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2493)
      	at java.lang.Class.getConstructor0(Class.java:2803)
      	at java.lang.Class.getConstructor(Class.java:1718)
      	at org.apache.solr.core.SolrResourceLoader.newInstance(SolrResourceLoader.java:602)
      	at org.apache.solr.schema.FieldTypePluginLoader$3.create(FieldTypePluginLoader.java:382)
      	at org.apache.solr.schema.FieldTypePluginLoader$3.create(FieldTypePluginLoader.java:376)
      	at org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:151)
      	at org.apache.solr.schema.FieldTypePluginLoader.readAnalyzer(FieldTypePluginLoader.java:400)
      	at org.apache.solr.schema.FieldTypePluginLoader.create(FieldTypePluginLoader.java:95)
      	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:492)
      	at org.apache.solr.schema.IndexSchema.<init>(IndexSchema.java:172)
      	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.ConfigSetService.createIndexSchema(ConfigSetService.java:89)
      	at org.apache.solr.core.ConfigSetService.getConfig(ConfigSetService.java:62)
      	at org.apache.solr.core.CoreContainer.create(CoreContainer.java:554)
      	at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:261)
      	at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:253)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
      	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
      	at java.util.concurrent.FutureTask.run(FutureTask.java:262)
      	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:745)
      Caused by: java.lang.ClassNotFoundException: org.apache.lucene.analysis.icu.ICUFoldingFilter
      	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:425)
      	at java.net.FactoryURLClassLoader.loadClass(URLClassLoader.java:789)
      	at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
      	... 27 more
      
      1. SOLR-6188.patch
        2 kB
        Shawn Heisey
      2. SOLR-6188.patch
        2 kB
        Shawn Heisey
      3. SOLR-6188.patch
        2 kB
        Shawn Heisey
      4. SOLR-6188.patch
        2 kB
        Shawn Heisey
      5. SOLR-6188.patch
        2 kB
        Shawn Heisey
      6. SOLR-6188.patch
        0.9 kB
        Shawn Heisey
      7. SOLR-6188.patch
        0.5 kB
        Shawn Heisey

        Issue Links

          Activity

          Hide
          Robert Muir added a comment -

          Usually this is because you have not configured the correct classpath.

          Show
          Robert Muir added a comment - Usually this is because you have not configured the correct classpath.
          Hide
          Ahmet Arslan added a comment -

          Hi Robert, I thought the same at first, but I have these two jars : icu4j-53.1.jar and lucene-analyzers-icu-5.0-SNAPSHOT.jar inside
          solr-trunk/solr/example/solr/collection1/lib directory. Besides it shouldn't work when org.apache.lucene.analysis.icu.ICUFoldingFilterFactory is used.

          I am downloading your 4.9 release candidate, i will test it with that too.

          Show
          Ahmet Arslan added a comment - Hi Robert, I thought the same at first, but I have these two jars : icu4j-53.1.jar and lucene-analyzers-icu-5.0-SNAPSHOT.jar inside solr-trunk/solr/example/solr/collection1/lib directory. Besides it shouldn't work when org.apache.lucene.analysis.icu.ICUFoldingFilterFactory is used. I am downloading your 4.9 release candidate, i will test it with that too.
          Hide
          Ahmet Arslan added a comment -

          Same symptom. solr.ICU*Factory in schema.xml causes not found exception for org.apache.lucene.* class.

          Show
          Ahmet Arslan added a comment - Same symptom. solr.ICU*Factory in schema.xml causes not found exception for org.apache.lucene.* class.
          Hide
          Uwe Schindler added a comment -

          Hi the reason for this issue is indeed caused by SOLR-4852: The reason why it works with absolute classname is the following:

          • If you use the absolute class name, the class is loaded by Class.forName from SolrResourceLoader
          • If you use the shortcut, the Solr 3.x backwards layer for finding factory classes is used. The solr.XXXFactory name is rewritten to a call to TokenFilterFactory.forName(). This forName call uses the classpath it was initialized with. TokenFilterFactory is a static class and doe snot really know classloaders (because there is only one single instance). Every SolrResourceLoader calls an update process, that scans the own classpath and adds all new factory instances to the forName() lookup map.

          What happens here: In an earlier stage, it looks like SolrResourceLoader has seen a Factory instance loaded by SPI and cached its factory class for forName(). But later the classpath and classloader was replaced and the scanner was called again. This onescanned classpath again, and found a new instance of the FactoryClass (the new one that should be used). Because this one was already in the forName cache, it did not replace that one. In the meantime, the old classloader was closed with Java 7's URLClassLoacer.close() method. Because of this a call to forName returned the factory class, but the dependend classes it was referring to are no longer loadable (classloader closed). This causes the bug.

          The fix is not easily possible, I will think about it.

          Show
          Uwe Schindler added a comment - Hi the reason for this issue is indeed caused by SOLR-4852 : The reason why it works with absolute classname is the following: If you use the absolute class name, the class is loaded by Class.forName from SolrResourceLoader If you use the shortcut, the Solr 3.x backwards layer for finding factory classes is used. The solr.XXXFactory name is rewritten to a call to TokenFilterFactory.forName(). This forName call uses the classpath it was initialized with. TokenFilterFactory is a static class and doe snot really know classloaders (because there is only one single instance). Every SolrResourceLoader calls an update process, that scans the own classpath and adds all new factory instances to the forName() lookup map. What happens here: In an earlier stage, it looks like SolrResourceLoader has seen a Factory instance loaded by SPI and cached its factory class for forName(). But later the classpath and classloader was replaced and the scanner was called again. This onescanned classpath again, and found a new instance of the FactoryClass (the new one that should be used). Because this one was already in the forName cache, it did not replace that one. In the meantime, the old classloader was closed with Java 7's URLClassLoacer.close() method. Because of this a call to forName returned the factory class, but the dependend classes it was referring to are no longer loadable (classloader closed). This causes the bug. The fix is not easily possible, I will think about it.
          Hide
          Shawn Heisey added a comment - - edited

          I closed SOLR-7771 as a duplicate of this issue.

          I'm attempting to get Solr 5.2.1 installed into my dev environment with the config from my Solr 4.9 install. I have all the extra jars in the lib directory under my solr home.

          By updating schema.xml to replace the solr.ICU* class names with the fully qualified versions, I was able to get Solr to start properly.

          I'm using another custom analysis component recompiled with 5.2.1 jars:

          https://github.com/solrmarc/CJKFoldingFilter/releases

          This component works just fine with "solr.CJKFoldingFilter" in the class parameter.

          Show
          Shawn Heisey added a comment - - edited I closed SOLR-7771 as a duplicate of this issue. I'm attempting to get Solr 5.2.1 installed into my dev environment with the config from my Solr 4.9 install. I have all the extra jars in the lib directory under my solr home. By updating schema.xml to replace the solr.ICU* class names with the fully qualified versions, I was able to get Solr to start properly. I'm using another custom analysis component recompiled with 5.2.1 jars: https://github.com/solrmarc/CJKFoldingFilter/releases This component works just fine with "solr.CJKFoldingFilter" in the class parameter.
          Hide
          Shawn Heisey added a comment -

          Usually when there's a strange problem related to the classloader, it's Lucene's ICU analysis jars that show the problem. Perhaps there's something strange going on in the ICU jars and this should be moved to the LUCENE project?

          Show
          Shawn Heisey added a comment - Usually when there's a strange problem related to the classloader, it's Lucene's ICU analysis jars that show the problem. Perhaps there's something strange going on in the ICU jars and this should be moved to the LUCENE project?
          Hide
          Shawn Heisey added a comment -

          On 4.2.1, 4.3.0, 4.6.1, 4.7.2, and 4.9.1 (the only 4.x versions I have tested), the workaround I mentioned in SOLR-4852 (putting all jars in solr_home/lib) works with the "solr." prefix on ICU analysis components. On 5.2.1, it doesn't, and full class names are required. All other typical classes are working with the "solr." prefix except the ICU components.

          Show
          Shawn Heisey added a comment - On 4.2.1, 4.3.0, 4.6.1, 4.7.2, and 4.9.1 (the only 4.x versions I have tested), the workaround I mentioned in SOLR-4852 (putting all jars in solr_home/lib) works with the "solr." prefix on ICU analysis components. On 5.2.1, it doesn't, and full class names are required. All other typical classes are working with the "solr." prefix except the ICU components.
          Hide
          Shawn Heisey added a comment - - edited

          I was helping someone with a class cast exception problem on the mailing list, and noticed that the log for 5.3.0 also says that it is loading jars in solrhome/lib twice, just like I noticed in the 5.2.1 log. SOLR-4852 appeared to be triggered by Solr loading twice from that location. At that time I never tried using the fully qualified ICU class names in schema.xml, but I suspect that it would have worked then.

          I think that the root of this problem is that Solr is loading jars from that lib directory twice. In SOLR-7771 (specifically in 5.2.1) I noticed that this doesn't cause problems with other jars in that directory, just ICU analysis. This may indicate that this is a bug that specifically affects ICU jars. The way that Solr's classloader and/or the "solr." prefix mechanism works is apparently not with the way that the ICU jars work when they register themselves, unless the classloader only loads them once. I do not know if the fault is in Solr or the ICU jars, but because other jars work correctly even when loaded twice, I am suspecting that it is the latter.

          Show
          Shawn Heisey added a comment - - edited I was helping someone with a class cast exception problem on the mailing list, and noticed that the log for 5.3.0 also says that it is loading jars in solrhome/lib twice, just like I noticed in the 5.2.1 log. SOLR-4852 appeared to be triggered by Solr loading twice from that location. At that time I never tried using the fully qualified ICU class names in schema.xml, but I suspect that it would have worked then. I think that the root of this problem is that Solr is loading jars from that lib directory twice. In SOLR-7771 (specifically in 5.2.1) I noticed that this doesn't cause problems with other jars in that directory, just ICU analysis. This may indicate that this is a bug that specifically affects ICU jars. The way that Solr's classloader and/or the "solr." prefix mechanism works is apparently not with the way that the ICU jars work when they register themselves, unless the classloader only loads them once. I do not know if the fault is in Solr or the ICU jars, but because other jars work correctly even when loaded twice, I am suspecting that it is the latter.
          Hide
          Shawn Heisey added a comment -

          Even though I am suspecting a problem in the ICU jars, there is a problem in Solr. It should only be loading solrhome/lib contents once. IMHO fixing that so it only happens once should be the focus of this issue. I am considering opening a LUCENE issue to investigate whether the ICU jars have something that needs to be fixed, but I will only do that after some discussion.

          I had created a patch for SOLR-4852 which adds duplicate resource URL checking to the classloader, and also refused to replace the classloader if nothing new was loaded. I think I may have done it wrong, but the idea seems sound.

          Show
          Shawn Heisey added a comment - Even though I am suspecting a problem in the ICU jars, there is a problem in Solr. It should only be loading solrhome/lib contents once. IMHO fixing that so it only happens once should be the focus of this issue. I am considering opening a LUCENE issue to investigate whether the ICU jars have something that needs to be fixed, but I will only do that after some discussion. I had created a patch for SOLR-4852 which adds duplicate resource URL checking to the classloader, and also refused to replace the classloader if nothing new was loaded. I think I may have done it wrong, but the idea seems sound.
          Hide
          Shawn Heisey added a comment - - edited

          One final update: I wonder if the class cast exception in the dataimport jar might be caused by loading it twice. I did not have this problem with 5.2.1, and it did load those jars twice, but the user with that problem is running 5.3.0.

          Show
          Shawn Heisey added a comment - - edited One final update: I wonder if the class cast exception in the dataimport jar might be caused by loading it twice. I did not have this problem with 5.2.1, and it did load those jars twice, but the user with that problem is running 5.3.0.
          Hide
          Shawn Heisey added a comment -

          I figured out why it loads solrhome/lib twice.

          Looking at current branch_5x code, line 143 in SolrResourceLoader.java does this:

              addToClassLoader("./lib/", null, true);
          

          At the same time, the sharedLibDirectory field in the NodeConfig class defaults to "lib" (set in the NodeConfigBuilder class), and CoreContainer#load() looks like this:

            /**
             * Load the cores defined for this CoreContainer
             */
            public void load()  {
              log.info("Loading cores into CoreContainer [instanceDir={}]", loader.getInstanceDir());
          
              // add the sharedLib to the shared resource loader before initializing cfg based plugins
              String libDir = cfg.getSharedLibDirectory();
              if (libDir != null) {
                File f = FileUtils.resolvePath(new File(solrHome), libDir);
                log.info("loading shared library: " + f.getAbsolutePath());
                loader.addToClassLoader(libDir, null, false);
                loader.reloadLuceneSPI();
              }
          

          Which of these should we keep? My bias (chosen without really thinking about any possible deeper implications) is to remove the one line from SolrResourceLoader.java. This would cause it to only use sharedLib, which the user should be able to override in solr.xml.

          Show
          Shawn Heisey added a comment - I figured out why it loads solrhome/lib twice. Looking at current branch_5x code, line 143 in SolrResourceLoader.java does this: addToClassLoader( "./lib/" , null , true ); At the same time, the sharedLibDirectory field in the NodeConfig class defaults to "lib" (set in the NodeConfigBuilder class), and CoreContainer#load() looks like this: /** * Load the cores defined for this CoreContainer */ public void load() { log.info( "Loading cores into CoreContainer [instanceDir={}]" , loader.getInstanceDir()); // add the sharedLib to the shared resource loader before initializing cfg based plugins String libDir = cfg.getSharedLibDirectory(); if (libDir != null ) { File f = FileUtils.resolvePath( new File(solrHome), libDir); log.info( "loading shared library: " + f.getAbsolutePath()); loader.addToClassLoader(libDir, null , false ); loader.reloadLuceneSPI(); } Which of these should we keep? My bias (chosen without really thinking about any possible deeper implications) is to remove the one line from SolrResourceLoader.java. This would cause it to only use sharedLib, which the user should be able to override in solr.xml.
          Hide
          Shawn Heisey added a comment - - edited

          The patch I just attached fixes the problem. A Solr 5.2.1 install was throwing errors for ICU jars, then I removed those two lines from the 5.2.1 source, built the server, and replaced the solr.war with the one I just built. Everything worked perfectly.

          Show
          Shawn Heisey added a comment - - edited The patch I just attached fixes the problem. A Solr 5.2.1 install was throwing errors for ICU jars, then I removed those two lines from the 5.2.1 source, built the server, and replaced the solr.war with the one I just built. Everything worked perfectly.
          Hide
          ASF subversion and git services added a comment -

          Commit 1701999 from Shawn Heisey in branch 'dev/trunk'
          [ https://svn.apache.org/r1701999 ]

          SOLR-6188: Only load jars in default sharedLib once.

          Show
          ASF subversion and git services added a comment - Commit 1701999 from Shawn Heisey in branch 'dev/trunk' [ https://svn.apache.org/r1701999 ] SOLR-6188 : Only load jars in default sharedLib once.
          Hide
          ASF subversion and git services added a comment -

          Commit 1702006 from Shawn Heisey in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1702006 ]

          SOLR-6188: Only load jars in default sharedLib once. (backport trunk r1701999)

          Show
          ASF subversion and git services added a comment - Commit 1702006 from Shawn Heisey in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1702006 ] SOLR-6188 : Only load jars in default sharedLib once. (backport trunk r1701999)
          Hide
          ASF subversion and git services added a comment -

          Commit 1702007 from Shawn Heisey in branch 'dev/branches/lucene_solr_5_3'
          [ https://svn.apache.org/r1702007 ]

          SOLR-6188: Only load jars in default sharedLib once. (backport trunk r1701999)

          Show
          ASF subversion and git services added a comment - Commit 1702007 from Shawn Heisey in branch 'dev/branches/lucene_solr_5_3' [ https://svn.apache.org/r1702007 ] SOLR-6188 : Only load jars in default sharedLib once. (backport trunk r1701999)
          Hide
          Shawn Heisey added a comment -

          Precommit passed on trunk and 5x.

          Show
          Shawn Heisey added a comment - Precommit passed on trunk and 5x.
          Hide
          Shawn Heisey added a comment -

          There are jenkins failures. Looking at them, I am not sure how removing an extra load of "./lib" (the default sharedLib) can cause a failure to find a file in the core lib directory.

          Show
          Shawn Heisey added a comment - There are jenkins failures. Looking at them, I am not sure how removing an extra load of "./lib" (the default sharedLib) can cause a failure to find a file in the core lib directory.
          Hide
          Shawn Heisey added a comment -

          I will revert the commit and figure out what to do about the failures, try again for 5.4 when I've got it.

          Show
          Shawn Heisey added a comment - I will revert the commit and figure out what to do about the failures, try again for 5.4 when I've got it.
          Hide
          Shawn Heisey added a comment -

          I tracked down what's happening with the first failure, in ResourceLoaderTest, line 200. This test relies on the SolrResourceLoader explicitly loading the lib directory inside any directory given, which is what I just removed.

          I think the removed lines are probably also how Solr loads core-level lib directories, which explains the other failure.

          Show
          Shawn Heisey added a comment - I tracked down what's happening with the first failure, in ResourceLoaderTest, line 200. This test relies on the SolrResourceLoader explicitly loading the lib directory inside any directory given, which is what I just removed. I think the removed lines are probably also how Solr loads core-level lib directories, which explains the other failure.
          Hide
          ASF subversion and git services added a comment -

          Commit 1702054 from Shawn Heisey in branch 'dev/branches/lucene_solr_5_3'
          [ https://svn.apache.org/r1702054 ]

          SOLR-6188: Revert r1702007 (backport of r1701999)

          Show
          ASF subversion and git services added a comment - Commit 1702054 from Shawn Heisey in branch 'dev/branches/lucene_solr_5_3' [ https://svn.apache.org/r1702054 ] SOLR-6188 : Revert r1702007 (backport of r1701999)
          Hide
          ASF subversion and git services added a comment -

          Commit 1702056 from Shawn Heisey in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1702056 ]

          SOLR-6188: Revert 1702006 (backport of r1701999)

          Show
          ASF subversion and git services added a comment - Commit 1702056 from Shawn Heisey in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1702056 ] SOLR-6188 : Revert 1702006 (backport of r1701999)
          Hide
          ASF subversion and git services added a comment -

          Commit 1702057 from Shawn Heisey in branch 'dev/trunk'
          [ https://svn.apache.org/r1702057 ]

          SOLR-6188: Revert r1701999

          Show
          ASF subversion and git services added a comment - Commit 1702057 from Shawn Heisey in branch 'dev/trunk' [ https://svn.apache.org/r1702057 ] SOLR-6188 : Revert r1701999
          Hide
          Shawn Heisey added a comment -

          I've concocted a new patch which I am attaching. I've been seeing a lot of test failures, but it's a different test failing every time, and the failures do not seem to be due to this patch, but I can't be 100% certain.

          Show
          Shawn Heisey added a comment - I've concocted a new patch which I am attaching. I've been seeing a lot of test failures, but it's a different test failing every time, and the failures do not seem to be due to this patch, but I can't be 100% certain.
          Hide
          Shawn Heisey added a comment -

          When I was getting the test failures, I was on a Windows 7 machine. I tried running on Linux and they all passed.

          After that, I built the server and copied the DIH jar to server/solr/lib and started it. This produces the following log snippet:

          2015-09-17 07:27:47.392 INFO  (main) [   ] o.a.s.c.SolrResourceLoader using system property solr.solr.home: /home/elyograg/asf/branch_5x/solr/server/solr
          2015-09-17 07:27:47.392 INFO  (main) [   ] o.a.s.c.SolrResourceLoader Skipping resource load from lib directory in /home/elyograg/asf/branch_5x/solr/server/solr/.  It is either null or the solr home.  The lib directory in the solr home i
          s handled via the default sharedLib.
          2015-09-17 07:27:47.399 INFO  (main) [   ] o.a.s.c.SolrXmlConfig Loading container configuration from /home/elyograg/asf/branch_5x/solr/server/solr/solr.xml
          2015-09-17 07:27:47.496 INFO  (main) [   ] o.a.s.c.CoresLocator Config-defined core root directory: /home/elyograg/asf/branch_5x/solr/server/solr
          2015-09-17 07:27:47.523 INFO  (main) [   ] o.a.s.c.CoreContainer New CoreContainer 1634132079
          2015-09-17 07:27:47.523 INFO  (main) [   ] o.a.s.c.CoreContainer Loading cores into CoreContainer [instanceDir=/home/elyograg/asf/branch_5x/solr/server/solr/]
          2015-09-17 07:27:47.524 INFO  (main) [   ] o.a.s.c.CoreContainer loading shared library: /home/elyograg/asf/branch_5x/solr/server/solr/lib
          2015-09-17 07:27:47.524 INFO  (main) [   ] o.a.s.c.SolrResourceLoader Adding 'file:/home/elyograg/asf/branch_5x/solr/server/solr/lib/solr-dataimporthandler-5.4.0-SNAPSHOT.jar' to classloader
          

          It skips the initial load and then picks up the jar I added via sharedLib.

          Would anyone like to sanity-check the patch? There might be a better solution, but this one does work.

          Show
          Shawn Heisey added a comment - When I was getting the test failures, I was on a Windows 7 machine. I tried running on Linux and they all passed. After that, I built the server and copied the DIH jar to server/solr/lib and started it. This produces the following log snippet: 2015-09-17 07:27:47.392 INFO (main) [ ] o.a.s.c.SolrResourceLoader using system property solr.solr.home: /home/elyograg/asf/branch_5x/solr/server/solr 2015-09-17 07:27:47.392 INFO (main) [ ] o.a.s.c.SolrResourceLoader Skipping resource load from lib directory in /home/elyograg/asf/branch_5x/solr/server/solr/. It is either null or the solr home. The lib directory in the solr home i s handled via the default sharedLib. 2015-09-17 07:27:47.399 INFO (main) [ ] o.a.s.c.SolrXmlConfig Loading container configuration from /home/elyograg/asf/branch_5x/solr/server/solr/solr.xml 2015-09-17 07:27:47.496 INFO (main) [ ] o.a.s.c.CoresLocator Config-defined core root directory: /home/elyograg/asf/branch_5x/solr/server/solr 2015-09-17 07:27:47.523 INFO (main) [ ] o.a.s.c.CoreContainer New CoreContainer 1634132079 2015-09-17 07:27:47.523 INFO (main) [ ] o.a.s.c.CoreContainer Loading cores into CoreContainer [instanceDir=/home/elyograg/asf/branch_5x/solr/server/solr/] 2015-09-17 07:27:47.524 INFO (main) [ ] o.a.s.c.CoreContainer loading shared library: /home/elyograg/asf/branch_5x/solr/server/solr/lib 2015-09-17 07:27:47.524 INFO (main) [ ] o.a.s.c.SolrResourceLoader Adding 'file:/home/elyograg/asf/branch_5x/solr/server/solr/lib/solr-dataimporthandler-5.4.0-SNAPSHOT.jar' to classloader It skips the initial load and then picks up the jar I added via sharedLib. Would anyone like to sanity-check the patch? There might be a better solution, but this one does work.
          Hide
          Shawn Heisey added a comment -

          New patch with CHANGES.txt update.

          The logged message is better, and the code now takes advantage of the null check that's already present, instead of doing it again.

          Show
          Shawn Heisey added a comment - New patch with CHANGES.txt update. The logged message is better, and the code now takes advantage of the null check that's already present, instead of doing it again.
          Hide
          Shawn Heisey added a comment -

          Miniscule change to the patch. Removes one space from the logged message.

          Show
          Shawn Heisey added a comment - Miniscule change to the patch. Removes one space from the logged message.
          Hide
          Shawn Heisey added a comment -

          Found a more serious problem in the patch this time. The logged message was missing required spaces in the concatenated strings.

          Show
          Shawn Heisey added a comment - Found a more serious problem in the patch this time. The logged message was missing required spaces in the concatenated strings.
          Hide
          Shawn Heisey added a comment -

          The only thing to say about this log message is that it will be logged every time Solr starts up. I wonder if it's too verbose.

          Show
          Shawn Heisey added a comment - The only thing to say about this log message is that it will be logged every time Solr starts up. I wonder if it's too verbose.
          Hide
          Shawn Heisey added a comment -

          Having thought about this while driving to work, I wonder if a message even needs to be logged. It will only skip when the requested directory is the solr home, and then it will use whatever is in sharedLib, which defaults to "lib".

          Show
          Shawn Heisey added a comment - Having thought about this while driving to work, I wonder if a message even needs to be logged. It will only skip when the requested directory is the solr home, and then it will use whatever is in sharedLib, which defaults to "lib".
          Hide
          Shawn Heisey added a comment -

          New patch with a shorter message. Will still be logged on every startup. If consensus is that we don't need a message, I can remove it.

          Show
          Shawn Heisey added a comment - New patch with a shorter message. Will still be logged on every startup. If consensus is that we don't need a message, I can remove it.
          Hide
          Shawn Heisey added a comment -

          Another new patch. This time, I removed the log message and added a verbose comment. Also explicitly included the class name on my usage of locateSolrHome(). After consideration, that seemed like the right way to go.

          Show
          Shawn Heisey added a comment - Another new patch. This time, I removed the log message and added a verbose comment. Also explicitly included the class name on my usage of locateSolrHome(). After consideration, that seemed like the right way to go.
          Hide
          Shawn Heisey added a comment -

          Precommit passed on trunk. I am getting solr test failures, so I'm running the tests multiple times to try and determine whether the failures are due to this patch.

          Show
          Shawn Heisey added a comment - Precommit passed on trunk. I am getting solr test failures, so I'm running the tests multiple times to try and determine whether the failures are due to this patch.
          Hide
          Shawn Heisey added a comment -

          The only test that repeatedly failed was this:

             [junit4]   2> NOTE: reproduce with: ant test  -Dtestcase=SolrCloudExampleTest -Dtests.method=testLoadDocsIntoGettingStartedCollection -Dtests.seed=3F1C68B923D2CA4C -Dtests.slow=true -Dtests.locale=ar_KW -Dtests.timezone=CET -Dtests.asserts=true -Dtests.file.encoding=UTF-8
             [junit4] FAILURE 45.1s J0 | SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<<
             [junit4]    > Throwable #1: java.lang.AssertionError: Delete action failed!
             [junit4]    >        at __randomizedtesting.SeedInfo.seed([3F1C68B923D2CA4C:2C7F5AD612BD73EA]:0)
             [junit4]    >        at org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169)
             [junit4]    >        at org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145)
             [junit4]    >        at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963)
             [junit4]    >        at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938)
             [junit4]    >        at java.lang.Thread.run(Thread.java:745)
          

          Looking at this test, I do not think it can be affected by my patch. I will commit this to trunk and let Jenkins pound on it for a little while.

          Show
          Shawn Heisey added a comment - The only test that repeatedly failed was this: [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=SolrCloudExampleTest -Dtests.method=testLoadDocsIntoGettingStartedCollection -Dtests.seed=3F1C68B923D2CA4C -Dtests.slow=true -Dtests.locale=ar_KW -Dtests.timezone=CET -Dtests.asserts=true -Dtests.file.encoding=UTF-8 [junit4] FAILURE 45.1s J0 | SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection <<< [junit4] > Throwable #1: java.lang.AssertionError: Delete action failed! [junit4] > at __randomizedtesting.SeedInfo.seed([3F1C68B923D2CA4C:2C7F5AD612BD73EA]:0) [junit4] > at org.apache.solr.cloud.SolrCloudExampleTest.doTestDeleteAction(SolrCloudExampleTest.java:169) [junit4] > at org.apache.solr.cloud.SolrCloudExampleTest.testLoadDocsIntoGettingStartedCollection(SolrCloudExampleTest.java:145) [junit4] > at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsFixedStatement.callStatement(BaseDistributedSearchTestCase.java:963) [junit4] > at org.apache.solr.BaseDistributedSearchTestCase$ShardsRepeatRule$ShardsStatement.evaluate(BaseDistributedSearchTestCase.java:938) [junit4] > at java.lang.Thread.run(Thread.java:745) Looking at this test, I do not think it can be affected by my patch. I will commit this to trunk and let Jenkins pound on it for a little while.
          Hide
          ASF subversion and git services added a comment -

          Commit 1707630 from Shawn Heisey in branch 'dev/trunk'
          [ https://svn.apache.org/r1707630 ]

          SOLR-6188: Only load resources in SOLRHOME/lib once.

          Show
          ASF subversion and git services added a comment - Commit 1707630 from Shawn Heisey in branch 'dev/trunk' [ https://svn.apache.org/r1707630 ] SOLR-6188 : Only load resources in SOLRHOME/lib once.
          Hide
          Shawn Heisey added a comment -

          I was sent four direct messages from Policeman Jenkins. The failures did not look like they were caused by my commit, and one of them was the failure that I described above. I would appreciate a review before I backport to 5x.

          Show
          Shawn Heisey added a comment - I was sent four direct messages from Policeman Jenkins. The failures did not look like they were caused by my commit, and one of them was the failure that I described above. I would appreciate a review before I backport to 5x.
          Hide
          Steve Rowe added a comment -

          +1, LGTM, I don't know a lot about classloaders, but AFAICT this works around the bug Uwe describes above.

          Show
          Steve Rowe added a comment - +1, LGTM, I don't know a lot about classloaders, but AFAICT this works around the bug Uwe describes above .
          Hide
          ASF subversion and git services added a comment -

          Commit 1707800 from Shawn Heisey in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1707800 ]

          SOLR-6188: Only load resources in SOLRHOME/lib once. (backport trunk r1707630)
          Also indirectly incorporates r1707771 - fixing my error in CHANGES.txt.

          Show
          ASF subversion and git services added a comment - Commit 1707800 from Shawn Heisey in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1707800 ] SOLR-6188 : Only load resources in SOLRHOME/lib once. (backport trunk r1707630) Also indirectly incorporates r1707771 - fixing my error in CHANGES.txt.
          Hide
          Shawn Heisey added a comment -

          Precommit passed on 5x. The only solr test failure (which repeated through two runs) did not look related to the patch.

          Show
          Shawn Heisey added a comment - Precommit passed on 5x. The only solr test failure (which repeated through two runs) did not look related to the patch.

            People

            • Assignee:
              Shawn Heisey
              Reporter:
              Ahmet Arslan
            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development