On 25/03/13 21:11, Andy Seaborne wrote:
thanks: recorded as
https://issues.apache.org/jira/browse/JENA-423

I reduced the case to

select (count (*) as ?n) where { FILTER(false) }

the key is that the app code takes one row then closes the execution
object rather than exhaust the results iterator.  If the result iterator
runs out, the singleton return hasNext = false at some point and the
autoclose mechanism works.

Unfortuately the singleton was treated as a plain iterator, not a
QueryIterator so .close didn't cascade down.

It's a warning and it's harmless.


Fixed (twice over!) - it'll be in the next nightly SNAPSHOT build for 2.10.1

     Andy


On 25/03/13 16:48, Patrick Logan wrote:
Thanks Andy. Here's an example that exhibits the behavior. When the count
is zero, the warning is printed. Commenting out the second pattern in the
where-group causes the count to be 100 and no warning is printed.

-Patrick


package com.example;

import static org.junit.Assert.assertEquals;

import java.io.IOException;

import org.junit.BeforeClass;
import org.junit.Test;

import com.hp.hpl.jena.query.QueryExecution;
import com.hp.hpl.jena.query.QueryExecutionFactory;
import com.hp.hpl.jena.query.QuerySolution;
import com.hp.hpl.jena.query.ResultSet;
import com.hp.hpl.jena.rdf.model.Model;
import com.hp.hpl.jena.rdf.model.ModelFactory;
import com.hp.hpl.jena.rdf.model.Resource;
import com.hp.hpl.jena.vocabulary.RDF;

public class JenaWarningExample {

         private static Model model;

         @BeforeClass
         public static  void setupClass() throws Exception {
                 model = ModelFactory.createDefaultModel();
                 Resource someClass =
model.createResource("urn:example.com:
SomeClass");
                 for (int i = 0; i < 100; i++) {
                         Resource instance =
model.createResource("urn:example.com:someInstance:" + i);
                         model.add(instance, RDF.type, someClass);
                 }
         }

         @Test
         public void testJenaWarning() throws IOException {
                 String query = " select (count (distinct ?instance)
as ?n)
where { " +
                                 "            ?instance a
<urn:example.com:SomeClass>
. " +
                                 "            ?instance
<urn:example.com:someProperty>
?value .    " +
                                 "        } ";
                 QueryExecution exec =
QueryExecutionFactory.create(query,
model);
                 try {
                         ResultSet results = exec.execSelect();
                         int n = 0;
                         if (results.hasNext()) {
                                 QuerySolution solution =
results.nextSolution();
                                 n =
solution.get("n").asLiteral().getInt();
                         }
                         assertEquals(0, n);
                 } finally {
                         exec.close();
                 }
         }
}





On Sat, Mar 23, 2013 at 3:35 PM, Andy Seaborne <[email protected]> wrote:

On 23/03/13 21:18, Patrick Logan wrote:

Using 2.10.0 jena.core and arq with an in-memory model, I am getting a
warning:

WARN  [2013-03-23 14:06:34,218]
com.hp.hpl.jena.sparql.engine.**iterator.QueryIteratorCheck: Open
iterator:
QueryIterSingleton/40500

...when closing the QueryExecution for the following query:

select (count(distinct ?a) as ?n)
where {
      ?a a <urn:example.com:Something> .
      ?a <urn:example.com:hasSomethingE**lse> ?c .
}

In this case the count happens to be zero.

If I take out the second pattern in the where clause, the count is
2000-something and there is no warning about an open iterator.

The last bit of the stack trace looks like:

QueryIteratorCheck.dump(**ExecutionContext, boolean) line: 87
QueryIteratorCheck.**checkForOpenIterators(**ExecutionContext) line: 59
QueryIteratorCheck.close() line: 50
QueryIteratorCloseable(**QueryIteratorWrapper).**closeIterator()
line: 50
QueryIteratorCloseable(**QueryIteratorBase).close() line: 185
QueryIteratorCloseable.close() line: 39
QueryExecutionBase.close() line: 168


I tried to recreate this but, whatever I try with the command line
tools,
it works find for me.  How was the query called and closed?

Is it a plain in-memory model or an inference model?

A complete, minimal example would be helpful.

         Andy





Reply via email to