You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Adam Lally (JIRA)" <ui...@incubator.apache.org> on 2007/02/28 21:08:50 UTC
[jira] Created: (UIMA-327) Flow Controller API extensions in
support of more complex flow options
Flow Controller API extensions in support of more complex flow options
----------------------------------------------------------------------
Key: UIMA-327
URL: https://issues.apache.org/jira/browse/UIMA-327
Project: UIMA
Issue Type: New Feature
Components: Core Java Framework
Reporter: Adam Lally
Assigned To: Adam Lally
Fix For: 2.2
1) ParallelStep - a new subtype of Step that the Flow Controller can
return. The ParallelStep constructor would take a List of keys,
indicating that multiple AEs could logically be run in parallel. Note
that the runtime may or may not actually execute them in parallel - in
a collocated deployment it certainly would not. In a remote
deployment we can (eventually) support parallel execution by making
use of the XMI merging support I put in.
2) Dynamically adding/removing AEs from the aggregate. This would be
a new set of FlowConroller APIs:
removeAnalysisEngines(List)
addAnalysisEngines(List)
each of which takes a List of keys. The AnalysisEngine metadata map
available through the FlowControllerContext would also be updated.
This supports error handling such as the "disable" action in the
current CPM, allowing removing a misbehaving AE from the flow.
Someday it could also allow adding new AEs to an aggregate
dynamically.
The Flow Controller could throw an exception in response to
removeAnalysisEngines, indicating that the aggregate cannot continue
without the removed AEs (or that the flow controller simply can't
handle dynamic removal - maybe that should be the default in fact).
3) Notification of errors to allow continuing after a failure. This
would support an action like the current CPM's "continue" action.
There would be a new API:
Flow.onFailure(String failedAnalysisEngineKey, Throwable failure)
If the runtime wanted to continue after a failure, it would call this
method on the Flow Controller, and then would go back to calling
hasNext/next. Without this notification, a "continue" action wouldn't
make much sense, because a dynamic FlowControlle may make an
assumption that the last step it issued completed successfully.
Note for #2 and #3 the existing framework won't call these methods, yet.
These Flow Controller extensions are a prerequisite for doing more
advanced flow things like parallel flows and error recovery.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Work started: (UIMA-327) Flow Controller API extensions in
support of more complex flow options
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Work on UIMA-327 started by Adam Lally.
> Flow Controller API extensions in support of more complex flow options
> ----------------------------------------------------------------------
>
> Key: UIMA-327
> URL: https://issues.apache.org/jira/browse/UIMA-327
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
> Reporter: Adam Lally
> Assigned To: Adam Lally
> Fix For: 2.2
>
>
> 1) ParallelStep - a new subtype of Step that the Flow Controller can
> return. The ParallelStep constructor would take a List of keys,
> indicating that multiple AEs could logically be run in parallel. Note
> that the runtime may or may not actually execute them in parallel - in
> a collocated deployment it certainly would not. In a remote
> deployment we can (eventually) support parallel execution by making
> use of the XMI merging support I put in.
> 2) Dynamically adding/removing AEs from the aggregate. This would be
> a new set of FlowConroller APIs:
> removeAnalysisEngines(List)
> addAnalysisEngines(List)
> each of which takes a List of keys. The AnalysisEngine metadata map
> available through the FlowControllerContext would also be updated.
> This supports error handling such as the "disable" action in the
> current CPM, allowing removing a misbehaving AE from the flow.
> Someday it could also allow adding new AEs to an aggregate
> dynamically.
> The Flow Controller could throw an exception in response to
> removeAnalysisEngines, indicating that the aggregate cannot continue
> without the removed AEs (or that the flow controller simply can't
> handle dynamic removal - maybe that should be the default in fact).
> 3) Notification of errors to allow continuing after a failure. This
> would support an action like the current CPM's "continue" action.
> There would be a new API:
> Flow.onFailure(String failedAnalysisEngineKey, Throwable failure)
> If the runtime wanted to continue after a failure, it would call this
> method on the Flow Controller, and then would go back to calling
> hasNext/next. Without this notification, a "continue" action wouldn't
> make much sense, because a dynamic FlowControlle may make an
> assumption that the last step it issued completed successfully.
> Note for #2 and #3 the existing framework won't call these methods, yet.
> These Flow Controller extensions are a prerequisite for doing more
> advanced flow things like parallel flows and error recovery.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (UIMA-327) Flow Controller API extensions in support
of more complex flow options
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Lally closed UIMA-327.
---------------------------
> Flow Controller API extensions in support of more complex flow options
> ----------------------------------------------------------------------
>
> Key: UIMA-327
> URL: https://issues.apache.org/jira/browse/UIMA-327
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
> Reporter: Adam Lally
> Assignee: Adam Lally
> Fix For: 2.2
>
>
> 1) ParallelStep - a new subtype of Step that the Flow Controller can
> return. The ParallelStep constructor would take a List of keys,
> indicating that multiple AEs could logically be run in parallel. Note
> that the runtime may or may not actually execute them in parallel - in
> a collocated deployment it certainly would not. In a remote
> deployment we can (eventually) support parallel execution by making
> use of the XMI merging support I put in.
> 2) Dynamically adding/removing AEs from the aggregate. This would be
> a new set of FlowConroller APIs:
> removeAnalysisEngines(List)
> addAnalysisEngines(List)
> each of which takes a List of keys. The AnalysisEngine metadata map
> available through the FlowControllerContext would also be updated.
> This supports error handling such as the "disable" action in the
> current CPM, allowing removing a misbehaving AE from the flow.
> Someday it could also allow adding new AEs to an aggregate
> dynamically.
> The Flow Controller could throw an exception in response to
> removeAnalysisEngines, indicating that the aggregate cannot continue
> without the removed AEs (or that the flow controller simply can't
> handle dynamic removal - maybe that should be the default in fact).
> 3) Notification of errors to allow continuing after a failure. This
> would support an action like the current CPM's "continue" action.
> There would be a new API:
> Flow.onFailure(String failedAnalysisEngineKey, Throwable failure)
> If the runtime wanted to continue after a failure, it would call this
> method on the Flow Controller, and then would go back to calling
> hasNext/next. Without this notification, a "continue" action wouldn't
> make much sense, because a dynamic FlowControlle may make an
> assumption that the last step it issued completed successfully.
> Note for #2 and #3 the existing framework won't call these methods, yet.
> These Flow Controller extensions are a prerequisite for doing more
> advanced flow things like parallel flows and error recovery.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (UIMA-327) Flow Controller API extensions in
support of more complex flow options
Posted by "Adam Lally (JIRA)" <ui...@incubator.apache.org>.
[ https://issues.apache.org/jira/browse/UIMA-327?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Adam Lally resolved UIMA-327.
-----------------------------
Resolution: Fixed
All of this has been implemented. Opened UIMA-331 to consider adding a built-in flow controller that can do ParallelStep and continue after error.
> Flow Controller API extensions in support of more complex flow options
> ----------------------------------------------------------------------
>
> Key: UIMA-327
> URL: https://issues.apache.org/jira/browse/UIMA-327
> Project: UIMA
> Issue Type: New Feature
> Components: Core Java Framework
> Reporter: Adam Lally
> Assigned To: Adam Lally
> Fix For: 2.2
>
>
> 1) ParallelStep - a new subtype of Step that the Flow Controller can
> return. The ParallelStep constructor would take a List of keys,
> indicating that multiple AEs could logically be run in parallel. Note
> that the runtime may or may not actually execute them in parallel - in
> a collocated deployment it certainly would not. In a remote
> deployment we can (eventually) support parallel execution by making
> use of the XMI merging support I put in.
> 2) Dynamically adding/removing AEs from the aggregate. This would be
> a new set of FlowConroller APIs:
> removeAnalysisEngines(List)
> addAnalysisEngines(List)
> each of which takes a List of keys. The AnalysisEngine metadata map
> available through the FlowControllerContext would also be updated.
> This supports error handling such as the "disable" action in the
> current CPM, allowing removing a misbehaving AE from the flow.
> Someday it could also allow adding new AEs to an aggregate
> dynamically.
> The Flow Controller could throw an exception in response to
> removeAnalysisEngines, indicating that the aggregate cannot continue
> without the removed AEs (or that the flow controller simply can't
> handle dynamic removal - maybe that should be the default in fact).
> 3) Notification of errors to allow continuing after a failure. This
> would support an action like the current CPM's "continue" action.
> There would be a new API:
> Flow.onFailure(String failedAnalysisEngineKey, Throwable failure)
> If the runtime wanted to continue after a failure, it would call this
> method on the Flow Controller, and then would go back to calling
> hasNext/next. Without this notification, a "continue" action wouldn't
> make much sense, because a dynamic FlowControlle may make an
> assumption that the last step it issued completed successfully.
> Note for #2 and #3 the existing framework won't call these methods, yet.
> These Flow Controller extensions are a prerequisite for doing more
> advanced flow things like parallel flows and error recovery.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.