Pooling in Sakai LDAP

Here at Oxford we connect to a LDAP server to get details about users for our Sakai service. Previously we had reports of some pages taking a long time to load when lots of users details where requested from the LDAP. One obvious change we could make was to switch to use pooling on our connections to the LDAP server. To check that this was improving the performance I wrote a little test case which attempts to get details about 100 users individually from the LDAP.

• Without pooling - 100 users in 10 sec = 10 users/sec.
• With pooling - 100 users in 5 secs = 20 users/sec.

This is a nice doubling of performance, although I was still expecting to see better performance generally and while the test is running the local load on the machine isn't very high so I suspect any further performance improvements will have to come on the server.

Tomcat UNIX aliases

To make managing development instances of tomcat a little easier I have a few bash aliases (you can add these lines to your ~/.bash_profile):

alias tchome='export CATALINA_HOME=`pwd`; echo CATALINA_HOME=$CATALINA_HOME'
alias tctail='tail -f ${CATALINA_HOME}/logs/catalina.out'
alias tcless='less ${CATALINA_HOME}/logs/catalina.out'
alias tcshow='echo ${CATALINA_HOME}'
alias tc='${CATALINA_HOME}/bin/catalina.sh'

so my typical workflow is cd {tomcat-directory}, tchome and then I move back around the filesystem and use tc start and tctail.

Keep on rolling...

Well after a quite a few weeks of waiting my new set of wheels turned up. A Brompton S6L in apple green. The gears needs a little adjusting but otherwise it's a great ride.

Error: sec_error_bad_signature with Firefox 3

Recently when most of our team upgraded their browsers to Firefox 3 we noticed then when we tried to visit on of our internal websites over a secure connection we would get presented with an error page saying "sec_error_bad_signature". Most of the existing comments on the web seem to be saying that they are seeing this error when visiting a site with an untrusted certificate. However in our case it was a correctly signed certificate obtained through the JANET Server Certificate Service.

The server is just a Ubuntu Linux server with a standard installation of Apache Tomcat 5.5 and another very similar setup was working correctly. But after close inspection it became clear that the server had a public key using the DSA algorithm but the machine that was working correctly was using the RSA algorithm. The certificate work was done with the Java keytool command and I think I probably didn't specify the -keyalg RSA argument. After recreating with RSA the certificate and installing it everything was working correctly. The screenshots are taken with Safari (which worked fine with DSA) and shows the two different certificates.

Jack Buckett

Well it's happened again and our second son Jack Buckett was born on Wednesday the 6th of August at 8:31 weighing 4.09kgs. We are all home and doing well now.

RSF Error

I've just been doing a little web development with RSF and it seemed that sometimes when accessing the RSF webapp I would get an error:

[An error occurred handling this RSF request]
[Context has not been started properly]


with a stack trace starting with:

WARN: Error initialising SakaiRSF servlet: (2008-07-15 10:07:43,909 http-9080-Processor21_PonderUtilCore)
java.lang.IllegalStateException: Error acquiring web application context - servlet context not configured correctly
at uk.ac.cam.caret.sakai.rsf.servlet.ReasonableSakaiServlet.init(ReasonableSakaiServlet.java:41)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1139)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:791)


It seems that this occurs if you access the RSF webapp while it is still starting up. The only way to fix it is to reload the webapp again and give it a little more time.

Removing Eclipse team provider information

At the moment there are two competing plugins for Eclipse that can provide SVN integration, Subversive and Subclipse. At various times I have tried each of them and they both have their plus points however if I have a project checked out with one plugin and the Eclipse installation I am using doesn't have that plugin installed I don't get any options under the team menu to share the project.

Rather than getting the old plugin back running and "un-sharing" the project you can just delete a file from the workspace metadata to allow you to re-share the project.
workspace/.metadata/.plugins/org.eclipse.core.resources/.projects/{projectname}/.index.properties
This seems to work for me under Eclipse 3.3.2.