My problem was that the XMLResponseWriter is using the searcher of the
original request to get the matching documents (in the method writeDocList
of the class XMLWriter). Since the DocList contains id from the index of the
second core, there were not valid in the index of the core receiving the
request.

To circumvent the problem, I implement a custom response writer. This is not
a problem for my project since I have to return a custom format.


Pascal Dimassimo wrote:
> 
> Hi,
> 
> I'm writing a custom handler that forwards a request to a handler of
> another core. The custom handler is defined in "core0" and the core I try
> to send the request to is "core2" which has a mlt handler. Here is the
> code of my custom handler (extends RequestHandlerBase and implements
> SolrCoreAware):
> 
> public void inform(SolrCore core) {
>         this.core = core;
>         this.cores = core.getCoreDescriptor().getCoreContainer();
>         this.multiCoreHandler = cores.getMultiCoreHandler();
> }
> 
> public void handleRequestBody(SolrQueryRequest request, SolrQueryResponse
> response)
>             throws Exception {
>         
>         SolrCore coreToRequest = cores.getCore("core2");
> 
>         ModifiableSolrParams params = new ModifiableSolrParams();
>         params.set("q", "Lucene");
>         params.set("mlt.fl", "body");
>         params.set("debugQuery", "true");
>         
>         request = new LocalSolrQueryRequest(coreToRequest, params);
> 
>         SolrRequestHandler mlt = coreToRequest.getRequestHandler("/mlt");
>         coreToRequest.execute(mlt, request, response);
> 
>         coreToRequest.close();
> }
> 
> 
> I'm calling this handler from firefox with this url (the path of my custom
> handler is /nlt):
> http://localhost:8080/solr/core0/nlt
> 
> With my debugger, I can see, after the execute() method is executed, this
> line in the log:
> 13-Mar-2009 4:25:59 PM org.apache.solr.core.SolrCore execute
> INFO: [core2] webapp=/solr path=/nlt params={} webapp=null path=null
> params={q=Lucene&mlt.fl=body&debugQuery=true} status=0 QTime=125
> 
> Which seems logical: the core2 is executing the request (though I'm
> wondering how core2 knows about the "/nlt" path)
> 
> After, I let the debugger resume the program and I see those lines:
> 13-Mar-2009 4:25:59 PM org.apache.solr.core.SolrCore execute
> INFO: [core0] webapp=/solr path=/nlt params={} webapp=null path=null
> params={q=Lucene&mlt.fl=body&debugQuery=true} status=0 QTime=125 status=0
> QTime=141 
> 13-Mar-2009 4:25:59 PM org.apache.solr.common.SolrException log
> SEVERE: java.lang.ArrayIndexOutOfBoundsException: -1
>         at
> org.apache.lucene.index.MultiSegmentReader.document(MultiSegmentReader.java:259)
>         at
> org.apache.lucene.index.IndexReader.document(IndexReader.java:632)
>         at
> org.apache.solr.search.SolrIndexSearcher.doc(SolrIndexSearcher.java:371)
>         at
> org.apache.solr.request.XMLWriter$3.writeDocs(XMLWriter.java:479)
> 
> It looks like core0 is also trying to handle the request. With the
> debugger, I discover that the code is trying to access a document with an
> id of the index of core2 within the index of core0, which fails
> (SolrIndexSearcher.java:371).
> 
> Any idea with there seems to be two cores that try to handle the request?
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/Custom-handler-that-forwards-a-request-to-another-core-tp22501470p22541459.html
Sent from the Solr - User mailing list archive at Nabble.com.

Reply via email to