Changed the datasource.properties file to include specification for the SPARQL Endpoint.
SPARQL_EP_url = http://biomoby.elmonline.ca/sparql
SPARQL_EP_query_param_name = query
SPARQL_EP_misc_params = { \
"default-graph-uri": "sandbox", \
"should-sponge": "", \
"format": "text/html", \
"debug": "on" \
}
SPARQL_EP_url specifies the SPARQL Endpoint URL
SPARQL_EP_query_param_name specifies the name of the query parameter used by the SPARQL Endpoint.
ie. the name in the name/value pairs used when submitting a SPARQL query as a URL parameter
SPARQL_EP_misc_params is a JSON object with all the name/value pairs that the SPARQL Endpoint needs for URL Parameters
These specifications are used to set the same parameters kept in a SPARQL_EP_params JSON object in the ed_connotea_patched.js
Showing posts with label SPARQL Endpoint. Show all posts
Showing posts with label SPARQL Endpoint. Show all posts
Monday, August 18, 2008
Friday, July 18, 2008
Error Handling
Getting 504 Errors from our Virtuoso OpenLink SPARQL Endpoint at biomoby.elmonline.ca/sparql
And the Tomcat Manager's down.
So I've taken this opportunity to test out some error-handling in ED. Mostly just refining the E-mail function I have set up to e-mail to ed.developers@gmail.com any errors that may popup in the SPARQLTaggingServlet. Usually it comes down to an error in trying connect to the SPARQL Endpoint in which case I fire off an E-mail to the developers gmail with
-the Response Code
-tagging XML
-Time of Error
-Extra Information (Insert statement, HTML returned from the connection (usually contains some clue as to what happenned) and some information about where the error occurred
Put in a variable and some if statements to activate and deactivate the use of the SPARQL Endpoint in case it goes down, but we still want ED to work with just ED Database on arch. In addition to this, I've decided that any errors codes returned from the SPARQLTaggingServlets or Timeouts while submitting - I'll just let it go through to connotea anyways and hide the fact that there was an error from the user.
Reasoning:
1) The tags were submitted to ED Database via Jena already
2) If there was an error in the SPARQLTaggingServlet - it has been e-mailed to the developer's email, recorded and I will know about it
3) People can still keep using ED even if the SPARQL Endpoint goes down
which seems to be happenning a lot lately
And the Tomcat Manager's down.
So I've taken this opportunity to test out some error-handling in ED. Mostly just refining the E-mail function I have set up to e-mail to ed.developers@gmail.com any errors that may popup in the SPARQLTaggingServlet. Usually it comes down to an error in trying connect to the SPARQL Endpoint in which case I fire off an E-mail to the developers gmail with
-the Response Code
-tagging XML
-Time of Error
-Extra Information (Insert statement, HTML returned from the connection (usually contains some clue as to what happenned) and some information about where the error occurred
Put in a variable and some if statements to activate and deactivate the use of the SPARQL Endpoint in case it goes down, but we still want ED to work with just ED Database on arch. In addition to this, I've decided that any errors codes returned from the SPARQLTaggingServlets or Timeouts while submitting - I'll just let it go through to connotea anyways and hide the fact that there was an error from the user.
Reasoning:
1) The tags were submitted to ED Database via Jena already
2) If there was an error in the SPARQLTaggingServlet - it has been e-mailed to the developer's email, recorded and I will know about it
3) People can still keep using ED even if the SPARQL Endpoint goes down
which seems to be happenning a lot lately
Labels:
email,
error,
Error handling,
SPARQL,
SPARQL Endpoint,
SPARQLTaggingServlet
Subscribe to:
Posts (Atom)