[Mulgara-dev] CONSTRUCT query regression?

[Hugh Cayless]

Hi.  I have a mulgara db that supports a webapp, and since I upgraded to 1.9 from 1.7, certain queries no longer function.  For example:

prefix dc: <http://purl.org/dc/terms/>
construct {?a dc:identifier ?b}
from <rmi://localhost/papyri.info#pi>
where { <http://papyri.info/hgv/SB_24> dc:hasPart ?a .
?a dc:identifier ?b .
filter regex(str(?b), "^http:")}

On the production server (just downgraded back to 2.1.7):
http://papyri.info/mulgara/sparql/?query=prefix%20dc%3A%20%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0Aconstruct%20%7B%3Fa%20dc%3Aidentifier%20%3Fb%7D%0Afrom%20%3Crmi%3A%2F%2Flocalhost%2Fpapyri.info%23pi%3E%0Awhere%20%7B%20%3Chttp%3A%2F%2Fpapyri.info%2Fhgv%2FSB_24%3E%20dc%3AhasPart%20%3Fa%20.%0A%3Fa%20dc%3Aidentifier%20%3Fb%20.%0Afilter%20regex%28str%28%3Fb%29%2C%20%22%5Ehttp%3A%22%29%7D

On the dev server (still at 2.1.9), I get
http://dev.papyri.info/mulgara/sparql/?query=prefix%20dc%3A%20%3Chttp%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F%3E%0Aconstruct%20%7B%3Fa%20dc%3Aidentifier%20%3Fb%7D%0Afrom%20%3Crmi%3A%2F%2Flocalhost%2Fpapyri.info%23pi%3E%0Awhere%20%7B%20%3Chttp%3A%2F%2Fpapyri.info%2Fhgv%2FSB_24%3E%20dc%3AhasPart%20%3Fa%20.%0A%3Fa%20dc%3Aidentifier%20%3Fb%20.%0Afilter%20regex%28str%28%3Fb%29%2C%20%22%5Ehttp%3A%22%29%7D

I get errors like the following in the log:

2010-11-06 07:59:07,883 WARN  ProtocolServlet - Error closing: TransactionalAnswer closed
org.mulgara.query.TuplesException: TransactionalAnswer closed
        at org.mulgara.resolver.TransactionalAnswer.notClosed(TransactionalAnswer.java:336)
        at org.mulgara.resolver.TransactionalAnswer.close(TransactionalAnswer.java:118)
        at org.mulgara.query.GraphAnswer.close(GraphAnswer.java:149)
        at org.mulgara.protocol.http.ProtocolServlet.doResponse(ProtocolServlet.java:324)
        at org.mulgara.protocol.http.ProtocolServlet.doGet(ProtocolServlet.java:211)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
        at org.mulgara.protocol.http.ProtocolServlet.service(ProtocolServlet.java:201)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:527)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:423)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:930)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:358)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:183)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:866)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:126)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:113)
        at org.eclipse.jetty.server.Server.handle(Server.java:347)
        at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:594)
        at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:1042)
        at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:549)
        at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:211)
        at org.eclipse.jetty.server.HttpConnection.handle(HttpConnection.java:424)
        at org.eclipse.jetty.server.nio.BlockingChannelConnector$BlockingChannelEndPoint.run(BlockingChannelConnector.java:291)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$2.run(QueuedThreadPool.java:436)
        at java.lang.Thread.run(Thread.java:619)

The one change I made is to StreamedRdfXmlAnswer to have it not use entities with an internal DTD subset, because we occasionally have URLs with urlencoded characters in them (which look like busted parameter entities to an XML processor).  I suspect the latter change is at the root of the failure, but I won't have time to look at it until next week.  Any ideas?

Thanks,
Hugh

/**
 * Hugh A. Cayless, Ph.D.
 * NYU Digital Library Technology Services
 * http://papyri.info
 */