[
https://issues.apache.org/jira/browse/SOLR-2186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12924284#action_12924284
]
Lance Norskog commented on SOLR-2186:
-------------------------------------
I've tracked it down. The ThreadedContext object is built without a resolver.
There is a notation that the resolver will be set dynamicall but it is not.
The ThreadedContext resolver is called in the "firstInit" methods
TikaEntityProcessor, LineEntityProcessor, and XPathEntityProcessor.
TikaEntityProcessor also calls it in nextRow.
public class ThreadedContext extends ContextImpl{
private DocBuilder.EntityRunner entityRunner;
private boolean limitedContext = false;
public ThreadedContext(DocBuilder.EntityRunner entityRunner, DocBuilder
docBuilder) {
super(entityRunner.entity,
null,//to be fethed realtime
null,
null,
docBuilder.session,
null,
docBuilder);
this.entityRunner = entityRunner;
}
I hacked DocBuilder.java to throw in a resolver and that allowed the TikaEP to
function during firstInit. Then, the entity attribute resolver failed in the
nextRow method.
TikaEP is the only class that calls the entity attribute resolver outside of
the firstInit() call. Is it possible to change TikeEP to only use the resolver
in firstInit?
> DataImportHandler multi-threaded option throws exception
> --------------------------------------------------------
>
> Key: SOLR-2186
> URL: https://issues.apache.org/jira/browse/SOLR-2186
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
> Reporter: Lance Norskog
>
> The multi-threaded option for the DataImportHandler throws an exception and
> the entire operation fails. This is true even if only 1 thread is configured
> via *threads='1'*
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
