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

Refactor RemoteRepository / RemoteRepositoryManager

    Details

      Description

      The RemoteRepositoryManager needs to be available from the RemoteRepository in order to support the transaction service (which is 1:1 with the database, not the namespace). This means that the RemoteRepositoryManager can no longer extend RemoteRepository. Instead, we need to obtain a RemoteRepository from the RemoteRepositoryManager. There are already methods for this. We can also add a getRemoteRepositoryForDefaultNamespace() for convenience.

      The recommended pattern is as follows.

       // Create client for the remote service.
       final RemoteRepositoryManager mgr = new RemoteRepositoryManager(serviceURL);
       try {
         // Obtain a Sesame Repository for the default sparql endpoint on that service.
         final Repository repo = mgr.getRepositoryForDefaultNamespace().getBigdataSailRemoteRepository();
         try {
           doWork(repo);
         } finally {
           repo.close();
         }
       } finally {
         mgr.close();
       }
      

      This pattern makes it possible to:
      - Obtain BigdataSailRemoteRepository objects for different sparql end points on the same blazegraph server.
      - Those BigdataSailRemoteRepository objects are flyweight.
      - The RemoteRepositoryManager can be used to access additional interfaces, including the multi-tenancy API and the transaction API.

      See BLZG-1195 Read/write tx support in NSS and BigdataSailRemoteRepositoryConnection

        Activity

        Hide
        bryanthompson bryanthompson added a comment -

        The BigdataGraphClient uses the following convenience constructors. If we refactor per my proposal, then we can obtain the RemoteRepositoryManager from the RemoteRepository so these methods would not change.

        	public BigdataGraphClient(final RemoteRepository repo) {
        		this(repo, BigdataRDFFactory.INSTANCE);
        	}
        	
        	public BigdataGraphClient(final RemoteRepository repo, 
        			final BlueprintsValueFactory factory) {
        	    this(new BigdataSailRemoteRepository(repo), factory);
        	}
        

        The caller for these methods is currently

        				final BigdataSailNSSWrapper nss = testSails.get(key);
        				final BigdataGraph graph = new BigdataGraphClient(nss.m_repo);
        

        The BigdataSailNSSWrapper SHOULD be a test suite only class IMHO. It does not provides any means to address anything other than the default namespace in a blazegraph server instance. This is a completely unnecessary constraint. Internally the BigdataSailNSSWrapper is actually using a RemoteRepositoryManager object.

                m_repo = new RemoteRepositoryManager(m_serviceURL,
                		m_httpClient,
                        getSail().getDatabase().getIndexManager().getExecutorService());
        

        This means that we could change the type on m_repo and propagate out that type change and then the blueprint remote graph APIs would work as is, but we still would not be able to obtain a BigdataSailRemoteRepository or BigdataSailRemoteRepositoryConnection for a non-default namespace by passing in the RemoteRepository object for that namespace. (We could do this by passing in the sparqlEndpointURL and having it construct the RemoteRepositoryManager, but this is wasteful.)

        So:

        1. Change the BigdataSailNSSWrapper to type the nss field as a RemoteRepositoryManager.
        2. Refactor RemoteRepositoryManager such that it no longer extends RemoteRepository and add RemoteRepository.getRemoteRepositoryManager()
        3. Modify BigdataGraphClient to use RemoteRepositoryManager.getRepositoryForDefaultNamespace() // new method.

        At this point, we can always obtain a RemoteRepositoryManager from a RemoteRepository.

        Show
        bryanthompson bryanthompson added a comment - The BigdataGraphClient uses the following convenience constructors. If we refactor per my proposal, then we can obtain the RemoteRepositoryManager from the RemoteRepository so these methods would not change. public BigdataGraphClient(final RemoteRepository repo) { this(repo, BigdataRDFFactory.INSTANCE); } public BigdataGraphClient(final RemoteRepository repo, final BlueprintsValueFactory factory) { this(new BigdataSailRemoteRepository(repo), factory); } The caller for these methods is currently final BigdataSailNSSWrapper nss = testSails.get(key); final BigdataGraph graph = new BigdataGraphClient(nss.m_repo); The BigdataSailNSSWrapper SHOULD be a test suite only class IMHO. It does not provides any means to address anything other than the default namespace in a blazegraph server instance. This is a completely unnecessary constraint. Internally the BigdataSailNSSWrapper is actually using a RemoteRepositoryManager object. m_repo = new RemoteRepositoryManager(m_serviceURL, m_httpClient, getSail().getDatabase().getIndexManager().getExecutorService()); This means that we could change the type on m_repo and propagate out that type change and then the blueprint remote graph APIs would work as is, but we still would not be able to obtain a BigdataSailRemoteRepository or BigdataSailRemoteRepositoryConnection for a non-default namespace by passing in the RemoteRepository object for that namespace. (We could do this by passing in the sparqlEndpointURL and having it construct the RemoteRepositoryManager, but this is wasteful.) So: 1. Change the BigdataSailNSSWrapper to type the nss field as a RemoteRepositoryManager. 2. Refactor RemoteRepositoryManager such that it no longer extends RemoteRepository and add RemoteRepository.getRemoteRepositoryManager() 3. Modify BigdataGraphClient to use RemoteRepositoryManager.getRepositoryForDefaultNamespace() // new method. At this point, we can always obtain a RemoteRepositoryManager from a RemoteRepository.
        Hide
        bryanthompson bryanthompson added a comment -

        Commit 5677303f0156eb984422823d6ea7f8b920ad0ca9 (primary refactoring of the RemoteRepository).
        Commit 19eb542c3fea4e761937d1c122360563a854ffce (fixes service description test).

        I can not run the HA test suite yet due to broken test resource locations in the master.

        The blueprints and NSS test suites are green with these changes.

        Show
        bryanthompson bryanthompson added a comment - Commit 5677303f0156eb984422823d6ea7f8b920ad0ca9 (primary refactoring of the RemoteRepository). Commit 19eb542c3fea4e761937d1c122360563a854ffce (fixes service description test). I can not run the HA test suite yet due to broken test resource locations in the master. The blueprints and NSS test suites are green with these changes.
        Hide
        bryanthompson bryanthompson added a comment -

        I am able to run the HA test suite now and it is also running green (78 out of 157 tests so far are green). I am going to close this ticket pending.

        Show
        bryanthompson bryanthompson added a comment - I am able to run the HA test suite now and it is also running green (78 out of 157 tests so far are green). I am going to close this ticket pending.

          People

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

            Dates

            • Created:
              Updated:
              Resolved: