uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Eckart de Castilho <...@apache.org>
Subject Re: Error when trying to drop CAS with FlowController
Date Sun, 06 Sep 2015 15:20:18 GMT
That would require that the OUTER_AAE is aware of the filtering. 
We would prefer if all customization/filtering/etc. could be done in the
INNER_AAE which is the declared extension point.

In the worst case, we'd probably opt to move the FILTER from to
the OUTER_AAE entirely and make filtering a default option. 

My assumption would be that the OUTER_AAE should not have a problem 
if the INNER_AAE drops anything if INNER_AAE declares outputsNewCases=true.
But obviously that assumption is wrong - I/we just don't get why.

Cheers,

-- Richard

On 06.09.2015, at 17:14, Eddie Epstein <eaepstein@gmail.com> wrote:

> How about the filter adds a FeatureStructure indicating that the CAS should
> be dropped.
> Then when the INNER_AAE returns the CAS, the flow controller in the
> OUTER_AAE
> sends the CAS to FinalStep?
> 
> Eddie
> 
> On Sun, Sep 6, 2015 at 11:08 AM, Richard Eckart de Castilho <rec@apache.org>
> wrote:
> 
>> Eddie,
>> 
>> we (Torsten and I) have the case that a reader produces a number of CASes
>> and we want to filter out some of them because they do not match a given
>> criteria.
>> 
>> The pipeline/flow structure we are using looks as follows:
>> 
>> READER -> OUTER_AAE { AEs..., INNER_AAE { FILTER }, AEs..., CONSUMER }
>> 
>> READER, OUTER_AAE, AEs and CONSUMER are assumed to be fixed.
>> 
>> INNER_AAE is meant to be an extension point and the FILTER inside it
>> is meant to remove all CASes that do not match our criteria such
>> that those do not reach the CONSUMER.
>> 
>> So we do explicitly not want certain CASes to continue the processing path.
>> 
>> -- Richard
>> 
>> On 06.09.2015, at 17:04, Eddie Epstein <eaepstein@gmail.com> wrote:
>> 
>>> Richard,
>>> 
>>> In general the input CAS must continue down some processing path.
>>> Where is it stored and what triggers its continued processing if it is
>> not
>>> returned?
>>> 
>>> Eddie
>>> 
>>> On Sun, Sep 6, 2015 at 10:28 AM, Richard Eckart de Castilho <
>> rec@apache.org>
>>> wrote:
>>> 
>>>> Hi Eddie,
>>>> 
>>>> in most cases, we use process(CAS) and in such a case what you describe
>>>> is very logical.
>>>> 
>>>> However, when setting outputsNewCases to true, doesn't the contract
>> change?
>>>> My understanding is that processAndOutputNewCASes(CAS) is being
>>>> used and in such a case. Why shouldn't it be ok that the iterator
>>>> returned by processAndOutputNewCASes does not contain the input CAS?
>>>> 
>>>> Cheers,
>>>> 
>>>> -- Richard
>>>> 
>>>> On 06.09.2015, at 16:21, Eddie Epstein <eaepstein@gmail.com> wrote:
>>>> 
>>>>> Hi Richard,
>>>>> 
>>>>> FinalStep() in a CasMultiplier aggregate means to stop further flow
>>>>> in the aggregate and return the CAS to the component that passed
>>>>> the CAS into the aggregate, or if a child-CAS, passed the child's
>>>>> parent-CAS into the aggregate.
>>>>> 
>>>>> FinalStep(true) is used to stop a child-CAS from being returned
>>>>> to the component. But the contract for an AE is CAS-in/CAS-out,
>>>>> which means a CAS coming into an AE must be returned.
>>>>> 
>>>>> Eddie
>>>>> 
>>>>> On Sun, Sep 6, 2015 at 9:59 AM, Richard Eckart de Castilho <
>>>> rec@apache.org>
>>>>> wrote:
>>>>> 
>>>>>> Hi Eddie,
>>>>>> 
>>>>>> ok, but why can input CASes created outside the aggregate not be
>>>> dropped?
>>>>>> 
>>>>>> Cheers,
>>>>>> 
>>>>>> -- Richard
>>>> 
>>>> 
>> 
>> 


Mime
View raw message