jpmccu / sadi

Automatically exported from code.google.com/p/sadi
0 stars 0 forks source link

Service creates exception when submitted to a virtuoso backed registry #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
What steps will reproduce the problem?
1. Create a new sadi registry that is backed with with virtuoso server
2. Register http://138.119.12.49:8080/FISHTOX-SADIServices/DNA2RNATranscriber

What is the expected output? What do you see instead?

The following error in the log....

2011-09-26 15:45:54 registry [ERROR] registration failed for 
http://138.119.12.49:8080/FISHTOX-SADIServices/DNA2RNATranscriber: 
virtuoso.jdbc3.VirtuosoException: SQ074: Line 1: SP030: SPARQL compiler, line 
1: syntax error at '<' before 'Mon'
com.hp.hpl.jena.shared.JenaException: virtuoso.jdbc3.VirtuosoException: SQ074: 
Line 1: SP030: SPARQL compiler, line 1: syntax error at '<' before 'Mon'
    at virtuoso.jena.driver.VirtGraph.graphBaseFind(VirtGraph.java:388)
    at com.hp.hpl.jena.graph.impl.GraphBase.find(GraphBase.java:240)
    at com.hp.hpl.jena.graph.impl.GraphBase.graphBaseFind(GraphBase.java:260)
    at com.hp.hpl.jena.graph.impl.GraphBase.find(GraphBase.java:257)
    at com.hp.hpl.jena.rdf.model.impl.ModelCom.listStatements(ModelCom.java:378)
    at com.hp.hpl.jena.rdf.model.impl.ModelCom.listStatements(ModelCom.java:383)
    at com.hp.hpl.jena.rdf.model.impl.ResourceImpl.listProperties(ResourceImpl.java:160)
    at com.hp.hpl.jena.util.ResourceUtils.reachableClosure(ResourceUtils.java:251)
    at ca.wilkinsonlab.sadi.registry.Registry.unregisterService(Registry.java:457)
    at ca.wilkinsonlab.sadi.registry.Registry.registerService(Registry.java:349)
    at org.apache.jsp.register.index_jsp._jspService(index_jsp.java:133)
    at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:419)
    at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:391)
    at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:722)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:240)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:164)
    at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:462)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:164)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
    at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:562)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:395)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:250)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:188)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:302)
    at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
    at java.lang.Thread.run(Thread.java:662)
Caused by: virtuoso.jdbc3.VirtuosoException: SQ074: Line 1: SP030: SPARQL 
compiler, line 1: syntax error at '<' before 'Mon'
    at virtuoso.jdbc3.VirtuosoResultSet.process_result(Unknown Source)
    at virtuoso.jdbc3.VirtuosoResultSet.<init>(Unknown Source)
    at virtuoso.jdbc3.VirtuosoPreparedStatement.<init>(Unknown Source)
    at virtuoso.jdbc3.VirtuosoConnection.prepareStatement(Unknown Source)
    at virtuoso.jdbc3.VirtuosoConnection.prepareStatement(Unknown Source)
    at virtuoso.jena.driver.VirtGraph.graphBaseFind(VirtGraph.java:384)
    ... 32 more

What version of the product are you using? On what operating system?

Latest version of sadi-registry...
Virtuoso...Version: 06.01.3127 Build: Aug 2 2010

Original issue reported on code.google.com by matthew....@gmail.com on 26 Sep 2011 at 6:57

GoogleCodeExporter commented 9 years ago
This is not reproducible with an empty registry.  Note in the exception trace 
that the error is actually thrown while trying to unregister the service.  
Also, the server 138.119.12.49 is no longer responding to external requests (I 
was able to connect to it once and successfully register the service, but no 
longer).

That said, I've seen this problem before.  It is possible to get data into 
Virtuoso that you can't then extract with the Jena driver.  Even if you used 
the Jena driver to put the data in.  In the past, I've seen this with 
properties that weren't valid URIs.  I suspect if you query the service 
definition in your current registry (you'll have to use the Virtuoso SPARQL 
endpoint, since the Jena interface is the thing throwing the error), you'll 
find the problem.  You can then use the SPARQL endpoint or the command-line 
isql client to remove the offending statement(s), at which point you'll be able 
to use the Jena driver again.

In short: not a SADI problem, but rather a bug in the Virtuoso Jena driver.  
You could come up with a contained example (i.e.: use Jena to insert this data 
into an empty graph, try to use Jena to query the same data, throw exception) 
and submit it as a bug to Virtuoso.

Please reopen this if the above turns out not to be on point and you've got 
more to add.

Original comment by elmccar...@gmail.com on 26 Sep 2011 at 7:20

GoogleCodeExporter commented 9 years ago
I had problems exporting the Virtuoso graph for the registry using Jena, which 
fits with your explanation. I will switch back to a registry backed by a RDF 
file. I was having problems with my sadi-registry emptying itself. I though 
using virtuoso might help. I suspect it is a file locking issue, as it happens 
when you try to view or add services to the registry, and SHARE is running. 
It's really hard to reproduce this and submit a bug report though.

Original comment by matthew....@gmail.com on 26 Sep 2011 at 7:26

GoogleCodeExporter commented 9 years ago
Well, we are using a Virtuoso-backed registry for the main SADI registry and 
it's been stable.  The problems are only cause by service definitions/class 
definitions that are actually invalid.  Try this query to find problematic 
statements:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX sadi: <http://sadiframework.org/ontologies/sadi.owl#>
SELECT DISTINCT ?service ?p
WHERE
{
  ?service rdf:type sadi:Service .
  ?service sadi:decoratesWith ?decoration .
  ?decoration owl:onProperty ?p .
  ?decoration owl:someValuesFrom ?valuesFrom .
  FILTER (regex(str(?p), "[,< ]") || regex(str(?valuesFrom), "[,< ]"))
}

Once you've found them, deleting them is trivial if the SPARQL endpoint is 
setup for SPARUL.  Otherwise you'll have to do it from the isql client.

Original comment by elmccar...@gmail.com on 26 Sep 2011 at 7:42

GoogleCodeExporter commented 9 years ago
The services registered ok to the main repro. I guess the likely explanation 
then is that the virtuoso driver is not playing ball with the older version of 
virtuoso (Aug 2 2010). What version are you using there? 

Original comment by matthew....@gmail.com on 26 Sep 2011 at 7:51

GoogleCodeExporter commented 9 years ago
It registered fine for me locally in Virtuoso 6.  The version of Virtuoso on 
sadiframework.org is 5.0.11.

It really looks like the ontology defining your service classes (or one that it 
imports) changed between the time when you first registered your service and 
the time that you re-registered it.  The stack trace pasted in the original bug 
report shows the service being unregistered, so there was already a definition 
there.  That definition will be the one that was problematic.  And it should 
still be in there, because it can't be removed by through the Jena interface.

Original comment by elmccar...@gmail.com on 26 Sep 2011 at 7:55