Outside of Jena, mysql server side timeouts cause this kind of thing.
The only way Ive managed to get around it is to reduce the mysql server
side timeout, for example
[mysqld]
wait_timeout=300
interactive_timeout=300
and to run a connection pool that sends keep alive queries. Eg with a
jakarta commons dbcp pool, you would set properties testWhileIdle and
validationQuery (something like "select 1"). The pool uses this to test
connections during idle, but it also needs to test when getting a
connection from the pool, so you also have to set testOnBorrow -
otherwise you get a connection error when taken from the pool and then a
new connection is constructed. Setting testOnBorrow does this first and
suppresses the connection error from bubbling up.
So it seems to me that somehow, this kind of thing needs to be applied
in your case - your quartz job seems to be the right approach, but is it
excercising a pool of connections that your model is making use of ?
On 04/05/12 09:19, Andy Seaborne wrote:
On 04/05/12 08:06, Tayfun Gökmen Halaç wrote:
2012/5/3 Andy Seaborne<a...@apache.org>:
There is a sdbModel description at the beginning of the configuration
file.
[] ja:loadClass "com.hp.hpl.jena.sdb.SDB" .
sdb:DatasetStore rdfs:subClassOf ja:RDFDataset .
sdb:Model rdfs:subClassOf ja:Model .
Although execQueryProtected() method in SPARQL class expects mysql
exception within a QueryStageException, it is thrown within a
JenaException by SDB.
What haven't been able to determine is why QueryStageException is
begin throw at all. It's not part of the SDB SPARQL execution if it's
a dataset and I don't see how a query can get to code that does throw
it. Maybe if the config is declaring a model.
Without a complete, minimum example, I haven't the material to
construct a test case.
My modified SPARQL processor cannot obtain a connection although it
tries
for the second time and autoreconnect is enabled.
That should work.
Unfortunately does not work.
One way to keep the connection alive is to ask a lightweight query
every
hour, e.g "ASK{:x :p :o}" -- the IRIs do not have to be in the data.
I have constructed a quartz scheduler to send a query once every four
hours while connection timeout of MySQL is eight hours.
Which one of the following queries is low-cost?
"ASK{:x :p :o}" or "SELECT * WHERE {?s ?p ?o.} LIMIT 1"
The ASK one.
Andy
Andy
Tayfun
On 27/04/12 17:01, Tayfun Gökmen HALAÇ wrote:
Andy,
Do you have any comments on Joseki SPARQL processor? Message are
answered
on a "when I can basis" My expeirnece was that if autoreconnect is
enabled,
then the first call
after a long idle period still failed. Retrying was necessary. But
you
still need autoreconnect. Andy
