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.

tailor for svn to hg

Well after attempting to convert the portal part of the sakai subversion repository to mercurial I have discovered that tailor (the tool I used) doesn't understand svn tags and branches (or doesn't convert them to mercurial tags and branches). So although is seems to have converted the portal ok. I now have a huge checkout:

buckett@oucs-matthewb:~/tmp/portal $ du -sh *
228M    branches
4.0K    project.log
739M    tags
23M     trunk

So I think tailor would well for converting a branch (eg 2.5-x) or trunk but not for keeping details about when those branches were made from trunk.

Converting Subversion repository to Mercurial with tailor (Ubuntu 7.10)

I'm looking at managing our local builds in a better way than a set of patches against a point on the Sakai tree. Currently I am looking at placing a copy of the sakai subversion repository into a mercurial one. Mercurial doesn't seem to have good subversion support out of the box (unlike git) but the suggested route seems to be to use a genral purpose tool called tailor. Subversion, mercurial and tailor are packaged for Ubuntu (7.10) so after installing them I attempted a quick conversion of part of the Sakai repository.

To do this I generated a tailor configuration file with a command similar to:
tailor --verbose --source-kind svn --repository https://source.sakaiproject.org/svn/ --module portal --target-kind hg > sakai.tailor
and then attempted to run the conversion with:
tailor -c sakai.tailor
which failed with a nice python stack trace:
File "/var/lib/python-support/python2.4/vcpx/repository/hg.py", line 438, in _prepareWorkingDirectory
message = 'Tailor preparing to convert repo by adding .hgignore')
File "/var/lib/python-support/python2.4/vcpx/repository/hg.py", line 339, in _hgCommand allopts = self._defaultOpts(cmd)
File "/var/lib/python-support/python2.4/vcpx/repository/hg.py", line 333, in _defaultOpts findcmd = commands.find
AttributeError: 'module' object has no attribute 'find'

after a little puzzling I found a bug report about this "not compatible with mercurial 0.9.4", which contained a small patch to fix the issue. Applying this patch to my local machine allowed tailor to run fine. It seems that Ubuntu 8.04 (which will be released in a month) contains a later version of tailor so people shouldn't see this issue.

Following Sakai developments

Some of my current work involves developing the Sakai portal and collaborating with others in this space. To keep abreast of what is happening I follow the SVN commit messages and have a filter setup in the Sakai bug tracking system (JIRA).

I filter the SVN commit messages (as I get notified of every single Sakai commit) so that I only see the ones that relate to the /portal part of the repository. My filter (GMail) for this is to:(source@collab.sakaiproject.org) (portal/trunk OR portal/branchces). In JIRA I have a filter which emails me any tickets that have changed in the last 24 hours and have it run once a day. The trick for this is to have the Updated From field set to -1d

This all allows me to know about stuff that is changing without being overwhelmed with email.

Disabled input buttons in Sakai

In HTML you can disable the ability for an input button to be clicked typically you just add the disabled attribute to a button with some value. Eg:

<input value="Click" disabled="true" type="button">

Now in Sakai if you do this for an active button (default one for a form) then under Firefox the button loses some of it's 3D look but remains blue (default default button colour). IE always renders a disabled button grey (allowed in W3C spec). To get a consistent look across the browsers and make it clearer to a Firefix user that the button is disabled you have to have the disabled attribute equal disabled:

<input class="active" value="Click" disabled="disabled" type="button">

the button is made grey by the following CSS (from /reference/library/src/webapp/skin/default/tool.css)

.act .active[disabled="disabled"] { color:grey }