I think I've "fired" too soon with the patch. I think the main algorithm implemented by Burn works though. What remains is an agreement on when to trigger the action. Code change to support either approach (reached or exceeded threshold) is trivial. I've checked the CPM and it looks like the action triggers when the threshold is *exceeded*. This doesnt mean that this the right thing to do in the uima-as, its just what the current CPM user expects. Perhaps the terminology is wrong here. Instead of threshold perhaps this should be error tolerance or something like that.
On Mon, Mar 3, 2008 at 4:24 PM, Burn Lewis (JIRA) < [email protected]> wrote: > > [ > https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574741#action_12574741] > > Burn Lewis commented on UIMA-838: > --------------------------------- > > The current implementation takes the action when the threshold is reached > (0 => no threshold, so ignore errors & 1 => no errors permitted so stop on > first error.) But the wondow is not a sliding one, as the count of > accumulated errors is reset every 'thresholdWindow' CASes. > > I agree that thresholds are usually crossed, but if we change the > implementation so -1 => no threshold (an infinite number of errors > permitted) then would it be confusing to continue to use 0 to mean no > timeout and no window. > > Can we instead talk about a threshold at which the error action is taken, > rather than a threshold for taking no action, e.g. > > The thresholdCount and thresholdWindow attributes specify the > threshold at which the thresholdAction is taken. > If xxx errors occur within a window of size yyy, the framework > takes the specified > action of either disabling this delegate, or terminating the > containing AS Aggregate > (or if not an AS Aggregate, terminating the AS Primitive). > A thresholdCount of 0 has the special meaning of no-threshold > (errors ignored), > and a thresholdWindow of 0 means no-window (all errors are > counted.) > > I think it helps to describe the special values here, before the defaults > section. > > > > > Incorrect support for process CAS error threshold count and threshold > window > > > ----------------------------------------------------------------------------- > > > > Key: UIMA-838 > > URL: https://issues.apache.org/jira/browse/UIMA-838 > > Project: UIMA > > Issue Type: Bug > > Components: Async Scaleout > > Reporter: Burn Lewis > > Attachments: uimaj-as-core-UIMA-838-patch.txt > > > > > > The thresholdAction should be taken when the number of CAS errors > reaches the thresholdCount value within the last thresholdWindow CASes. A > thresholdWindow of 0 means an infinite window, so the action is taken when > the total number of errors reaches the thresholdCount. A thresholdCount of > 0 means an infinite limit, errors are ignored. A thresholdCount of 1 means > that the first error triggers the action, hence the action must be taken > when the threshold is REACHED, not exceeded as stated in the current docs. > (Although thresholds usually apply when exceeded, making the thresholdCount > be the number permitted would require using a value such as -1 for no > threshold, in contrast to our use of 0 to mean no timeout and no window) > > It should be an error to specify a (non-zero) thresholdWindow that is > smaller than the thresholdCount ... an impossible situation. > > Note that if thresholdCount = 1 the thresholdWindow value is irrelevant, > and if thresholdCount = thresholdWindow the action is taken when that many > consecutive errors occur. > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
