Thanks for the background Uwe. Makes sense to me now.
Also, just want to thank everyone working on Solr & Lucene. It really is
fantastic at what it does.
Charlie
On 09/10/2014 18:39, Uwe Schindler wrote:
What happens is explained here:
<https://issues.apache.org/jira/browse/SOLR-6188?focusedCommentId=14039350&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14039350>
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
-----Original Message-----
From: Uwe Schindler [mailto:[email protected]]
Sent: Thursday, October 09, 2014 7:35 PM
To: [email protected]
Subject: RE: Moving to Java 7 on debian breaks ICU Normalizer2 on Solr 4.7.2
and Solr 4.10.1
Hi,
The reason why it works in Java 6 is because Java 6 does not support to close
a classloader on cleanup. In Java 7+, Classloader implements Closeable. The
bug is in Solr, because on replaceClassloader it closes the old classlaoder
(which is correct otherwise we get a resource leak!!), but this causes classes
aleady load with the old classloader to no longer be able to load other classes
(because the classloader was closed earlier). In Java 6, we have a resource
leak, but it works.
The only fix is to refactor SolrResourceLoader to collect all lib dirs first and
only as very last step to create the classloader - and don't replace & close the
older classloaders. The classloaders should only be closed on shutdown.
Uwe
-----
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: [email protected]
-----Original Message-----
From: Charlie Orford [mailto:[email protected]]
Sent: Thursday, October 09, 2014 7:05 PM
To: [email protected]
Subject: Re: Moving to Java 7 on debian breaks ICU Normalizer2 on Solr
4.7.2 and Solr 4.10.1
Hi Sean
I've just read the comments on the bug you linked to in your earlier email.
All I can add is:
a). the documentation should be more clear that using the same
directory as both a top-level lib and a per core lib is not recommended.
b). in case it helps with tracking the eventual bug down, I had the
same problem with 4.10.1 on Java 7 as I did with 4.7.2 on Java 7 (i.e.
it was a java version issue rather than a solr version issue). The
only combination that worked (before I changed the shareLib path in
solr.xml to a non-existent dir) was Solr 4.7.2 on Java 6.
Charlie
On 09/10/2014 17:20, Charlie Orford wrote:
Thanks Shawn you're a genius! Changed the sharedLib path to a
non-existent directory and Solr is now happily running on Java 7.
Is this a bug with Solr or was I doing it wrong? My solr.xml looked
like this before:
<?xml version="1.0" encoding="UTF-8" ?>
<!--
All (relative) paths are relative to the installation path
persistent: Save changes made via the API to this file
sharedLib: path to a lib directory that will be shared across all
cores (optional)
-->
<solr>
<str name="coreRootDirectory">/srv/solr/4.7</str>
<str name="sharedLib">lib</str>
<int name="coreLoadThreads">4</int> </solr>
Replacing "lib" with "li2b" (which doesn't exist) solved the problem.
Here's the log: http://hastebin.com/hucikamora.avrasm (the jars
under lib/ are still being loaded but only the once now).
Charlie
On 09/10/2014 16:49, Shawn Heisey wrote:
On 10/9/2014 5:57 AM, Charlie Orford wrote:
Here are the startup logs from Solr (first one shows running under
Java 6 and working, second one is the very same installation
runing under Java 7 and failing):
http://hastebin.com/yapuqonide.vhdl
http://hastebin.com/edigeduset.pas
This looks like the problem I described here:
https://issues.apache.org/jira/browse/SOLR-4852
I see that your jars are loaded twice, which seems to be the root
of the problem. I never tried this under Java 6, I had already
upgraded to Java 7 by then. I bet if you remove the sharedLib
setting from solr.xml, it'll start working correctly.
Thanks,
Shawn
-------------------------------------------------------------------
-- To unsubscribe, e-mail: [email protected] For
additional commands, e-mail: [email protected]
--------------------------------------------------------------------
- To unsubscribe, e-mail: [email protected] For
additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For
additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional
commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
