Details

    • Type: Bug
    • Status: Done
    • Priority: Medium
    • Resolution: Done
    • Affects Version/s: None
    • Fix Version/s: BLAZEGRAPH_RELEASE_1_5_3
    • Component/s: None
    • Labels:
      None

      Description

      The following issue was reported on the Blazegraph mailing list:

      When evaluating the query

      PREFIX  dc:   <http://purl.org/dc/elements/1.1/>
      PREFIX  rdfs: <http://www.w3.org/2000/01/rdf-schema#>
      PREFIX  foaf: <http://xmlns.com/foaf/0.1/>
      PREFIX  owl:  <http://www.w3.org/2002/07/owl#>
      PREFIX  xsd:  <http://www.w3.org/2001/XMLSchema#>
      PREFIX  rdf:  <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
      PREFIX lubm: <http://swat.cse.lehigh.edu/onto/univ-bench.owl#>
      
      SELECT  *
      WHERE
        { { ?_v0 
      (((((rdfs:subClassOf|owl:equivalentClass)|^owl:equivalentClass)|((owl:intersectionOf/(rdf:rest)*)/rdf:first))|((owl:onProperty/((((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty)|(((owl:inverseOf|^owl:inverseOf)/(((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty))*)/(owl:inverseOf|^owl:inverseOf))))*)/(^owl:onProperty|rdfs:domain)))|((((owl:onProperty/((((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty)|(((owl:inverseOf|^owl:inverseOf)/(((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty))*)/(owl:inverseOf|^owl:inverseOf))))*)/(owl:inverseOf|^owl:inverseOf))/(((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty))*)/rdfs:range))* 
      lubm:Student .
              {   { ?p rdf:type ?_v0}
                UNION
                  { ?_v1 
      ((((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty)|(((owl:inverseOf|^owl:inverseOf)/(((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty))*)/(owl:inverseOf|^owl:inverseOf))))*/(^owl:onProperty|rdfs:domain) 
      ?_v0 .
                    ?p ?_v1 _:b0
                  }
              }
            UNION
              { ?_v1 
      ((((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty)|(((owl:inverseOf|^owl:inverseOf)/(((rdfs:subPropertyOf|owl:equivalentProperty)|^owl:equivalentProperty))*)/(owl:inverseOf|^owl:inverseOf))))*/rdfs:range 
      ?_v0 .
                _:b1 ?_v1 ?p
              }
          }
        }
      

      against a database containing the LUBM ontology and University0_0.owl, the following NPW exception is thrown:

      java.util.concurrent.ExecutionException: 
      java.util.concurrent.ExecutionException: 
      org.openrdf.query.QueryEvaluationException: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at java.util.concurrent.FutureTask.report(FutureTask.java:122)
              at java.util.concurrent.FutureTask.get(FutureTask.java:188)
              at 
      com.bigdata.rdf.sail.webapp.BigdataServlet.submitApiTask(BigdataServlet.java:281)
              at 
      com.bigdata.rdf.sail.webapp.QueryServlet.doSparqlQuery(QueryServlet.java:632)
              at 
      com.bigdata.rdf.sail.webapp.QueryServlet.doPost(QueryServlet.java:259)
              at 
      com.bigdata.rdf.sail.webapp.RESTServlet.doPost(RESTServlet.java:248)
              at 
      com.bigdata.rdf.sail.webapp.MultiTenancyServlet.doPost(MultiTenancyServlet.java:138)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
              at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
              at 
      org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:769)
              at 
      org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
              at 
      org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
              at 
      org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:577)
              at 
      org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
              at 
      org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1125)
              at 
      org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
              at 
      org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
              at 
      org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1059)
              at 
      org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
              at 
      org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
              at 
      org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
              at 
      org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
              at org.eclipse.jetty.server.Server.handle(Server.java:497)
              at 
      org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
              at 
      org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:248)
              at 
      org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
              at 
      org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:610)
              at 
      org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:539)
              at java.lang.Thread.run(Thread.java:745)
      Caused by: java.util.concurrent.ExecutionException: 
      org.openrdf.query.QueryEvaluationException: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at java.util.concurrent.FutureTask.report(FutureTask.java:122)
              at java.util.concurrent.FutureTask.get(FutureTask.java:188)
              at 
      com.bigdata.rdf.sail.webapp.QueryServlet$SparqlQueryTask.call(QueryServlet.java:830)
              at 
      com.bigdata.rdf.sail.webapp.QueryServlet$SparqlQueryTask.call(QueryServlet.java:649)
              at 
      com.bigdata.rdf.task.ApiTaskForIndexManager.call(ApiTaskForIndexManager.java:68)
              at java.util.concurrent.FutureTask.run(FutureTask.java:262)
              at 
      java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
              at 
      java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
              ... 1 more
      Caused by: org.openrdf.query.QueryEvaluationException: 
      java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
      java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at 
      com.bigdata.rdf.sail.Bigdata2Sesame2BindingSetIterator.hasNext(Bigdata2Sesame2BindingSetIterator.java:188)
              at 
      info.aduna.iteration.IterationWrapper.hasNext(IterationWrapper.java:68)
              at org.openrdf.query.QueryResults.report(QueryResults.java:155)
              at 
      org.openrdf.repository.sail.SailTupleQuery.evaluate(SailTupleQuery.java:76)
              at 
      com.bigdata.rdf.sail.webapp.BigdataRDFContext$TupleQueryTask.doQuery(BigdataRDFContext.java:1705)
              at 
      com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.innerCall(BigdataRDFContext.java:1562)
              at 
      com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.call(BigdataRDFContext.java:1527)
              at 
      com.bigdata.rdf.sail.webapp.BigdataRDFContext$AbstractQueryTask.call(BigdataRDFContext.java:699)
              ... 4 more
      Caused by: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at 
      com.bigdata.relation.accesspath.BlockingBuffer$BlockingIterator.checkFuture(BlockingBuffer.java:1523)
              at 
      com.bigdata.relation.accesspath.BlockingBuffer$BlockingIterator._hasNext(BlockingBuffer.java:1710)
              at 
      com.bigdata.relation.accesspath.BlockingBuffer$BlockingIterator.hasNext(BlockingBuffer.java:1563)
              at 
      com.bigdata.striterator.AbstractChunkedResolverator._hasNext(AbstractChunkedResolverator.java:365)
              at 
      com.bigdata.striterator.AbstractChunkedResolverator.hasNext(AbstractChunkedResolverator.java:341)
              at 
      com.bigdata.rdf.sail.Bigdata2Sesame2BindingSetIterator.hasNext(Bigdata2Sesame2BindingSetIterator.java:134)
              ... 11 more
      Caused by: java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: java.util.concurrent.ExecutionException: 
      java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at java.util.concurrent.FutureTask.report(FutureTask.java:122)
              at java.util.concurrent.FutureTask.get(FutureTask.java:188)
              at 
      com.bigdata.relation.accesspath.BlockingBuffer$BlockingIterator.checkFuture(BlockingBuffer.java:1454)
              ... 16 more
      Caused by: java.lang.RuntimeException: 
      java.util.concurrent.ExecutionException: java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at 
      com.bigdata.rdf.sail.RunningQueryCloseableIterator.checkFuture(RunningQueryCloseableIterator.java:59)
              at 
      com.bigdata.rdf.sail.RunningQueryCloseableIterator.close(RunningQueryCloseableIterator.java:73)
              at 
      com.bigdata.rdf.sail.RunningQueryCloseableIterator.hasNext(RunningQueryCloseableIterator.java:82)
              at 
      com.bigdata.striterator.ChunkedWrappedIterator.hasNext(ChunkedWrappedIterator.java:197)
              at 
      com.bigdata.striterator.AbstractChunkedResolverator$ChunkConsumerTask.call(AbstractChunkedResolverator.java:222)
              at 
      com.bigdata.striterator.AbstractChunkedResolverator$ChunkConsumerTask.call(AbstractChunkedResolverator.java:197)
              ... 4 more
      Caused by: java.util.concurrent.ExecutionException: java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at com.bigdata.util.concurrent.Haltable.get(Haltable.java:273)
              at 
      com.bigdata.bop.engine.AbstractRunningQuery.get(AbstractRunningQuery.java:1511)
              at 
      com.bigdata.bop.engine.AbstractRunningQuery.get(AbstractRunningQuery.java:104)
              at 
      com.bigdata.rdf.sail.RunningQueryCloseableIterator.checkFuture(RunningQueryCloseableIterator.java:46)
              ... 9 more
      Caused by: java.lang.Exception: 
      task=ChunkTask{query=12f11bc0-b22a-48c8-89f7-a3603bae639a,bopId=58,partitionId=-1,sinkId=75,altSinkId=null}, 
      cause=java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at 
      com.bigdata.bop.engine.ChunkedRunningQuery$ChunkTask.call(ChunkedRunningQuery.java:1337)
              at 
      com.bigdata.bop.engine.ChunkedRunningQuery$ChunkTaskWrapper.run(ChunkedRunningQuery.java:896)
              at 
      java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
              at java.util.concurrent.FutureTask.run(FutureTask.java:262)
              at 
      com.bigdata.concurrent.FutureTaskMon.run(FutureTaskMon.java:63)
              at 
      com.bigdata.bop.engine.ChunkedRunningQuery$ChunkFutureTask.run(ChunkedRunningQuery.java:791)
              ... 3 more
      Caused by: java.util.concurrent.ExecutionException: 
      java.lang.RuntimeException: cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at java.util.concurrent.FutureTask.report(FutureTask.java:122)
              at java.util.concurrent.FutureTask.get(FutureTask.java:188)
              at 
      com.bigdata.bop.engine.ChunkedRunningQuery$ChunkTask.call(ChunkedRunningQuery.java:1317)
              ... 8 more
      Caused by: java.lang.RuntimeException: 
      cause=java.lang.NullPointerException, 
      state=JVMHashJoinUtility{open=false,joinType=Normal,joinVars=[],outputDistinctJVs=true,size=20,considered(left=26,right=312,joins=312)}
              at 
      com.bigdata.bop.join.JVMHashJoinUtility.launderThrowable(JVMHashJoinUtility.java:1406)
              at 
      com.bigdata.bop.join.JVMHashJoinUtility.acceptSolutions(JVMHashJoinUtility.java:431)
              at 
      com.bigdata.bop.join.HashIndexOp$ChunkTask.acceptSolutions(HashIndexOp.java:433)
              at 
      com.bigdata.bop.join.HashIndexOp$ChunkTask.call(HashIndexOp.java:338)
              at 
      com.bigdata.bop.join.HashIndexOp$ChunkTask.call(HashIndexOp.java:237)
              at java.util.concurrent.FutureTask.run(FutureTask.java:262)
              at 
      com.bigdata.bop.engine.ChunkedRunningQuery$ChunkTask.call(ChunkedRunningQuery.java:1316)
              ... 8 more
      Caused by: java.lang.NullPointerException
              at 
      com.bigdata.bop.join.JVMHashJoinUtility.acceptSolutions(JVMHashJoinUtility.java:410)
              ... 13 more
      

      I was able to reproduce this behavior 1.5.2 (triples mode, no inference).

        Issue Links

          Activity

          Hide
          michaelschmidt michaelschmidt added a comment -

          Trying to minimize the example, I came up with the following example leading to an NPE in exactly the same line of code:

          PREFIX  rdfs: <http://www.w3.org/2000/01/rdf-schema#>
          PREFIX  owl:  <http://www.w3.org/2002/07/owl#>
          
          SELECT  *
          WHERE
          { 
             ?_v1 (rdfs:subPropertyOf | owl:inverseOf*)* ?_v0 .
          }
          

          over database

          <http://S1> rdfs:subPropertyOf <http://S2> .
          <http://S2> rdfs:subPropertyOf <http://S3> .
          

          The problem is that calling "if (index.add(bset) == null) {" in JVMHashJoinUtility.acceptSolutions(JVMHashJoinUtility.java:410) yields an NPE, since index is null.

          Show
          michaelschmidt michaelschmidt added a comment - Trying to minimize the example, I came up with the following example leading to an NPE in exactly the same line of code: PREFIX rdfs: <http: //www.w3.org/2000/01/rdf-schema#> PREFIX owl: <http: //www.w3.org/2002/07/owl#> SELECT * WHERE { ?_v1 (rdfs:subPropertyOf | owl:inverseOf*)* ?_v0 . } over database <http: //S1> rdfs:subPropertyOf <http://S2> . <http: //S2> rdfs:subPropertyOf <http://S3> . The problem is that calling "if (index.add(bset) == null) {" in JVMHashJoinUtility.acceptSolutions(JVMHashJoinUtility.java:410) yields an NPE, since index is null.
          Hide
          bryanthompson bryanthompson added a comment -

          The root cause is that the parent query is issuing sub-query requests. The subquery requests use a hash index / hash join pattern. However, the queryID used to locate the IHashJoinUtility object is the queryID of the parent query. This is the same each time the subquery is evaluated. Since the sub-query is evaluated multiple times, it winds up using the same IHashJoinUtility object. The hash index operator sets up the IHashJoinUtility object if it is not found in the IQueryAttributes identified by the queryID in the NamedSolutionSetRef object used to locate the hash index. However, the hash join operator is clearing the reference for the right hand side when it completes. Thus, on the 2nd+ sub-query invocation the IHashJoinUtility object is reused by the right hand side has become null. The NPE is thrown when that null value is dereferenced.

          Show
          bryanthompson bryanthompson added a comment - The root cause is that the parent query is issuing sub-query requests. The subquery requests use a hash index / hash join pattern. However, the queryID used to locate the IHashJoinUtility object is the queryID of the parent query. This is the same each time the subquery is evaluated. Since the sub-query is evaluated multiple times, it winds up using the same IHashJoinUtility object. The hash index operator sets up the IHashJoinUtility object if it is not found in the IQueryAttributes identified by the queryID in the NamedSolutionSetRef object used to locate the hash index. However, the hash join operator is clearing the reference for the right hand side when it completes. Thus, on the 2nd+ sub-query invocation the IHashJoinUtility object is reused by the right hand side has become null. The NPE is thrown when that null value is dereferenced.
          Hide
          bryanthompson bryanthompson added a comment -

          I propose a change to the NamedSolutionSetRef to permit the queryID to be null. When null, it will refer to the current query. This will make it possible to reuse the same query plan and still resolve a different hash index each time the sub-query plan is evaluated for the property path expression.

          This is in github in BLZG-1493-bbt as a branch off of master. This branch is gone through CI and is clear for all except one test that was checking the NamedSolutionSetRef constructor for correct rejection.

          I am going to document the code and propagate the changes made to HashIndexOpBase and SolutionSetHashJoin to the other classes that use the NamedSolutionSetRef to locate the IHashJoinUtility object. For reference, those changes are:

          HashIndexBaseOp and SolutionSetHashJoinOp (the change is the same).

                          final IQueryAttributes attrs = context
                                  .getQueryAttributes(namedSetRef.getQueryId()==null?context.getRunningQuery().getQueryId():namedSetRef.getQueryId());
          
          Show
          bryanthompson bryanthompson added a comment - I propose a change to the NamedSolutionSetRef to permit the queryID to be null. When null, it will refer to the current query. This will make it possible to reuse the same query plan and still resolve a different hash index each time the sub-query plan is evaluated for the property path expression. This is in github in BLZG-1493 -bbt as a branch off of master. This branch is gone through CI and is clear for all except one test that was checking the NamedSolutionSetRef constructor for correct rejection. I am going to document the code and propagate the changes made to HashIndexOpBase and SolutionSetHashJoin to the other classes that use the NamedSolutionSetRef to locate the IHashJoinUtility object. For reference, those changes are: HashIndexBaseOp and SolutionSetHashJoinOp (the change is the same). final IQueryAttributes attrs = context .getQueryAttributes(namedSetRef.getQueryId()== null ?context.getRunningQuery().getQueryId():namedSetRef.getQueryId());
          Hide
          bryanthompson bryanthompson added a comment - - edited

          I have committed an alternative approach for BLZG-1493. I have applied the changes instead to BOpContext.getRunningQuery(UUID) and getMemoryManager(UUID). When the UUID is null, they return the current query. This handles some cases that could have resulted in NPEs with the first patch when an HTree based class tried to resolve the appropriate memory manager using context.getMemoryManager(namedSetRef.getQueryId()).

          However, this change also means that a NamedSolutionSetRef with queryId := null will use the memory manager of the child. I believe that the memory pools of the parent and child are currently independent, so the child would actually have access to as much memory as the parent in a case were a per-query memory limit had been imposed. BLZG-1500 is a new ticket for this potential issue.

          bradbebee Targeted for 1.5.3.

          Commit to github 10cf0b5fecd22aec1c1929b6f19777dbdfd326bc
          PR https://github.com/SYSTAP/bigdata/pull/163

          Show
          bryanthompson bryanthompson added a comment - - edited I have committed an alternative approach for BLZG-1493 . I have applied the changes instead to BOpContext.getRunningQuery(UUID) and getMemoryManager(UUID). When the UUID is null, they return the current query. This handles some cases that could have resulted in NPEs with the first patch when an HTree based class tried to resolve the appropriate memory manager using context.getMemoryManager(namedSetRef.getQueryId()). However, this change also means that a NamedSolutionSetRef with queryId := null will use the memory manager of the child. I believe that the memory pools of the parent and child are currently independent, so the child would actually have access to as much memory as the parent in a case were a per-query memory limit had been imposed. BLZG-1500 is a new ticket for this potential issue. bradbebee Targeted for 1.5.3. Commit to github 10cf0b5fecd22aec1c1929b6f19777dbdfd326bc PR https://github.com/SYSTAP/bigdata/pull/163
          Hide
          michaelschmidt michaelschmidt added a comment -

          Added test case to TestTickets. @Brad: ready to be merged down now (into master + 1.5.3) now.

          Show
          michaelschmidt michaelschmidt added a comment - Added test case to TestTickets. @Brad: ready to be merged down now (into master + 1.5.3) now.

            People

            • Assignee:
              michaelschmidt michaelschmidt
              Reporter:
              michaelschmidt michaelschmidt
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: