> -----Original Message----- > From: Damian Steer [mailto:[email protected]] > Sent: Saturday, January 28, 2012 8:44 AM > To: [email protected] > Subject: Re: Fuseki (broken pipe) > > > On 27 Jan 2012, at 20:27, John Fereira wrote: > > > Sure, I could dump the RDF, but the site is going to be harvesting > data from numerous data sources, probably on a daily basis and > considering it's going to be hosted at a well known U.N. organization > it's likely going to get really large. If I was just going to use RDF > I could that directly to Elda and forget about using joseki/fuseki > entirely (which I might do for a subset of the data anyway). > > > > The semantic web app isn't so much tightly coupled with SDB as much > as SDB is sort of hardwired into it. I suppose replacing it with TDB > would be possible but that would make it quite difficult to migrate to > future release of the app. > > I've had a quick look at getting connection pooling working with fuseki > and it looks tricky. The problem is that there's no obvious point to > free the connection. > > Two approaches: > > 1) Wrap every DatasetGraph operation in a getConnection / > freeConnection and use a pool. That might be ok for fuseki. Generally > it won't work because you can get a graph and perform arbitrary > operations on it. > > 2) Before every SDB operation check the status of the connection (e.g. > 'SELECT 1') and, if necessary, reconnect.
As of java 6 there is a java.sql.Connection.isValid(int timeout) method that could be used. What are the minimum java requirements for SDB? If it's Java 6, using the isValid() method might be the easiest way to fix this. On Friday I updated the mysql Connector/J jar file to the latest version and added autoReconnect=true to the jdbcUrl. I don't see a Stacktrace anymore. Instead, I'm seeing the following message: The last packet successfully received from the server was 231,244,460 milliseconds ago. The last packet sent successfully to the server was 231,244,461 milliseconds ago. is longer than the server configured value of 'wait_timeout'. You should consider either expiring and/or testing connection validity before use in your application, increasing the server configured values for client timeouts, or using the Connector/J connection property 'autoReconnect=true' to avoid this problem.
