[ 
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: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to