You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Richard Eckart de Castilho (JIRA)" <de...@uima.apache.org> on 2016/09/09 17:48:23 UTC
[jira] [Updated] (UIMA-111) Potential CPM Performance Issue with
multiple Sofas
[ https://issues.apache.org/jira/browse/UIMA-111?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Richard Eckart de Castilho updated UIMA-111:
--------------------------------------------
Labels: Stale (was: )
This issue is marked as "stale" due to inactivity for 5 years or longer. If no further activity is detected on this issue, it is scheduled be closed as 'unresolved' in 3 months time from now (Dec 2016).
> Potential CPM Performance Issue with multiple Sofas
> ---------------------------------------------------
>
> Key: UIMA-111
> URL: https://issues.apache.org/jira/browse/UIMA-111
> Project: UIMA
> Issue Type: Improvement
> Components: Collection Processing
> Reporter: Adam Lally
> Priority: Minor
> Labels: Stale
>
> (Originally reported as CMVC defect 3117)
> We need to revisit some special handling of document
> text. The CPM currently, for Vinci deployed-services,
> attempts to preserve the document text in case the
> service omits the document text from the XCAS it
> returns (as an optimization). In practice, our services no
> longer do this optimization - they always return the text.
> The potential issue is that the CPM does a brute-force
> search of CasData looking for the "document text".
> For single-sofa cases, this is always the first
> (or near to the first) element of the CasData, so
> no problem. But for multiple-sofa services, there
> is no "document text" element at all. In this
> case the CPM would do a brute force search of the
> entire CasData on each call.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)