You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Ravi Kiran Bhaskar (JIRA)" <ji...@apache.org> on 2013/04/22 21:23:16 UTC
[jira] [Comment Edited] (SOLR-4743) Group query crashes server
[ https://issues.apache.org/jira/browse/SOLR-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13638352#comment-13638352 ]
Ravi Kiran Bhaskar edited comment on SOLR-4743 at 4/22/13 7:22 PM:
-------------------------------------------------------------------
Hoss: Thank you very much for promptly following up. You are correct that you can still query even after the exception happens, however, its a slowly degrades to being a vegetable. You will see in the logs that as time progresses the empty queries keep growing and finally we restart the glassfish, I must admit that I may be a bit more paranoid/zealous than usual about relating the exception with the empty queries, so take it with a grain of salt. :-)
Unfortunately since this is happening on production servers we had to restart immediately and hence we couldn't get the thread dumps. However I have attached the log file that show logs from sane to bust to restart of glassfish server. Look for the word 'JBI' to mark start or stop of glassfish. I have also attached the solrconfig.xml. Obviously I had to modify some paths and names in solrconfig and log to obfuscate important details as per my company's security policy.
was (Author: b_ravi_kiran):
Hoss: Thank you very much for promptly following up. You are correct that you can still query even after the exception happens, however, its a slowly degrades to being a vegetable. You will see in the logs that as time progresses the empty queries keep growing and finally we restart the glassfish.
Unfortunately since this is happening on production servers we had to restart immediately and hence we couldn't get the thread dumps. However I have attached the log file that show logs from sane to bust to restart of glassfish server. Look for the word 'JBI' to mark start or stop of glassfish. I have also attached the solrconfig.xml. Obviously I had to modify some paths and names in solrconfig and log to obfuscate important details as per my company's security policy.
> Group query crashes server
> --------------------------
>
> Key: SOLR-4743
> URL: https://issues.apache.org/jira/browse/SOLR-4743
> Project: Solr
> Issue Type: Bug
> Components: search
> Affects Versions: 3.6.2
> Environment: CentOS release 5.9, Sun GlassFish Enterprise Server v2.1.1 Patch15
> Reporter: Ravi Kiran Bhaskar
> Priority: Critical
> Attachments: server.log_2013-04-20T09-53-28, solrconf.xml
>
>
> If you specify group=true but don't specify group.query or group.field SOLR throws a SEVERE exception following which we see the empty queries and finally no responses via solrj and admin console gives numFound always equal to total number of docs in index (it's 21692 as shown below). Looks like the searcher goes for a spin once it encounters the exception. Such situation should have been gracefully handled
> EXCEPTION and QUERY
> --------------------
> [#|2013-04-19T23:47:53.363-0400|SEVERE|sun-appserver2.1.1|org.apache.solr.core.SolrCore|_ThreadID=26;_ThreadName=httpSSLWorkerThread-9001-17;_RequestID=2f
> 933642-cad0-40e5-86c6-65b00be9bb97;|org.apache.solr.common.SolrException: Specify at least one field, function or query to group by.
> at org.apache.solr.search.Grouping.execute(Grouping.java:228)
> at org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:372)
> at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
> at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
> at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:365)
> at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:260)
> at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:246)
> at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:214)
> at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:313)
> at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:287)
> at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:218)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
> at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:94)
> at com.sun.enterprise.web.PESessionLockingStandardPipeline.invoke(PESessionLockingStandardPipeline.java:98)
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:222)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:166)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:648)
> at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:593)
> at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:587)
> at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1093)
> at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:291)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:670)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:601)
> at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:875)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:365)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:285)
> at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:221)
> at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:269)
> at com.sun.enterprise.web.connector.grizzly.ssl.SSLWorkerThread.run(SSLWorkerThread.java:111)
> |#]
> [#|2013-04-19T23:47:53.365-0400|INFO|sun-appserver2.1.1|org.apache.solr.core.SolrCore|_ThreadID=26;_ThreadName=httpSSLWorkerThread-9001-17;|[core1] webapp=/solr path=/select params={q=astronomy\+&rows=10&start=0&facet=true&fq=source:"xxx.com"&fq=locations:("Maryland")&sort=score+desc&group=true} status=400 QTime=9 |#]
> EMPTY QUERY
> ------------
> [#|2013-04-20T17:35:50.933-0400|INFO|sun-appserver2.1.1|org.apache.solr.core.SolrCore|_ThreadID=26;_ThreadName=httpSSLWorkerThread-9001-6;|[core1] webapp=/solr path=/select params={} hits=21692 status=0 QTime=16 |#]
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org