exception from http://trust.utep.edu/sparql-pml/query/index

0 views
Skip to first unread message

Timothy Lebo

unread,
Jul 20, 2010, 4:41:53 PM7/20/10
to jar...@miners.utep.edu, Paulo Pinheiro da Silva, infere...@googlegroups.com
Jarora,


I queried:

select distinct ?type
where {
?s a ?type
}


against:

http://trust.utep.edu/sparql-pml/query/index


and got:

Grails Runtime Exception

Error Details

Error 500: null id in edu.utep.trust.provenance.Query entry (don't flush the Session after an exception occurs)
Servlet: grails
URI: /sparql-pml/grails/query/execute.dispatch
Exception Message: null id in edu.utep.trust.provenance.Query entry (don't flush the Session after an exception occurs)
Caused by: null id in edu.utep.trust.provenance.Query entry (don't flush the Session after an exception occurs)
Class: Unknown
At Line: [-1]
Code Snippet:
Stack Trace

org.hibernate.AssertionFailure: null id in edu.utep.trust.provenance.Query entry (don't flush the Session after an exception occurs)
at java.lang.Thread.run(Thread.java:619)

http://trust.utep.edu/sparql-pml/query/index says to bug you for more information.

Can you provide some assistance?

Thanks,
Tim Lebo

Jitin Arora

unread,
Jul 22, 2010, 3:21:15 AM7/22/10
to Timothy Lebo, Paulo Pinheiro da Silva, infere...@googlegroups.com
Tim,

I am not sure what information you were trying to retrieve with that
query but the error itself is unrelated to the query. My investigation
indicates that the problem relates to a database connection timeout.
The web application uses a database to store some info about queries
and their results so that they can be visualized using Probe-It. Since
the application is used only infrequently, inactivity timeouts cause
the database connection to be lost. So when the application is used
after a period of time, the first query ends up throwing an exception.
When you run into this specific exception, just wait a few seconds and
try again. The application automatically attempts to reconnect to the
database and all should be well in a few seconds.

Finding a fix for the problem may be difficult as it may require
digging into lower level APIs to find out exactly which layer is
causing the problem and how it can be tweaked to extend the inactivity
limit. If the issue is significant or becomes significant, then I can
implement a hack to avoid the exception at least.

Jitin

Timothy Lebo

unread,
Jul 22, 2010, 8:06:03 AM7/22/10
to Jitin Arora, infere...@googlegroups.com
Jitin,

As long as I know to try again, it should be fine.

You might want to catch that exception and report "try again, we didn't connect to the database in time" or something.

Thanks for the help.

-Tim

Reply all
Reply to author
Forward
0 new messages