You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by yriveiro <ya...@gmail.com> on 2013/04/23 01:57:01 UTC
Too many close, count -1
Hi,
Reviewing the solr's log I found this message.
The solr version is 4.2.1, running in a tomcat 7
4973652:SEVERE: Too many close [count:-1] on
org.apache.solr.core.SolrCore@5795a627. Please report this exception to
solr-user@lucene.apache.org
5003386:SEVERE: REFCOUNT ERROR: unreferenced
org.apache.solr.core.SolrCore@5795a627 (XXXX) has a reference count of -1
2965529:SEVERE: Too many close [count:-1] on
org.apache.solr.core.SolrCore@7722b49b. Please report this exception to
solr-user@lucene.apache.org
52965531:SEVERE: Too many close [count:-1] on
org.apache.solr.core.SolrCore@32530662. Please report this exception to
solr-user@lucene.apache.org
52965533:SEVERE: Too many close [count:-1] on
org.apache.solr.core.SolrCore@144e2972. Please report this exception to
solr-user@lucene.apache.org
52971283:SEVERE: Too many close [count:-1] on
org.apache.solr.core.SolrCore@1705c88e. Please report this exception to
solr-user@lucene.apache.org
52978567:SEVERE: Too many close [count:-1] on
org.apache.solr.core.SolrCore@c200c62. Please report this exception to
solr-user@lucene.apache.org
-----
Best regards
--
View this message in context: http://lucene.472066.n3.nabble.com/Too-many-close-count-1-tp4058129.html
Sent from the Solr - User mailing list archive at Nabble.com.
Re: Too many close, count -1
Posted by Erick Erickson <er...@gmail.com>.
One outside possibility (and 4.3 should refuse to start if this is the
case). Is it possible that more than one of your cores has the same
name?
FWIW,
Erick
On Tue, Apr 23, 2013 at 5:30 PM, Chris Hostetter
<ho...@fucit.org> wrote:
>
> : Subject: Re: Too many close, count -1
>
> Thanks for the details, nothing jumps out at me, but we're now tracking
> this in SOLR-4753...
>
> https://issues.apache.org/jira/browse/SOLR-4753
>
> -Hoss
Re: Too many close, count -1
Posted by Chris Hostetter <ho...@fucit.org>.
: Subject: Re: Too many close, count -1
Thanks for the details, nothing jumps out at me, but we're now tracking
this in SOLR-4753...
https://issues.apache.org/jira/browse/SOLR-4753
-Hoss
Re: Too many close, count -1
Posted by Yago Riveiro <ya...@gmail.com>.
Hoss,
I use solr as a SolrCluster, the main feature that I use is faceting to do some analytics and normal queries to do free text search and retrieve data using filters.
I don't use any custom plugin or contribute plugin.
At the moment I'm importing my data from mysql to solr, I don't use dih, instead I use a custom mechanism. In this import, I don't do hard or soft commits, I relay this responsibility to solr.
I don't know if this info is useful but I have a lot of: WARNING: [XXX] PERFORMANCE WARNING: Overlapping onDeckSearchers=2
The cluster is formed by a thousand of collection, I have a collection for each client.
My solrconfig:
<config>
<luceneMatchVersion>LUCENE_40</luceneMatchVersion>
<directoryFactory name="DirectoryFactory" class="${solr.directoryFactory:solr.StandardDirectoryFactory}"/>
<indexConfig>
<ramBufferSizeMB>256</ramBufferSizeMB>
<mergeFactor>20</mergeFactor>
<mergeScheduler class="org.apache.lucene.index.ConcurrentMergeScheduler"/>
<lockType>native</lockType>
<!-- Commit Deletion Policy
Custom deletion policies can be specified here. The class must
implement org.apache.lucene.index.IndexDeletionPolicy.
http://lucene.apache.org/java/3_5_0/api/core/org/apache/lucene/index/IndexDeletionPolicy.html
The default Solr IndexDeletionPolicy implementation supports
deleting index commit points on number of commits, age of
commit point and optimized status.
The latest commit point should always be preserved regardless
of the criteria.
-->
<!--
<deletionPolicy class="solr.SolrDeletionPolicy">
-->
<!-- The number of commit points to be kept -->
<!-- <str name="maxCommitsToKeep">1</str> -->
<!-- The number of optimized commit points to be kept -->
<!-- <str name="maxOptimizedCommitsToKeep">0</str> -->
<!--
Delete all commit points once they have reached the given age.
Supports DateMathParser syntax e.g.
-->
<!--
<str name="maxCommitAge">30MINUTES</str>
-->
<str name="maxCommitAge">60MINUTES</str>
<!--
</deletionPolicy>
-->
<!-- Lucene Infostream
To aid in advanced debugging, Lucene provides an "InfoStream"
of detailed information when indexing.
Setting The value to true will instruct the underlying Lucene
IndexWriter to write its debugging info the specified file
-->
<!-- <infoStream file="INFOSTREAM.txt">false</infoStream> -->
</indexConfig>
<query>
<!-- If true, stored fields that are not requested will be loaded lazily.
This can result in a significant speed improvement if the usual case is to
not load all stored fields, especially if the skipped fields are large compressed
text fields.
-->
<enableLazyFieldLoading>true</enableLazyFieldLoading>
<queryResultWindowSize>1000</queryResultWindowSize>
<queryResultMaxDocsCached>3000</queryResultMaxDocsCached>
<maxWarmingSearchers>2</maxWarmingSearchers>
<useFilterForSortedQuery>true</useFilterForSortedQuery>
<filterCache
class="solr.FastLRUCache"
size="2000"
initialSize="1500"
autowarmCount="750"
cleanupThread="true"/>
<queryResultCache
class="solr.FastLRUCache"
size="2000"
initialSize="1500"
autowarmCount="750"
cleanupThread="true"/>
<documentCache
class="solr.FastLRUCache"
size="20000"
initialSize="10000"
autowarmCount="0"
cleanupThread="true"/>
</query>
<updateHandler class="solr.DirectUpdateHandler2">
<updateLog>
<str name="dir">${solr.data.dir:}</str>
</updateLog>
<!-- Commit documents definitions -->
<autoCommit>
<maxDocs>5000</maxDocs>
<maxTime>10000</maxTime>
</autoCommit>
<autoSoftCommit>
<maxTime>2500</maxTime>
</autoSoftCommit>
<maxPendingDeletes>20000</maxPendingDeletes>
</updateHandler>
<requestDispatcher handleSelect="false">
<requestParsers enableRemoteStreaming="true" multipartUploadLimitInKB="10485760"/>
</requestDispatcher>
<requestHandler name="/select" class="solr.SearchHandler"/>
<!-- request handler that returns indented JSON by default -->
<requestHandler name="/query" class="solr.SearchHandler">
<lst name="defaults">
<str name="echoParams">explicit</str>
<str name="wt">json</str>
<str name="indent">true</str>
<str name="df">text</str>
</lst>
</requestHandler>
<!-- realtime get handler, guaranteed to return the latest stored fields of
any document, without the need to commit or open a new searcher. The
current implementation relies on the updateLog feature being enabled. -->
<requestHandler name="/get" class="solr.RealTimeGetHandler">
<lst name="defaults">
<str name="omitHeader">true</str>
<str name="wt">json</str>
<str name="indent">false</str>
</lst>
</requestHandler>
<requestHandler name="/admin/" class="solr.admin.AdminHandlers" />
<requestHandler name="standard" class="solr.StandardRequestHandler" default="true" />
<requestHandler name="/update" class="solr.UpdateRequestHandler" />
<requestHandler name="/analysis/field" startup="lazy" class="solr.solr.FieldAnalysisRequestHandler" />
<requestHandler name="/analysis/document" class="solr.DocumentAnalysisRequestHandler" startup="lazy" />
<requestHandler name="/replication" class="solr.ReplicationHandler" startup="lazy" />
<!-- Echo the request contents back to the client -->
<requestHandler name="/debug/dump" class="solr.DumpRequestHandler" >
<lst name="defaults">
<str name="echoParams">explicit</str> <!-- for all params (including the default etc) use: 'all' -->
<str name="echoHandler">true</str>
</lst>
</requestHandler>
<requestHandler name="/admin/ping" class="solr.PingRequestHandler">
<lst name="invariants">
<str name="q">rows=0;start=0;omitHeader=true</str>
</lst>
<lst name="defaults">
<str name="echoParams">NONE</str>
</lst>
</requestHandler>
<!-- config for the admin interface -->
<admin>
<defaultQuery>id:*</defaultQuery>
</admin>
</config>
Cumprimentos
--
Yago Riveiro
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)
On Tuesday, April 23, 2013 at 3:13 AM, Chris Hostetter wrote:
>
> : Can you tell what operations cause this to happen?
>
> ie: what does your configuration look like? are you using any custom
> plugins? what types of features of solr do you use (faceting, grouping,
> highlighting, clustering, dih, etc...) ?
>
>
> -Hoss
Re: Too many close, count -1
Posted by Chris Hostetter <ho...@fucit.org>.
: Can you tell what operations cause this to happen?
ie: what does your configuration look like? are you using any custom
plugins? what types of features of solr do you use (faceting, grouping,
highlighting, clustering, dih, etc...) ?
-Hoss
Re: Too many close, count -1
Posted by Yonik Seeley <yo...@lucidworks.com>.
Can you tell what operations cause this to happen?
I've added a comment to https://issues.apache.org/jira/browse/SOLR-4749
where we're looking at some related issues around CoreContainer, but
perhaps it should get it's own issue.
-Yonik
http://lucidworks.com
On Mon, Apr 22, 2013 at 7:57 PM, yriveiro <ya...@gmail.com> wrote:
> Hi,
>
> Reviewing the solr's log I found this message.
>
> The solr version is 4.2.1, running in a tomcat 7
>
> 4973652:SEVERE: Too many close [count:-1] on
> org.apache.solr.core.SolrCore@5795a627. Please report this exception to
> solr-user@lucene.apache.org
> 5003386:SEVERE: REFCOUNT ERROR: unreferenced
> org.apache.solr.core.SolrCore@5795a627 (XXXX) has a reference count of -1
>
> 2965529:SEVERE: Too many close [count:-1] on
> org.apache.solr.core.SolrCore@7722b49b. Please report this exception to
> solr-user@lucene.apache.org
> 52965531:SEVERE: Too many close [count:-1] on
> org.apache.solr.core.SolrCore@32530662. Please report this exception to
> solr-user@lucene.apache.org
> 52965533:SEVERE: Too many close [count:-1] on
> org.apache.solr.core.SolrCore@144e2972. Please report this exception to
> solr-user@lucene.apache.org
> 52971283:SEVERE: Too many close [count:-1] on
> org.apache.solr.core.SolrCore@1705c88e. Please report this exception to
> solr-user@lucene.apache.org
> 52978567:SEVERE: Too many close [count:-1] on
> org.apache.solr.core.SolrCore@c200c62. Please report this exception to
> solr-user@lucene.apache.org
>
>
>
> -----
> Best regards
> --
> View this message in context: http://lucene.472066.n3.nabble.com/Too-many-close-count-1-tp4058129.html
> Sent from the Solr - User mailing list archive at Nabble.com.