Thanks you very much for responding Shawn. I never use IE, I use firefox.
These are brand new servers and I don't think I am mixing versions. What
made you think I was using the 1.4.1 ?? You are correct in saying that the
server is throwing HTML response since a group query has been failing with
SEVERE error following which the entire instance behaves weirdly until we
restart.
Its surprising that group query error handling has such glaring issue. 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 . Looks like the searcher goes for a
spin once it encounters the exception. Such situation should have been
gracefully handled
[#|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 |#]
Ravi Kiran Bhaskar
On Fri, Apr 19, 2013 at 5:40 PM, Shawn Heisey <s...@elyograg.org> wrote:
> On 4/19/2013 12:55 PM, Ravi Solr wrote:
>
>> We are using Solr 3.6.2 single core ( both index and query on same
>> machine)
>> and randomly the server fails to query correctly. If we query from the
>> admin console the query is not even applied and it returns numFound count
>> equal to total docs in the index as if no query is made, and if use SOLRJ
>> to query it throws javabin error
>>
>> Invalid version (expected 2, but 60) or the data in not in 'javabin'
>> format
>>
>
> The UI problem is likely a browser issue, but I could be wrong. Some
> browsers, IE in particular, but not limited to that one, have problems with
> the admin UI. Using a different browser or clearing the browser cache can
> sometimes fix those problems.
>
> As for SolrJ, are you using a really old (1.x) SolrJ with Solr 3.6.2? Have
> you ever had Solr 1.x running on the same machine that's now running 3.6.2?
>
> Because the javabin version changed between 1.4.1 and 3.1.0, SolrJ 1.x is
> not compatible with Solr 3.1 and later unless you set the response parser
> on the server object to XML before you try to use it. If you have upgraded
> Solr from an old version, your servlet container (sun-appserver) may have
> some of the old jars remaining from the 1.x install. They must be removed.
>
> To change your SolrJ to use the XML response parser, use code like the
> following:
>
> server.setParser(new XMLResponseParser());
>
> When SolrJ and Solr are both version 3.x or 4.x, you can remove this line.
>
> Another way that you can get the javabin error is when Solr is returning
> an error response, or returning a response that is not an error but is an
> HTML response reporting an unusual circumstance rather than the usual
> javabin. These HTML responses should no longer exist in the newest
> versions of Solr. Do you see any errors or warnings in your server log?
> The server log line you included in your email is not an error.
>
> Thanks,
> Shawn
>
>
