Details

      Description

      BigdataGraphFactory connect doesn't work with remote server.

      18:56:20.504 [main] DEBUG org.eclipse.jetty.client.HttpClient - Created HttpDestination[http://localhost:9999],queue=0,pool=ConnectionPool[c=0/64,a=0,i=0]
      
      
      18:56:20.507 [main] DEBUG o.e.jetty.client.HttpDestination - Queued HttpRequest[POST /bigdata/LBS/read/sparql/sparql HTTP/1.1]@676783d3 for HttpDestination[http://localhost:9999],queue=1,pool=ConnectionPool[c=0/64,a=0,i=0]
      
      

      The workaround is to create the BigdataGraphClient directly.

       g = new BigdataGraphClient("http://localhost:9999/bigdata")
      
      

        Issue Links

          Activity

          Hide
          bradbebee bradbebee added a comment -

          Close when https://github.com/SYSTAP/bigdata/pull/49 is merged into master.

          Show
          bradbebee bradbebee added a comment - Close when https://github.com/SYSTAP/bigdata/pull/49 is merged into master.
          Hide
          bryanthompson bryanthompson added a comment -

          Per the BigdataSailRemoteRepository javadoc, the proper incantation to create an instance of this class is below. Note that there is also an alternative form of this constructor to specify the useLBS option (serviceURL,useLBS). The constructor hides the setup of the HttpClient and the Executor. The same HttpClient and Executor will be used for all objects obtained from this class, including any SPARQL end point specific connection objects.
          {{

          { * <pre> * // 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();
          • }
          • </pre>
          • This pattern makes it possible to:
          • <ul>
          • <li>Obtain {@link BigdataSailRemoteRepository} objects for different sparql
          • end points on the same blazegraph server.</li>
          • <li>Those {@link BigdataSailRemoteRepository} objects are flyweight.</li>
          • <li>The {@link RemoteRepositoryManager} can be used to access additional
          • interfaces, including the multi-tenancy API and the transaction API.</li>
          • </ul>
            }}}

          I will note that these two constructors are broken. They are documented to accept a sparqlEndpointURL but are treating it as a serviceURL.

             /**
              * Constructor that simply specifies an endpoint. This class will internally
              * allocate a {@link RemoteRepositoryManager} that is scoped to the life
              * cycle of this class. The allocated {@link RemoteRepositoryManager} will be
              * closed when this {@link BigdataSailRemoteRepository} is closed.
              * <p>
              * Note: This constructor pattern is NOT flyweight.
              * 
              * @param sparqlEndpointURL
              *           The SPARQL end point URL
              */
          	public BigdataSailRemoteRepository(final String sparqlEndpointURL) {
          
          		this(sparqlEndpointURL, true/* useLBS */);
          
          	}
          
             /**
              * Constructor that simply specifies an endpoint. This class will internally
              * allocate a {@link RemoteRepositoryManager} that is scoped to the life
              * cycle of this class. The allocated {@link RemoteRepositoryManager} will be
              * closed when this {@link BigdataSailRemoteRepository} is closed.
              * <p>
              * Note: This constructor pattern is NOT flyweight.
              * 
              * @param sparqlEndpointURL
              *           The SPARQL end point URL
              * @param useLBS
              *           <code>true</code> iff the LBS pattern should be used.
              */
          	public BigdataSailRemoteRepository(final String sparqlEndpointURL,
          			final boolean useLBS) {
          
          		if (sparqlEndpointURL == null)
          			throw new IllegalArgumentException();
          
          		/*
          		 * Allocate a RemoteRepositoryManager. This is NOT a flyweight operation.
          		 * 
          		 */
          		this.our_mgr = new RemoteRepositoryManager(sparqlEndpointURL, useLBS);
          
                this.remoteRepository = our_mgr.getRepositoryForURL(sparqlEndpointURL,
                      useLBS);
          		
          	}
          
          Show
          bryanthompson bryanthompson added a comment - Per the BigdataSailRemoteRepository javadoc, the proper incantation to create an instance of this class is below. Note that there is also an alternative form of this constructor to specify the useLBS option (serviceURL,useLBS). The constructor hides the setup of the HttpClient and the Executor. The same HttpClient and Executor will be used for all objects obtained from this class, including any SPARQL end point specific connection objects. {{ { * <pre> * // 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(); } </pre> This pattern makes it possible to: <ul> <li>Obtain {@link BigdataSailRemoteRepository} objects for different sparql end points on the same blazegraph server.</li> <li>Those {@link BigdataSailRemoteRepository} objects are flyweight.</li> <li>The {@link RemoteRepositoryManager} can be used to access additional interfaces, including the multi-tenancy API and the transaction API.</li> </ul> }}} I will note that these two constructors are broken. They are documented to accept a sparqlEndpointURL but are treating it as a serviceURL. /** * Constructor that simply specifies an endpoint. This class will internally * allocate a {@link RemoteRepositoryManager} that is scoped to the life * cycle of this class. The allocated {@link RemoteRepositoryManager} will be * closed when this {@link BigdataSailRemoteRepository} is closed. * <p> * Note: This constructor pattern is NOT flyweight. * * @param sparqlEndpointURL * The SPARQL end point URL */ public BigdataSailRemoteRepository(final String sparqlEndpointURL) { this(sparqlEndpointURL, true/* useLBS */); } /** * Constructor that simply specifies an endpoint. This class will internally * allocate a {@link RemoteRepositoryManager} that is scoped to the life * cycle of this class. The allocated {@link RemoteRepositoryManager} will be * closed when this {@link BigdataSailRemoteRepository} is closed. * <p> * Note: This constructor pattern is NOT flyweight. * * @param sparqlEndpointURL * The SPARQL end point URL * @param useLBS * <code>true</code> iff the LBS pattern should be used. */ public BigdataSailRemoteRepository(final String sparqlEndpointURL, final boolean useLBS) { if (sparqlEndpointURL == null) throw new IllegalArgumentException(); /* * Allocate a RemoteRepositoryManager. This is NOT a flyweight operation. * */ this.our_mgr = new RemoteRepositoryManager(sparqlEndpointURL, useLBS); this.remoteRepository = our_mgr.getRepositoryForURL(sparqlEndpointURL, useLBS); }
          Hide
          bryanthompson bryanthompson added a comment -

          Per the above, my preference would be to get rid of both of these classes. If there is some unconstrained desired for parameterized factory method, they should operate in terms of the RemoteRepositoryManager. But there are clear downsides to this approach per the above.

          	public BigdataSailRemoteRepository(final String sparqlEndpointURL)
          
          and
          
          	public BigdataSailRemoteRepository(final String sparqlEndpointURL,final boolean useLBS)
          
          Show
          bryanthompson bryanthompson added a comment - Per the above, my preference would be to get rid of both of these classes. If there is some unconstrained desired for parameterized factory method, they should operate in terms of the RemoteRepositoryManager. But there are clear downsides to this approach per the above. public BigdataSailRemoteRepository(final String sparqlEndpointURL) and public BigdataSailRemoteRepository(final String sparqlEndpointURL,final boolean useLBS)
          Hide
          bryanthompson bryanthompson added a comment -

          I have proposed a fix for the client APIs at [1]. This has been implemented and merged to master. Handoff to bradbebee for review.

          [1] https://docs.google.com/a/systap.com/document/d/1rzLfdYZSqnXeualuRVD-ai-vgX_Lk4QZe5uj3Ge6Xzc/edit?usp=sharing

          Show
          bryanthompson bryanthompson added a comment - I have proposed a fix for the client APIs at [1] . This has been implemented and merged to master. Handoff to bradbebee for review. [1] https://docs.google.com/a/systap.com/document/d/1rzLfdYZSqnXeualuRVD-ai-vgX_Lk4QZe5uj3Ge6Xzc/edit?usp=sharing
          Hide
          bradbebee bradbebee added a comment -

          Ready to merge after code review of https://github.com/SYSTAP/bigdata/pull/49.

          Show
          bradbebee bradbebee added a comment - Ready to merge after code review of https://github.com/SYSTAP/bigdata/pull/49 .

            People

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

              Dates

              • Created:
                Updated:
                Resolved: