Uploaded image for project: 'Blazegraph (by SYSTAP)'
  1. Blazegraph (by SYSTAP)
  2. BLZG-1316

Embedded Graph Clients Query Listing and Cancellation

    Details

    • Type: Improvement
    • Status: Done
    • Priority: Medium
    • Resolution: Done
    • Affects Version/s: BLAZEGRAPH_RELEASE_1_5_1
    • Fix Version/s: BLAZEGRAPH_RELEASE_1_5_2
    • Component/s: blueprints
    • Labels:
      None

      Description

      Currently, query cancellation is only available through the REST API. This should be extended to support the blueprints implementation for BigdataGraph.

        Issue Links

          Activity

          Show
          beebs Brad Bebee added a comment - https://github.com/SYSTAP/bigdata/pull/74
          Hide
          bryanthompson bryanthompson added a comment -

          http://github.com/SYSTAP/bigdata/pull/73 was merged to master.

          I have conditionally disabled the REST API stress test due to the stochastic "namespace: EXISTS" test harness error in the master.

          I have created a new branch (TICKET_1156d) for continued work on the REST API (client and server).

          We need to coordinate work on BLZG-1126 and BLZG-1136. We should at ways to share a common execution layer. This is critical in terms of correctness (especially of error handling logic and group commit behaviors) and test coverage of the various methods.

          Show
          bryanthompson bryanthompson added a comment - http://github.com/SYSTAP/bigdata/pull/73 was merged to master. I have conditionally disabled the REST API stress test due to the stochastic "namespace: EXISTS" test harness error in the master. I have created a new branch (TICKET_1156d) for continued work on the REST API (client and server). We need to coordinate work on BLZG-1126 and BLZG-1136 . We should at ways to share a common execution layer. This is critical in terms of correctness (especially of error handling logic and group commit behaviors) and test coverage of the various methods.
          Hide
          bryanthompson bryanthompson added a comment -

          I have been toying with the notion of pushing down support for the various REST API operations. However the tasks that implement those operations, e.g., QueryServlet.SparqlUpdateTask, all have a signature that passes in the http request/response objects. See below. Some of this is intrinsic because the tasks have some behavior that is http oriented, e.g., sending back the mutation count as an XML document or the SPARQL UPDATE response as an XML document. But if we can solve this problem, then we have one entry point where tasks are submitted for execution and become listable and cancellable.

          There are other related issues for the REST API. See BLZG-14 and BLZG-1266. Both of these deal with correctness of the code paths for handling errors, operation cancellation, etc. These can be somewhat tricky and we really should strive to not have distinct code for these cases. To say nothing of the test suite coverage.

                  public SparqlUpdateTask(//
                  		final HttpServletRequest req,//
                          final HttpServletResponse resp,//
                          final String namespace, //
                          final long timestamp,//
                          final String updateStr,//
                          final BigdataRDFContext context//
                          ) {
          
          Show
          bryanthompson bryanthompson added a comment - I have been toying with the notion of pushing down support for the various REST API operations. However the tasks that implement those operations, e.g., QueryServlet.SparqlUpdateTask, all have a signature that passes in the http request/response objects. See below. Some of this is intrinsic because the tasks have some behavior that is http oriented, e.g., sending back the mutation count as an XML document or the SPARQL UPDATE response as an XML document. But if we can solve this problem, then we have one entry point where tasks are submitted for execution and become listable and cancellable. There are other related issues for the REST API. See BLZG-14 and BLZG-1266 . Both of these deal with correctness of the code paths for handling errors, operation cancellation, etc. These can be somewhat tricky and we really should strive to not have distinct code for these cases. To say nothing of the test suite coverage. public SparqlUpdateTask( // final HttpServletRequest req, // final HttpServletResponse resp, // final String namespace, // final long timestamp, // final String updateStr, // final BigdataRDFContext context // ) {
          Hide
          bryanthompson bryanthompson added a comment - - edited

          This related ticket has been worked in the TICKET_1156d branch. That branch has various changes to both the client and the server and support cancellation of not only QUERY and UPDATE but other operations submitted via the REST API.

          See github.com/SYSTAP/bigdata/pull/73

          Show
          bryanthompson bryanthompson added a comment - - edited This related ticket has been worked in the TICKET_1156d branch. That branch has various changes to both the client and the server and support cancellation of not only QUERY and UPDATE but other operations submitted via the REST API. See github.com/SYSTAP/bigdata/pull/73

            People

            • Assignee:
              beebs Brad Bebee
              Reporter:
              beebs Brad Bebee
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: