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

Delay time in submitting to Connotea

Now that we've got ED submitting tagging information to the sandbox graph of the Vrituoso server, in addition to submitting it the ED Database, I've had to put in a delay to prevent the Form from submitting until all the information has been submitted to the sandbox and confirmed that it was successful.

Trouble is... this can take a while since I need to break up a submission into a SPARQL insert statement for every tag since the number types for a tag are variable. making an insert statement potentially very very long.

And if you have A LOT of tags. The wait for a response can get even longer.

I set it at 20 seconds before it times out and an error page is presented to the user.

Before I was able to add up to 6 or 7 tags between 2-4 ftypes each and it would be under 10 seconds. but just recently Ben showed me an error that he got on Entity Describer, that went past the 20 second mark.

I'll have to test the capacity of tags + ftypes I can submit before I have say it's taking too long, but if need be I can analyze how long a tag insert is going to be and start merging them together if they're short enough. Seems a waste to do a 1 tag 1 ftype insert for a whole hTTPPost.

ED SPARQL/Update

I've added in 1 new class and 1 new servlet to the org.icapture.ED.tag package.

-SPARQLTaggingServlet.java is a servlet that functions in the same way as TagManagerSaveTaggingServlet.java

-SPARQLTagManager.java is a java class that functions in the same way as the TagManager.java

When a user hits the submit button on ED - the javascript normally calls the TagManagerSaveTaggingServlet (passing into it all the tagging data in xml format as a parameter). SPARQLTaggingServlet will be used in the same way. Call it in the same way with the same xml. SPARQLTaggingServlet acts as Servlet wrapper for the main class which is SPARQLTagManager. It creates a Tagging object with that xml and passes it into SPARQLTagManager which processes it into SPARQL/Update (SPARUL) INSERT statements and posts them to a Virtuoso server via "http://biomoby.elmonline.ca/sparql" as parameters which are then executed.

If it is successful (determined inside SPARQLTagManager via response codes), all inserts were made successfully and it will return the ResponseCode from the Virtuoso Server (200 if successful, anything else otherwise) to the SPARQLTaggingServlet.