custom writer, working but... a strange exception in logs
Hi all,
At first, lucene user for years, I should really thanks you for Solr.
For a start, I wrote a little results writer for an app. It works like
what I understand of Solr, except a strange exception I'm not able to
puzzle.
Version : fresh subversion.
1. Class
2. stacktrace
3. maybe ?
1. Class
public class HTMLResponseWriter implements QueryResponseWriter {
public static String CONTENT_TYPE_HTML_UTF8 = text/html; charset=UTF-8;
/** A custom HTML header configured from solrconfig.xml */
static String HEAD;
/** A custom HTML footer configured from solrconfig.xml */
static String FOOT;
/** get some snippets from conf */
public void init(NamedList n) {
String s=(String)n.get(head);
if (s != null !.equals(s)) HEAD = s;
s=(String)n.get(foot);
if (s != null !.equals(s)) FOOT = s;
}
public void write(Writer writer, SolrQueryRequest req,
SolrQueryResponse rsp)
throws IOException {
// cause the exception below
writer.write(HEAD);
/* loop on my results, working like it should */
// cause the exception below
writer.write(FOOT);
}
public String getContentType(SolrQueryRequest request,
SolrQueryResponse response) {
return CONTENT_TYPE_HTML_UTF8;
}
}
2. Stacktrace
=
GRAVE: org.apache.solr.core.SolrException: Missing required parameter: q
at
org.apache.solr.request.RequiredSolrParams.get(RequiredSolrParams.java:50)
at
org.apache.solr.request.StandardRequestHandler.handleRequestBody(StandardRequestHandler.java:72)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:77)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:658)
at org.apache.solr.servlet.SolrServlet.doGet(SolrServlet.java:66)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
...
3. Maybe ?
==
I can't figure why, but when writer.write(HEAD) is executed, I see code
from StandardRequestHandler executed 2 times in the debugger, first is
OK, second hasn't the q parameter. Displaying results is always OK.
Without such lines, there is only one call to StandardRequestHandler, no
exception in log, but no more head or foot. When HEAD and FOOT values
are hard coded and not configured, there's no exception. If HEAD and
FOOT are not static, problem is the same.
Is it a mistake in my code ? Every piece of advice welcome, and if I
touch a bug, be sure I will do my best to help.
--
Frédéric Glorieux
École nationale des chartes
direction des nouvelles technologies et de l'informatique
Re: custom writer, working but... a strange exception in logs
On 6/6/07, Frédéric Glorieux [EMAIL PROTECTED] wrote: I can't figure why, but when writer.write(HEAD) is executed, I see code from StandardRequestHandler executed 2 times in the debugger, first is OK, second hasn't the q parameter. I don't know why that would be... what is the client sending the request? If it gets an error, does it retry or something? Displaying results is always OK. Without such lines, there is only one call to StandardRequestHandler, no exception in log, but no more head or foot. When HEAD and FOOT values are hard coded and not configured, there's no exception. If HEAD and FOOT are not static, problem is the same. I don't see a non-null default for HEAD/FOOT... perhaps do if (HEAD!=null) writer.write(HEAD); There may be an issue with how you register in solrconfig.xml -Yonik
Re: custom writer, working but... a strange exception in logs
Thanks for answer, I'm feeling less guilty. I don't see a non-null default for HEAD/FOOT... perhaps do if (HEAD!=null) writer.write(HEAD); There may be an issue with how you register in solrconfig.xml I get every thing I want from solrconfig.xml, I was suspecting some classloader mystery. Following your advice from another post, I will write a specific request Handler, so it would be easier to trace the problem, with a very simple first solution, stop sending exception (to avoid gigabytes of logs). -- Frédéric Glorieux École nationale des chartes direction des nouvelles technologies et de l'informatique
Re: custom writer, working but... a strange exception in logs
I'm baffled. Would it be possible for you to send a scaled down (but compilable) version of your response writer that demonstrates the problem, along with a snippet that can be added to the example solrconfig.xml to register it and and example request URL that triggers the problem? that way we can all try ait and see if we can reproduce your results (for all we know, it may be an artifact of your debugger) -Hoss
SOLVED Re: custom writer, working but... a strange exception in logs
I'm baffled. [Yonic] I don't know why that would be... what is the client sending the request? If it gets an error, does it retry or something? Good ! It's the favicon.ico effect. Nothing in logs when the class is resquested from curl, but with a browser (here Opera), begin a response with html, and it requests for favicon.ico. -- Frédéric Glorieux École nationale des chartes direction des nouvelles technologies et de l'informatique
Re: SOLVED Re: custom writer, working but... a strange exception in logs
Frédéric Glorieux a écrit : I'm baffled. [Yonic] I don't know why that would be... what is the client sending the request? If it gets an error, does it retry or something? Good ! Nothing in logs when the class is resquested from curl, Sorry, same idea, but it's a CSS link. -- Frédéric Glorieux École nationale des chartes direction des nouvelles technologies et de l'informatique
Re: SOLVED Re: custom writer, working but... a strange exception in logs
: It's the favicon.ico effect. : Nothing in logs when the class is resquested from curl, but with a : browser (here Opera), begin a response with html, and it requests for : favicon.ico. HA HA HA HA that's freaking hilarious. One way to avoid that might be to register a NOOP request handler with the name /favicon.ico -Hoss
Re: SOLVED Re: custom writer, working but... a strange exception in logs
On Jun 6, 2007, at 5:32 PM, Chris Hostetter wrote: : It's the favicon.ico effect. : Nothing in logs when the class is resquested from curl, but with a : browser (here Opera), begin a response with html, and it requests for : favicon.ico. HA HA HA HA that's freaking hilarious. One way to avoid that might be to register a NOOP request handler with the name /favicon.ico :) maybe we should build one in that redirects to a solr.ico or something.
