We’re setting up a nightly instance so we can play with different applications and/or versions of applications within Sakai. We’re starting off with a vanilla trunk deploy, but with the gradebook branch that Louis is working on. This will add a file upload/import capability to the gradebook.
To create a nightly instance, all we did was:
- establish svn+ssh://svn.berkeley.edu/svn/bspace/nightly/v1/
- create our custom .externals file
- svn propset svn:externals v1 -F ./v1/.externals
- svn commit
Comments Off
I’m in the process of writing a utility to explode BB 5.5 content packages into a meaningful filesystem, which can be uploaded to Sakai via webdav. The problems I’m running into so far are:
- Do we use the BB title for the Sakai filename (which is what’s displayed in the BB UI)? [Update: No... use the original filenames, since they are unique.]
- How do we clean up the titles? Some are long, have invalid characters, etc. How much monkeying with filenames will users tolerate? [Update: Windows and Mac have their own illegal characters, as does Sakai's webdav. We're cleaning them all up so the full process works for every file.]
- This is a slow process. Unzipping files and extracting them in java takes forever. [Update: Using Buffered input/output streams helps tremendously. It had been a long time since I'd worked with these APIs.]
[Update: The project is available in Sakai's contrib]
Comments Off
When cleaning out the needless jforum logic that determined how to handle non-transactional DB connections (sakai should always be transactional), I inadvertantly removed the commit() call. This should have been a pretty easy thing to debug… if the DB connection is never committed, nothing should ever be saved to the database.
Oh, how naive! In sakai, we have a database connection pool. When jforum finished it’s request/response thread, it was returning its connection to the pool like any well behaved application should. The problem was that other application services were grabbing that same dirty connection, which was never committed and never rolled back. When that other service called commit() or rollBack(), the sql issued from jforum would suffer the same fate.
Note to self: just because spring takes care of all of your DB connection tasks for you, don’t assume that you’re done with DB connections for the rest of your life.
Comments Off
There’s a theory floating around the office that Jforum’s “Bad Gateway” errors are due to oracle deadlocks. To verify this, I need to do some research:
When the apache front-end times out talking to tomcat (producing the bad gateway error), does the tomcat request thread stop? If the bad gateways are really due to deadlocks, this must be the case, since we do not see oracle deadlock errors logged.
Our DBA team has been providing hints for solving this problem here: http://jira.media.berkeley.edu/jira/browse/BSP-410
Comments Off
I’m starting this blog at a peculiar time. I’m working on several projects all at once:
Let’s see what gets done and when!
Comments Off