[
https://issues.apache.org/jira/browse/UIMA-1245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12655241#action_12655241
]
Eddie Epstein commented on UIMA-1245:
-------------------------------------
{quote}
I assume this would be a per-CM option, not application wide .... where should
we specify it and how? Should we make this new behaviour the default? Should
the default be true or false? Perhaps in the deployment descriptor:
<casMultiplier poolSize="1" processParentLast="true">
or
<casMultiplier poolSize="1" processParentEarly="false">
or ....
{quote}
As per the original intent of this issue, the default has to be process the
parent last. I'd vote for processParentEarly="false" syntax. Yes, this has to
be per CM.
{quote}
As Burn points out, the "new signalling" I mentioned above isn't new - it's
already implemented, and serves (among other uses) to keep an inner remote CAS
multiplier "throttled" from generating too many CASes too rapidly.
{quote}
The "signalling" mechanism, which prevents a parent CAS from being returned
before all processing on its children is completed, was created so that any
errors while "working" on that CAS could be reported back to the client that
sent it. CAS multiplier throttling is accomplished only by the size of its CAS
pool.
{quote}
Now, since this signal is there, it allows some alternatives, for when the
parent is being blocked. Should the block be lifted when all the child CASes at
this level have been processed, or only when all the child CASes at this level
have been released (by virtue of a signal from containing aggregates, perhaps,
as described above)?
{quote}
The block is for child CASes still in process. When all processing on the
children is done, the parent is unblocked.
{quote}
In thinking more about this, perhaps the option should be to allow processing
the "parent-last" on a specific delegate, instead of having the block be at the
CAS Multiplier. This would allow the parent to flow through additional AEs in
its path up to some specified point, where it would then be forced to wait for
all of its children to be released. This would satisfy the use case of insuring
at some point in the flow that the parent was blocked until its children were
released.
{quote}
Interesting, but is certainly a more complicated design. Also, if the default
is to have the same behavior as core UIMA, then every subsequent AE would have
the parent-last block on, and unblocking would require lots of overrides.
Eddie
> Processing order of parent CAS different on UIMA and UIMA AS
> ------------------------------------------------------------
>
> Key: UIMA-1245
> URL: https://issues.apache.org/jira/browse/UIMA-1245
> Project: UIMA
> Issue Type: Bug
> Components: Async Scaleout
> Reporter: Eddie Epstein
>
> Arron Kaplan raised the question of when parent CASes are processed relative
> to their children. See http://markmail.org/message/5cop7iv2nshouhgs As of
> now, the processing order for a multi-threaded UIMA AS aggregate is different
> than that for a single-threaded UIMA aggregate.
> A discussion with Burn, Adam, Jerry, Marshall and myself concluded that the
> default processing order for UIMA AS should be changed to be the same as in
> UIMA, in order to have the same application behavior for both. This will be
> done by suspending flow of a parent CAS after it is returned from a
> CasMultiplier delegate until all its children CASes have finished processing.
> However, there also needs to be a UIMA AS deployment option for CasMultiplier
> delegates that allows the parent CAS to resume processing immediately after
> being returned from the CM. This option is needed to enable parallel
> processing.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
