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)