Stanbol
  1. Stanbol
  2. STANBOL-343

Long term operations (Jobs) for reasoning services

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 0.9.0-incubating
    • Component/s: Reasoners
    • Labels:
      None

      Description

      The current implementation of the reasoning services execute the operation in real time.
      Reasoning tasks are often time consuming, and in some cases cannot be completed in the lifetime of a http request.
      For this reason, there is the need of a way of running reasoning operations in the background, and a web service to ping the running operation and retrieve the result, when ready.

        Activity

        Hide
        Enrico Daga added a comment -

        The current implementation is stable, I will start to work on this issue on a separate branch, and let the current version in trunk until this is solved.

        Show
        Enrico Daga added a comment - The current implementation is stable, I will start to work on this issue on a separate branch, and let the current version in trunk until this is solved.
        Hide
        Enrico Daga added a comment - - edited

        As next step we need to refactor the ReasoningServiceExecutor class in the web module, in order to prepare it to be an implementation of Callable to be given to the JobManager:

        • Remove references to JAX-RS types from ReasoningServiceExecutor (decoupling from JAX-RS Resource)
        • Create two new types:
          • ReasoningServiceResult, to be processed by the JAX-RS resource. In perspective this would be the outcome of the job (Callable<ReasoningServiceResult>)
          • ResponseTaskBuilder, this class would prepare the Response object, used by the ReasoningServiceTaskResource with data from a ReasoningServiceResult.
        Show
        Enrico Daga added a comment - - edited As next step we need to refactor the ReasoningServiceExecutor class in the web module, in order to prepare it to be an implementation of Callable to be given to the JobManager: Remove references to JAX-RS types from ReasoningServiceExecutor (decoupling from JAX-RS Resource) Create two new types: ReasoningServiceResult, to be processed by the JAX-RS resource. In perspective this would be the outcome of the job (Callable<ReasoningServiceResult>) ResponseTaskBuilder, this class would prepare the Response object, used by the ReasoningServiceTaskResource with data from a ReasoningServiceResult.
        Hide
        Enrico Daga added a comment -

        The Jobs API have been moved to a dedicated module: Stanbol Commons Jobs (see STANBOL-383). The /reasoners endpoint implements this api.
        A set of runtime tests on the services have been prepared in /services-test, a shared class between runtime tests is in /test. Some of these (offline ones) could be added to the shares integration-tests module, after putting Reasoners in the full launcher (but decoupling of i-t from a single module is in discussion STANBOL-289).
        Tests are actually configured to run with a kres launcher (so you need to build that before running the tests).

        At this stage I would move this to /trunk, close this issue and then create dedicated issues for improvements.

        Show
        Enrico Daga added a comment - The Jobs API have been moved to a dedicated module: Stanbol Commons Jobs (see STANBOL-383 ). The /reasoners endpoint implements this api. A set of runtime tests on the services have been prepared in /services-test, a shared class between runtime tests is in /test. Some of these (offline ones) could be added to the shares integration-tests module, after putting Reasoners in the full launcher (but decoupling of i-t from a single module is in discussion STANBOL-289 ). Tests are actually configured to run with a kres launcher (so you need to build that before running the tests). At this stage I would move this to /trunk, close this issue and then create dedicated issues for improvements.
        Hide
        Enrico Daga added a comment -

        As the previous comment says, this can be marked resolved, then specific things will be managed on separate issues.

        Show
        Enrico Daga added a comment - As the previous comment says, this can be marked resolved, then specific things will be managed on separate issues.

          People

          • Assignee:
            Enrico Daga
            Reporter:
            Enrico Daga
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development