[
https://issues.apache.org/jira/browse/SOLR-3627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-3627:
---------------------------
Fix Version/s: (was: 3.6.1)
(was: 3.1)
Eugene: can you please retest with Solr 4.0.0-ALPHA, or at the very least 3.6.0?
This sounds exactly like SOLR-2462 which was fixed in Solr 3.3
> Memory leak when using spellchecker with long function query (fq)
> -----------------------------------------------------------------
>
> Key: SOLR-3627
> URL: https://issues.apache.org/jira/browse/SOLR-3627
> Project: Solr
> Issue Type: Bug
> Components: search, spellchecker
> Affects Versions: 3.1
> Environment: Windows 7
> Tomcat 6.0.26
> Solr 3.1
> Java options: -XX:PermSize=128m -XX:MaxPermSize=128m -Xms1024m -Xmx1024m
> Reporter: Eugene Viktorovich
> Priority: Critical
> Labels: performance
> Attachments: params.txt
>
>
> If spellcheck=true and request to Solr contains too long 'fq', memory is not
> cleaned, i.e. garbage collector can't clean memory. Fill rate of memory
> depends on the length of the fq.
> Example request:
> {code:xml}
> rows=10
> version=2.2
> spellcheck=true
> q=+((shortDesc_en:(hghg)))
> fq=(+contractIds:("contractId1" "contractId2" ... "contractId20000") AND
> +catalogIds:("catalogId1" "catalogId2" ... "catalogId20000"))
> {code}
> solrconfig.xml:
> {code:xml}
> ...
> <requestHandler name="standard" class="solr.SearchHandler" default="true">
> <!-- default values for query parameters -->
> <lst name="defaults">
> <str name="echoParams">explicit</str>
> <str name="spellcheck.onlyMorePopular">true</str>
>
> <str name="spellcheck.extendedResults">false</str>
> <str name="spellcheck.collate">true</str>
> <str name="spellcheck.collateExtendedResults">true</str>
>
> <str name="spellcheck.maxCollations">3</str>
>
> <str name="spellcheck.maxCollationTries">6</str>
>
> <str name="spellcheck.count">3</str>
> </lst>
> <arr name="last-components">
> <str>spellcheck</str>
> </arr>
> </requestHandler>
> ...
> {code}
> h6. If spellcheck.collate=false, issue is not reproduced.
> Preliminary research gave following result:
> When contractIds=~20000 and catalogIds=~20000, fill rate of memory is about
> 60 request.
> When contractIds=~10000 and catalogIds=~10000, fill rate of memory is about
> 90 request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
