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

DumpJournal does not protect against concurrent updates (NSS)

    Details

    • Type: Bug
    • Status: Closed - Won't Fix
    • Resolution: Unresolved
    • Affects Version/s: BIGDATA_RELEASE_1_2_3
    • Fix Version/s: None
    • Component/s: NanoSparqlServer
    • Labels:
      None

      Description

      The DumpJournal feature does not protect the index traversals against concurrent mutations from SPARQL UPDATEs. It was originally written as a standalone utility and does not include concurrency protection. It needs to wrap the indices as UnisolatedReadWriteIndex objects or (even simpler) grab the read-only views of those indices.

      Workaround: Do not apply UPDATEs when running /status?dumpJournal&dumpPages

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        I have managed to replicate the problem with a unit test in TestDumpJournal. I tried simply bracketing the dumpJournal operation with a newTx(), but that does not fix the problem. The problem is observed for the RWS but not for the WORM.

        Show
        bryanthompson bryanthompson added a comment - I have managed to replicate the problem with a unit test in TestDumpJournal. I tried simply bracketing the dumpJournal operation with a newTx(), but that does not fix the problem. The problem is observed for the RWS but not for the WORM.
        Hide
        bryanthompson bryanthompson added a comment -

        Perhaps the issue is that we are not protecting some of the internal index structures against concurrent modification when using DumpJournal? If this is just the user indices, those can be protected using a read-only view as of the last commit time. In fact, we should be able to do that with all of the index views....

        Show
        bryanthompson bryanthompson added a comment - Perhaps the issue is that we are not protecting some of the internal index structures against concurrent modification when using DumpJournal? If this is just the user indices, those can be protected using a read-only view as of the last commit time. In fact, we should be able to do that with all of the index views....
        Hide
        bryanthompson bryanthompson added a comment -

        I can no longer replicate this problem with the recent changes to support group commit in the REST API. Ticket will be reopened if we can demonstrate the problem again.

        Note: The issue can still be replicated within the TestDumpJournal test class. However the REST API logic appears to impose sufficient constraints so I am interpreting this as a test class problem (and that test is disabled).

        Show
        bryanthompson bryanthompson added a comment - I can no longer replicate this problem with the recent changes to support group commit in the REST API. Ticket will be reopened if we can demonstrate the problem again. Note: The issue can still be replicated within the TestDumpJournal test class. However the REST API logic appears to impose sufficient constraints so I am interpreting this as a test class problem (and that test is disabled).
        Hide
        bryanthompson bryanthompson added a comment -

        Update: My original comment on this ticket was correct. DumpJournal uses unisolated indices without any encapsulation. Concurrent updates will cause runtime exceptions in the DumpJournal threads.

        Show
        bryanthompson bryanthompson added a comment - Update: My original comment on this ticket was correct. DumpJournal uses unisolated indices without any encapsulation. Concurrent updates will cause runtime exceptions in the DumpJournal threads.

          People

          • Assignee:
            bryanthompson bryanthompson
            Reporter:
            bryanthompson bryanthompson
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: