UIMA
  1. UIMA
  2. UIMA-1295

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

    Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.3AS
    • Fix Version/s: None
    • Component/s: Async Scaleout
    • Labels:
      None

      Description

      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.

        Activity

        Hide
        Jerry Cwiklik added a comment -

        Defer beyond 2.4.2 Release

        Show
        Jerry Cwiklik added a comment - Defer beyond 2.4.2 Release
        Hide
        Jerry Cwiklik added a comment -

        Deferred beyond 2.4.0 release

        Show
        Jerry Cwiklik added a comment - Deferred beyond 2.4.0 release
        Hide
        Jerry Cwiklik added a comment -

        deferred beyond 2.3.1 release

        Show
        Jerry Cwiklik added a comment - deferred beyond 2.3.1 release
        Hide
        Marshall Schor added a comment -

        deferred beyond 2.3.0 release

        Show
        Marshall Schor added a comment - deferred beyond 2.3.0 release
        Hide
        Marshall Schor added a comment -

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

        Show
        Marshall Schor added a comment - Eddie - is this something for 2.3.0 release, or should we defer it?

          People

          • Assignee:
            Unassigned
            Reporter:
            Eddie Epstein
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Development