Right about the flow controller. That's where UIMA-AS comes in. Assuming that the CM has a casPool with enough CASes, and the aggregate is deployed asynchronously, then each delegate will be running in its own thread and can be processing CASes in parallel.
The ASB is a single-theaded controller used for deployment of synchronous aggregates. Is the intention here to use parallel processing to reduce latency for a interactive application or to increase throughput for batch processing? For throughput, why not just deploy the entire pipeline single-threaded and then run multiple pipeline instances in separate threads? UIMA-AS would do this by specifying N instances of a synchronous top-level aggregate. Eddie On Wed, May 20, 2015 at 8:49 AM, Petr Baudis <pa...@ucw.cz> wrote: > Hi! > > On Wed, May 20, 2015 at 07:56:33AM -0400, Eddie Epstein wrote: > > Parallel-step currently only works with remote delegates. The other > > approach, using CasMultipliers, allows an arbitrarily amount of parallel > > processing in-process. A CM would create a separate CAS for each delegate > > intended to run in parallel, and use a feature structure to hold a unique > > identifier in each child CAS which a custom flow controller would use to > > direct these CASes to the desired delegates. Results for the parallel > flows > > could be merged in a CasConsumer back into the parent CAS or to some > other > > output. > > Thanks for that hint. However, I'm not sure how a flow controller > could direct CASes to delegates? As far as I understand it, the flow > controller decides which AE processes the CAS next, but cannot control > the actual parallel execution of the flow, which would need to be taken > care by the ASB (Analysis Structure Broker), and that would be the thing > to hack in this case. Am I missing something? > > Thanks, > > Petr Baudis >
