Hi, Unfortunately Joseki does not allow making a connection pool. According to my experience in this situation, for doing something with apache dbcp, I should modify Joseki source code.
What do you mean by " is it excercising a pool of connections that your model is making use of". Thank you. Tayfun 2012/5/4 nat lu <[email protected]>: > 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<[email protected]>: >> >> >> >>> 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 >>>> >>>> >>>> >> >
