[Mulgara-dev] CONSTRUCT query regression?

Hugh Cayless hugh.cayless at nyu.edu
Wed Nov 17 22:03:14 UTC 2010


One more datum: JSON format works, but SPARQL XML format fails, just like the RDF XML.

H

On Nov 17, 2010, at 4:50 PM, Hugh Cayless wrote:

> Ok, I backed out my one change (switching off entities in the result document header) and retried, just to make sure.  I'm still getting the 500 with the message "Transaction error", no stacktrace, and nothing in the logs except for the warning I posted below.  Presumably there is an exception being thrown, but it's being swallowed.
> 
> Again, you can see the differences between the two URLs:
> 
> 1) http://goo.gl/retTJ (mulgara 2.1.7, works)
> 
> 2) http://goo.gl/1enfN (mulgara 2.1.9, doesn't work)
> 
> Data sets are identical.  You may note that even the one that works declares a bunch of unnecessary prefixes, but that's an irritant, not a showstopper.
> 
> http://goo.gl/UcjRx (#2 with &format=n3 appended, works).  So the problem would seem to be in serializing RDF XML.  
> 
> Can I provide any information to help troubleshoot this?  
> 
> Best,
> Hugh
> 
> On Nov 9, 2010, at 2:12 PM, Paul Gearon wrote:
> 
>> While the problem you've described here isn't supposed to happen, it's
>> actually just a warning (something that was supposed to happen just
>> once has actually happened twice, so it's letting you know about it).
>> 
>> Are you getting different results from the query?
>> 
>> Paul
>> 
>> 
>> On Tue, Nov 9, 2010 at 1:05 PM, Hugh Cayless <hugh.cayless at nyu.edu> wrote:
>>> 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
>>> */
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> Mulgara-dev mailing list
>>> Mulgara-dev at mulgara.org
>>> http://lists.mulgara.org/mailman/listinfo/mulgara-dev
>>> 
>> _______________________________________________
>> Mulgara-dev mailing list
>> Mulgara-dev at mulgara.org
>> http://lists.mulgara.org/mailman/listinfo/mulgara-dev
> 
> /**
> * Hugh A. Cayless, Ph.D.
> * NYU Digital Library Technology Services
> * http://papyri.info
> */
> 
> 
> 
> _______________________________________________
> Mulgara-dev mailing list
> Mulgara-dev at mulgara.org
> http://lists.mulgara.org/mailman/listinfo/mulgara-dev

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





More information about the Mulgara-dev mailing list