Burn Lewis (JIRA) wrote:
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
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.
I agree this seems an issue.
There seems to be several concerns here. Above you have stated what the
current "documentation" says. What does the current implementation do?
Is it documented what the meaning of 0 being supplied for the Window
and/or the thresholdCount means? (I looked in the docbooks for uima-as
- and didn't see it in the reference chapter).
Thresholds have two common meanings - one is something to be "reached",
the other is something to "cross". I think that the more common meaning
that would come to mind (at least for English speakers) is the "crossed"
idea. (Do others agree?)
So if the underlying issue is that the current docs and implementation
do not have a way to specify taking action on the occurence of the 1st
error, then we might want to explore solving this in other ways that
might preserve the common meaning of threshold.
A design goal I like for the XML we expose to our users is having that
XML be as intuitively obvious to users, who might not be "familiar" with
the "corner cases". One possible approach to this problem is to change
the meaning of 0 for thresholdCount to mean take action when crossing
from 0 to 1, and recover the previous meaning of 0 (ignore errors) in
some other fashion - 2 examples being
thresholdCount="ignore errors"
thresholdCount="-1"
(Or both). The "ignore errors" value would be intuitively obvious to a
casual reader of the XML. The -1 value would something a reader would
not have an immediate intuition for, and they would more likely "look it
up".
-Marshall
