You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@uima.apache.org by "Eddie Epstein (JIRA)" <ui...@incubator.apache.org> on 2009/02/26 23:51:04 UTC

[jira] Created: (UIMA-1295) Add "continue" as an error handling option for getMeta at initialization

Add "continue" as an error handling option for getMeta at initialization
------------------------------------------------------------------------

                 Key: UIMA-1295
                 URL: https://issues.apache.org/jira/browse/UIMA-1295
             Project: UIMA
          Issue Type: New Feature
          Components: Async Scaleout
            Reporter: Eddie Epstein


In http://markmail.org/message/ceb2npk5qsmuftn4 Yosi Mass requested that UIMA support a peer-to-peer capability where services are discovered dynamically to improve load balancing, and presumably, to enhance processing by using analytics which only become available after a client has started.

UIMA AS already supports dynamically expanding processing capability for a particular service, by simply starting additional service instances pointed at the service's existing request queue. Using appropriate error handling and/or custom flow controller options, a UIMA AS aggregate also has the capability to ignore a missing delegate service, as long as the delegate service was available during aggregate initialization. The enhancement suggested here is to allow an aggregate service to later use a delegate service that was unavailable during initialization.

UIMA changes would be:

1. add a new error handling option for getMeta failures at initialization. Currently the options at init are to disable any use of the delegate, or fail initialization and terminate the aggregate. The new option, "continue", would be ignore this failure and complete initialization of the aggregate, but mark the delegate as being in a special state, very similar to the "questionable" state described in UIMA-1127.

2. The difference from UIMA-1127 is that when getMeta succeeds for this delegate, the service's type system would be checked to see that it is compatible with that of the aggregate. See UIMA-1290 for details on what validation means. If valid, the delegate is marked fully operational. If the type system fails validation, and process error handling is set to continue, a new exception type would be given to the flow controller to decide how to handle the situation.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (UIMA-1295) Add "continue" as an error handling option for getMeta at initialization

Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
    [ https://issues.apache.org/jira/browse/UIMA-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12743207#action_12743207 ] 

Marshall Schor commented on UIMA-1295:
--------------------------------------

Eddie - is this something for 2.3.0 release, or should we defer it?

> Add "continue" as an error handling option for getMeta at initialization
> ------------------------------------------------------------------------
>
>                 Key: UIMA-1295
>                 URL: https://issues.apache.org/jira/browse/UIMA-1295
>             Project: UIMA
>          Issue Type: New Feature
>          Components: Async Scaleout
>            Reporter: Eddie Epstein
>
> In http://markmail.org/message/ceb2npk5qsmuftn4 Yosi Mass requested that UIMA support a peer-to-peer capability where services are discovered dynamically to improve load balancing, and presumably, to enhance processing by using analytics which only become available after a client has started.
> UIMA AS already supports dynamically expanding processing capability for a particular service, by simply starting additional service instances pointed at the service's existing request queue. Using appropriate error handling and/or custom flow controller options, a UIMA AS aggregate also has the capability to ignore a missing delegate service, as long as the delegate service was available during aggregate initialization. The enhancement suggested here is to allow an aggregate service to later use a delegate service that was unavailable during initialization.
> UIMA changes would be:
> 1. add a new error handling option for getMeta failures at initialization. Currently the options at init are to disable any use of the delegate, or fail initialization and terminate the aggregate. The new option, "continue", would be ignore this failure and complete initialization of the aggregate, but mark the delegate as being in a special state, very similar to the "questionable" state described in UIMA-1127.
> 2. The difference from UIMA-1127 is that when getMeta succeeds for this delegate, the service's type system would be checked to see that it is compatible with that of the aggregate. See UIMA-1290 for details on what validation means. If valid, the delegate is marked fully operational. If the type system fails validation, and process error handling is set to continue, a new exception type would be given to the flow controller to decide how to handle the situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (UIMA-1295) Add "continue" as an error handling option for getMeta at initialization

Posted by "Marshall Schor (JIRA)" <ui...@incubator.apache.org>.
     [ https://issues.apache.org/jira/browse/UIMA-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marshall Schor updated UIMA-1295:
---------------------------------

    Affects Version/s: 2.3AS

deferred beyond 2.3.0 release

> Add "continue" as an error handling option for getMeta at initialization
> ------------------------------------------------------------------------
>
>                 Key: UIMA-1295
>                 URL: https://issues.apache.org/jira/browse/UIMA-1295
>             Project: UIMA
>          Issue Type: New Feature
>          Components: Async Scaleout
>    Affects Versions: 2.3AS
>            Reporter: Eddie Epstein
>
> In http://markmail.org/message/ceb2npk5qsmuftn4 Yosi Mass requested that UIMA support a peer-to-peer capability where services are discovered dynamically to improve load balancing, and presumably, to enhance processing by using analytics which only become available after a client has started.
> UIMA AS already supports dynamically expanding processing capability for a particular service, by simply starting additional service instances pointed at the service's existing request queue. Using appropriate error handling and/or custom flow controller options, a UIMA AS aggregate also has the capability to ignore a missing delegate service, as long as the delegate service was available during aggregate initialization. The enhancement suggested here is to allow an aggregate service to later use a delegate service that was unavailable during initialization.
> UIMA changes would be:
> 1. add a new error handling option for getMeta failures at initialization. Currently the options at init are to disable any use of the delegate, or fail initialization and terminate the aggregate. The new option, "continue", would be ignore this failure and complete initialization of the aggregate, but mark the delegate as being in a special state, very similar to the "questionable" state described in UIMA-1127.
> 2. The difference from UIMA-1127 is that when getMeta succeeds for this delegate, the service's type system would be checked to see that it is compatible with that of the aggregate. See UIMA-1290 for details on what validation means. If valid, the delegate is marked fully operational. If the type system fails validation, and process error handling is set to continue, a new exception type would be given to the flow controller to decide how to handle the situation.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.