uima-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Valkyrie Savage" <sav...@tk.informatik.tu-darmstadt.de>
Subject RE: CAS Multipliers and Pipeline Troubles
Date Mon, 22 Jun 2009 13:26:19 GMT
Thanks for the responses, guys,

I think that I'll get to work on a Flow Controller with the drop flag set to true, based on
Burn's advice.  Comments below.


-----Original Message-----
From: Eddie Epstein [mailto:eaepstein@gmail.com]
Sent: Mon 6/22/2009 2:56 PM
To: uima-user@incubator.apache.org
Subject: Re: CAS Multipliers and Pipeline Troubles


To confirm your configuration, an aggregate AE contains two Cas
multipliers, one to split and a second to merge large documents. This
AAE is itself contained in a larger aggregate. The desired behavior is
that the inner AAE should return the merged CASes, but not the split
CASes. Of course the original input CASes must also be returned.

>>I don't want the original CAS back.  Also, I am running the AAE inside of a CPE, actually,
and not another aggregate.  Is this important?

For this scenario the inner AAE itself must be declared to be a Cas
multiplier, because the intent is for it to return new CASes. The
inner AAE's flow controller will have to specify that split CASes be
dropped using "new FinalStep(true)", but merged CASes be returned via
"new FinalStep(false)" or just "new FinalStep()".

>>So if I am intending to return a single new CAS that is built from the original CAS
(via a split operation followed by a merge), is it considered a CAS multiplier since the original
one is not the one being returned?

Is this the intended configuration?


-----Original Message-----
From: Burn Lewis [mailto:burnlewis@gmail.com]
Sent: Mon 6/22/2009 3:02 PM
To: uima-user@incubator.apache.org
Subject: Re: CAS Multipliers and Pipeline Troubles
Is your demultiplier reversing the action of the first CM and merging N
input CASes into 1 output CAS?  If so then change the

>>Yes.  This is what I'm hoping to do.

ActionAfterCasMultiplier to "drop".  This will ensure that the only CAS that
continues in the flow is the one output by the demultiplier.  Since only the
N-th input CAS will generate an output CAS when merging, the default of
"dropIfNewCasProduced" will let all but the last split CAS continue in the
flow and only the N-th will be dropped when the merged CAS is finally

>>Ah, this makes sense.  I guess I had thought that there would be some flag on the
constituent CASes that informed them that they were to be dropped when merged.

If I've misunderstood your application please clarify the action of the

>>Nope, thank you!

- Burn.

  • Unnamed multipart/mixed (inline, None, 0 bytes)
View raw message