On Thu, Feb 3, 2011 at 8:37 PM, Adam Hochman <[email protected]>wrote:
> Hi all, > I consistently get a db connection error on my all in one setup, but > everything appears to be fine. My understanding is that it there is a > connection error, felix will not continue activated the other bundles until > it has been resolved. So if I see felix proceeding, do I assume the > connection was restored? > Right. If a service requires a database connection pool, the service will only start once the pool becomes available. We don't publish the pool until we can make a successful connection, so the DB-dependent services start up only when their dependencies are met. > > 10:14:48 ERROR (Activator:91) - Connection attempt to > jdbc:h2:/var/folders/9V/9V94-cQnEuGsHGvzfdzC5k+++TM/-Tmp-//opencast/db > failed > 10:14:48 ERROR (Activator:92) - Exception: java.sql.SQLException: An > SQLException was provoked by the following failure: > java.lang.InterruptedException at > com.mchange.v2.sql.SqlUtils.toSQLException(SqlUtils.java:106) > > We might want to take a look at how the connection pool and h2 interact. It sounds like the connection pool is a little quick to give up on connecting, so we have to wait a few seconds before we try to activate the bundle again, at which time the h2 database has successfully started. > I also notice that at least with the embedded h2 db, SQLExceptions are > thrown on startup because tables already exists. This seems harmless but I > just want to confirm this. > Yes, this is from eclipselink, our JPA implementation. I've found no way to stop these complaints, other than turning off auto table creation (which is recommended for production). > > We also setup a distributed OSX environment locally, and ran into a few > issues. Our db is hosted on our admin server, and the engage and worker > servers had no problem connecting to the db. The admin server to the > locally hosted db through its server's ip addr. We changed the admin server > config properties to point to localhost and the mysql server configuration > to allow from opencast@localhost and it worked fine. Unfortunately we're > not db experts, so we want to know if this is an acceptable approach. > > I also find MySQL to be difficult in this regard. I switched to PostgreSQL a while back because, IMHO, it is more straightforward to configure and has better command line tools. Josh
_______________________________________________ Matterhorn-users mailing list [email protected] http://lists.opencastproject.org/mailman/listinfo/matterhorn-users
