You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Burn Lewis (JIRA)" <ui...@incubator.apache.org> on 2008/03/03 04:40:50 UTC
[jira] Created: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (UIMA-838) Incorrect support for process CAS
error threshold count and threshold window
Posted by Marshall Schor <ms...@schor.com>.
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
Re: [jira] Commented: (UIMA-838) Incorrect support for process CAS error threshold count and threshold window
Posted by Jaroslaw Cwiklik <ui...@gmail.com>.
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) <
uima-dev@incubator.apache.org> 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.
>
>
Re: [jira] Updated: (UIMA-838) Incorrect support for process CAS error threshold count and threshold window
Posted by Eddie Epstein <ea...@gmail.com>.
On Fri, Mar 14, 2008 at 6:12 PM, Burn Lewis (JIRA)
<ui...@incubator.apache.org> wrote:
> Attachment: UIMA-838-docs.patch
>
> Here's a patch for the docs that describes this act-when-threshold reached implementation.
Thanks Burn.
I made additional changes on top of yours. Please review.
Eddie
[jira] Reopened: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eddie Epstein reopened UIMA-838:
--------------------------------
More doc's changes needed.
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-docs2.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Resolved: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eddie Epstein resolved UIMA-838.
--------------------------------
Resolution: Fixed
Fix Version/s: 2.2.2S
Applied patches and confirmed extended test suite ran.
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Burn Lewis updated UIMA-838:
----------------------------
Attachment: UIMA-838-fix2.patch
Sorry to say my fix didn't handle the thresholdWindow == thresholdCount case .... i.e. when the action should be taken after thresholdCount consecutive errors. The current implementation treats this as if there were no window, counting total errors.
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-docs2.patch, UIMA-838-fix2.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Commented: (UIMA-838) Incorrect support for process CAS
error threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575042#action_12575042 ]
Burn Lewis commented on UIMA-838:
---------------------------------
I've started a discussion on taking action when threshold reached vs. exceeded in uima-dev
> 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.
[jira] Assigned: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor reassigned UIMA-838:
-----------------------------------
Assignee: Marshall Schor
> 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
> Assignee: Marshall Schor
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-docs2.patch, UIMA-838-fix2.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Commented: (UIMA-838) Incorrect support for process CAS
error threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ 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.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Burn Lewis updated UIMA-838:
----------------------------
Attachment: UIMA-838-test.patch
UIMA-838.patch
> 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: UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Burn Lewis updated UIMA-838:
----------------------------
Attachment: UIMA-838-docs2.patch
A few more suggestions.
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-docs2.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-838:
-------------------------------
Attachment: (was: uimaj-as-core-UIMA-838-patch.txt)
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Marshall Schor closed UIMA-838.
-------------------------------
Resolution: Fixed
> 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
> Assignee: Marshall Schor
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-docs2.patch, UIMA-838-fix2.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
Re: [jira] Reopened: (UIMA-838) Incorrect support for process CAS error threshold count and threshold window
Posted by Burn Lewis <bu...@gmail.com>.
Actually I removed it deliberately as the removeAnalysisEngines method
returns a void so I didn't see how it could respond that the disable should
become terminate ... unlike the other "over-riding" method continueOnFailure
which returns a boolean. But then I noticed that the Javadocs for the
FlowController Interface actually suggests throwing an exception:
Also the FlowController may throw an Exception if it determines that it does
not make sense for the flow to continue in the absence of the removed
Analysis Engines (see
AnalysisEngineProcessException.FLOW_CANNOT_CONTINUE_AFTER_REMOVE.
So in my last patch I suggested:
Note that when disabling, the framework asks the flow controller to
remove the delegate from the flow,
but if the flow controller cannot reasonably operate without this
component
it can convert the action to 'terminate' by throwing an exception.
Perhaps we could also refer to the appropriate Javadocs.
- Burn
On Sun, Mar 16, 2008 at 11:31 AM, Eddie Epstein <ea...@gmail.com> wrote:
> On Sat, Mar 15, 2008 at 8:12 PM, Marshall Schor <ms...@schor.com> wrote:
> > The documentation fixes include changing what happens when a "disable"
> > action occurs. It use to say that
> > ...
> >
> > When disabling, the framework asks the flow controller to remove the
> > delegate from the flow; the flow controller may respond to the
> framework that it cannot
> > reasonably operate without this component, in which case
> > the framework will convert the "disable" into a "terminate".
> >
> > ...
> >
> > This was removed. It seems to me that this was a good design. I think
> > this is a case where the documentation is being made to match the
> > implementation, when, perhaps, we should be making the implementation
> > match the documentation, or at least, leaving the documentation, as it
> > was, but perhaps including a <not-yet-implemented> flag.
> >
> > -Marshall
> >
>
> Sorry, the paragraph removed is good and does reflect the
> implementation. Burn had removed it, probably by accident, and I had
> meant to add it back. Good catch.
>
> Eddie
>
Re: [jira] Reopened: (UIMA-838) Incorrect support for process CAS error threshold count and threshold window
Posted by Eddie Epstein <ea...@gmail.com>.
On Sat, Mar 15, 2008 at 8:12 PM, Marshall Schor <ms...@schor.com> wrote:
> The documentation fixes include changing what happens when a "disable"
> action occurs. It use to say that
> ...
>
> When disabling, the framework asks the flow controller to remove the
> delegate from the flow; the flow controller may respond to the framework that it cannot
> reasonably operate without this component, in which case
> the framework will convert the "disable" into a "terminate".
>
> ...
>
> This was removed. It seems to me that this was a good design. I think
> this is a case where the documentation is being made to match the
> implementation, when, perhaps, we should be making the implementation
> match the documentation, or at least, leaving the documentation, as it
> was, but perhaps including a <not-yet-implemented> flag.
>
> -Marshall
>
Sorry, the paragraph removed is good and does reflect the
implementation. Burn had removed it, probably by accident, and I had
meant to add it back. Good catch.
Eddie
Re: [jira] Reopened: (UIMA-838) Incorrect support for process CAS
error threshold count and threshold window
Posted by Marshall Schor <ms...@schor.com>.
Eddie Epstein (JIRA) wrote:
> [ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
>
> Eddie Epstein reopened UIMA-838:
> --------------------------------
>
>
> add documentation fixes
>
The documentation fixes include changing what happens when a "disable"
action occurs. It use to say that
...
When disabling, the framework asks the flow controller to remove the
delegate from the flow; the flow controller may respond to the framework that it cannot
reasonably operate without this component, in which case
the framework will convert the "disable" into a "terminate".
...
This was removed. It seems to me that this was a good design. I think
this is a case where the documentation is being made to match the
implementation, when, perhaps, we should be making the implementation
match the documentation, or at least, leaving the documentation, as it
was, but perhaps including a <not-yet-implemented> flag.
-Marshall
[jira] Reopened: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eddie Epstein reopened UIMA-838:
--------------------------------
add documentation fixes
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Resolved: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Eddie Epstein resolved UIMA-838.
--------------------------------
Resolution: Fixed
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Jerry Cwiklik (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jerry Cwiklik updated UIMA-838:
-------------------------------
Attachment: uimaj-as-core-UIMA-838-patch.txt
Fixed uima-as error handling logic to support moving window concept for tracking errors and triggering actions based on defined thresholds.
> 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.
[jira] Commented: (UIMA-838) Incorrect support for process CAS
error threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12576968#action_12576968 ]
Burn Lewis commented on UIMA-838:
---------------------------------
Here's a fix for the sliding window (still takes the action when the threshold is reached.) New test case included.
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (UIMA-838) Incorrect support for process CAS
error threshold count and threshold window
Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12574560#action_12574560 ]
Marshall Schor commented on UIMA-838:
-------------------------------------
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".
> 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.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (UIMA-838) Incorrect support for process CAS error
threshold count and threshold window
Posted by "Burn Lewis (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Burn Lewis updated UIMA-838:
----------------------------
Attachment: UIMA-838-docs.patch
Here's a patch for the docs that describes this act-when-threshold reached implementation.
> 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
> Fix For: 2.2.2S
>
> Attachments: UIMA-838-docs.patch, UIMA-838-test.patch, UIMA-838.patch
>
>
> 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.