lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Neal Ensor <>
Subject Re: "Classic" 4.2 master-slave replication not completing
Date Wed, 03 Jul 2013 15:29:46 GMT
Posted the solr config up as (hope that works).
 Note that this is largely a hold-over from upgrades of previous solr
versions, there may be lots of cruft left over.  If it's advisable to do
so, I would certainly be open to starting from scratch with a 4.3+ example

I will take up the logging portions you listed there, to see where I might
have missed a library or configuration point, thanks.

On Mon, Jul 1, 2013 at 4:04 PM, Shawn Heisey <> wrote:

> On 7/1/2013 1:07 PM, Neal Ensor wrote:
>> is it conceivable that there's too much traffic, causing Solr to stall
>> re-opening the searcher (thus releasing to the new index)?  I'm grasping
>> at
>> straws, and this is beginning to bug me a lot.  The traffic logs wouldn't
>> seem to support this (apart from periodic health-check pings, the load is
>> distributed fairly evenly across 3 slaves by a load-balancer tool).  After
>> 35+ minutes this morning, none of the three successfully "unstuck", and
>> had
>> to be manually core-reloaded.
>> Is there perhaps a configuration element I'm overlooking that might make
>> solr a bit less "friendly" about it, and just dump the searchers/reopen
>> when replication completes?
> Can you share your solrconfig.xml file, someplace like
>  Please be sure to choose the correct file type ... on that website it is
> (X)HTML for an XML file.
>  As a side note, I'm getting really frustrated with trying to get log4j
>> logging on 4.3.1 set up; my tomcat container persists in complaining that
>> it cannot find, when I've put it in the WEB-INF/classes
>> of
>> the war file, have SLF4j libraries AND log4j at the shared container "lib"
>> level, and log4j.debug turned on.  I can't find any excuses why it cannot
>> seem to locate the configuration.
> The wiki is still down for maintenance, so below is a relevant section of
> the SolrLogging wiki page extracted from Google Cache.  When it comes back
> up, you can find it at this URL:
> Log4J_back_to_JUL_.28java.**util.logging.29<>
> =====
> The example logging setup takes over the configuration of Solr logging,
> which prevents the container from controlling where logs go. Users of
> containers other than the included Jetty (Tomcat in particular) may be
> accustomed to doing the logging configuration in the container. If you want
> to switch back to java.util.logging so this is once again possible, here's
> what to do. These steps apply to the example/lib/ext directory in the Solr
> example, or to your container's lib directory as mentioned in the previous
> section. These steps also assume that the slf4j version is 1.6.6, which
> comes with Solr4.3. Newer versions may use a different slf4j version. As of
> May 2013, you can use a newer SLF4J version with no trouble, but be aware
> that all slf4j components in your classpath must be the same version.
>     Download slf4j version 1.6.6 (the version used in Solr4.3.x).
>     Unpack the slf4j archive.
>     Delete these JARs from your lib folder: slf4j-log4j12-1.6.6.jar,
> jul-to-slf4j-1.6.6.jar, log4j-1.2.16.jar
>     Add these JARs to your lib folder (from slf4j zip):
> slf4j-jdk14-1.6.6.jar, log4j-over-slf4j-1.6.6.jar
>     Use your old
> =====
> Thanks,
> Shawn

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message