Pauli Borodulin

I recently needed to know how much disk space each table in a Ingres 2006 R2 database took. Any Ingres DBA knows that by default Ingres stores the data under location II_DATABASE, but the filenames used for the data files are not too informative. Fortunately it is possible to check the filename of a table using the following query in the corresponding database:

SELECT file_name, file_ext FROM iifile_info WHERE table_name = 'mytable';

The file_name column contains the name of the file for the table without extension and the column file_ext contains the extension. If the database uses multiple locations, it is also necessary to check the value of the column ‘location’, which will tell you the location of the file.

But this is not all. Ingres also stores all secondary indexes in separate files. It is also possible to see, using the table iifile_info, which index is stored in which file. This way it is even possible to hunt down indices that require more disk space than you expected.

I have just reworked Kristian Slavov’s remote control patch for Manu Abraham’s latest Mantis driver tree. The original patch was posted in April 2007 on linux-dvb mailing list. The reworked version contains only the remote controller functionality and it applies cleanly to the latest version (cd1fc4c7f1d8) of the driver tree. The patch is available at http://pauli.borodulin.fi/misc/mantis-rc-cd1fc4c7f1d8.patch.

Here’s some tips to get it working:

1. Get a snapshot of Manu’s tree from http://www.jusst.de/hg/mantis/
2. Extract the tree and apply the patch:
   tar jfx mantis-cd1fc4c7f1d8.tar.bz2
cd mantis-cd1fc4c7f1d8
patch -p1 < mantis-rc-cd1fc4c7f1d8.patch
3. Compile and install
   make
make install

The remote control will be visible through /dev/input. You can check the correct device by running dmesg. You should be able to spot a like similar to this: “input: Mantis VP-2033 IR Receiver as /class/input/input3″. To use the remote control with VDR you will need something like vdr-remote.

Edited: A revised version of the patch is available here. It is against driver tree version b14e79e460fc.

Yay! I got my bike fixed yesterday (had a flat front tyre etc.). I could not resist taking a short test drive in the evening and instead of just checking out that everything worked okay, I drove a 10 km route to the University and back home. I was able to maintain 20 km/h average speed which was fine after last winter with almost no physical exercise at all. Didn’t take it too seriously tho’, since I had jeans on and didn’t even have anything to drink. I guess I’ll have to try cycling my last summer’s regular route to Rajasalmen silta and back (about 40 km) soon.

I have decided to try tracking all my this summer’s cyclings using Nokia’s Sports Tracker so that I can check how much I cycled during the summer. I guess I will miss some workouts anyway, but some kind of total number of kilometers would be nice to see when summer ends.

I have been preparing for an update of Sun ONE Application Server 7 at work for some time now. A week ago I finally found a decent way to run Sun Java System Application Server 9.1 u1 on Solaris 9 under unprivileged account so that SJSAS could be reached on ports 80 and 443. The solution was to put Apache HTTP server in front of SJSAS using mod_jk and AJP (just like Tomcat often is installed). In the solution Apache will listen for the ports and deliver the requests to SJSAS using AJP. Gladly, Sun has provided instructions for this.

Unfortunately copying the three mentioned JARs (tomcat-ajp.jar, commons-logging.jar, and commons-modeler.jar) to the lib directory also had some unexpected side effects. After setting up AJP, we were unable to deploy WWW applications which used Commons-logging and log4j. This was because Commons-logging was now loaded by the common classloader and log4j was still loaded by the web classloader. Since log4j was loaded deeper in the classloader delegation hierarchy, Commons-logging was unable to see it. If Commons-logging was configured to use log4j (as we do), the web application failed to start because class org.apache.log4j.Category could not be located. You can read more about classloaders and Sun Application Server in the SJSAS manual.

The simplest solution would have been moving log4j to the SJSAS’s lib directory. This would have solved the problem with class visibility, but then all our applications would have used the same (common) version of the library (even if the application provided its own version of the library). This would have been a problem for us, since then it would not be possible for us to update the library for each application one by one. We would have to test all our applications when we needed a newer version of the library just for one of the applications. With out resources, this is simply not possible.

After some googling I come up with an idea of renaming the packages of Commons-logging and Commons-modeler. Sun has already been doing similar in SJSAS to prevent some class naming conflicts, since they use classes from Apache Commons and some other libraries. After modifying all the three JARs and replacing the previous versions I copied to the SJSAS lib directory, the problem was nicely solved.

I really wish that the support for AJP will be integrated to Glassfish V3 so that this trick will not be needed for it. On the other hand, by the time Glassfish V3 is released we will probably already have Solaris 10 on all of our servers. With Solaris 10 we can simply use ipf/ipnat to redirect the requests to the application server or we can use Solaris 10 privileges to allow unprivileged user to bind on privileged ports (<1024).

Yay! I was finally bored enough to put up a blog. The default theme looks pretty awful, but I guess it’s the content that really matters. I will see if I have time to put up my own theme later. Until that I’ll try to adopt a habit of writing my findings and thoughts publicly from time to time.