[
https://issues.apache.org/jira/browse/SOLR-5201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13756769#comment-13756769
]
Hoss Man commented on SOLR-5201:
--------------------------------
bq. The second option sounds nice but I wonder if that would cause a problem
with multiple configurations (2 update chains with 2 different configurations
of UIMAUpdateRequestProcessorFactory),
It depends on what kinds or problems you are worried about ... each
UIMAUpdateRequestProcessorFactory instance (ie: one instance per chain) should
each have it's own AnalysisEngine using it's own configuration ... unless the
AnalysisEngine constructor/factory/provider does something special to keep
track of them, they won't know anything about eachother.
If you *want* them to know about eachother (ie: to share an AnalysisEngine
between chains, or between chains in different SolrCores) then something a lot
more special case would need to be done.
> UIMAUpdateRequestProcessor should reuse the AnalysisEngine
> ----------------------------------------------------------
>
> Key: SOLR-5201
> URL: https://issues.apache.org/jira/browse/SOLR-5201
> Project: Solr
> Issue Type: Improvement
> Components: contrib - UIMA
> Affects Versions: 4.4
> Reporter: Tommaso Teofili
> Assignee: Tommaso Teofili
> Fix For: 4.5, 5.0
>
> Attachments: SOLR-5201-ae-cache-every-request_branch_4x.patch,
> SOLR-5201-ae-cache-only-single-request_branch_4x.patch
>
>
> As reported in http://markmail.org/thread/2psiyl4ukaejl4fx
> UIMAUpdateRequestProcessor instantiates an AnalysisEngine for each request
> which is bad for performance therefore it'd be nice if such AEs could be
> reused whenever that's possible.
--
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]
