Macbook vs. Powerbook: Jiggerypokery II

Posted by pookzilla on June 21, 2006

(This will be a bit rushed – I have a bus to catch in half an hour

After managing to get the tests running I discovered that the results were not being logged to the database. In the end there were several hurdles.

First was that the appropriate system properties (-Declipse.perf.dbloc and friends) were not being passed to the VMs that were being used to launch the tests. This was corrected by supplying the appropriate flags via extraVMArgs in the test.xml file.

Once done, however, the tests complained that they didn’t have the appropriate JDBC drivers. The problem here lies in the fact that the documentation for the performance tests says that the Derby plug-in needs to be called “org.apche.derby” when in fact it needs to be called Cloudscape. The test plug-ins themselves have no problem with org.apache.derby – they happily try and load several derivatives of the name as well as Cloudscape – but the ant scripts that set up the test VMs require the plug-in to be called Cloudscape otherwise it is not copied to the test Eclipse instances. After renaming the plug-in and putting into the test zip file everything worked.

Almost. See, now it was complaining about the inability to connect to the database. I had set up my Mac Mini as a database server to contain the results from both machines but for some reason I couldn’t connect to it. As it happens Derby out of the box comes with very strict security settings and will only allow connections to ‘localhost’. Once this was fixed (simply adding -h to the derby start script) I could connect to the database.

…

But no results were being posted. I could verify that the test machines were making connections to the database but they weren’t writing any results. The answer to this was really tricky. In trying to debug the database connection woes I had created a database called “perf” from the Derby command line. As it happens, the eclipse tests will always append “/perfDB” to any connection url you give it. As a result when I was passing “net:///perf” as a connection string to the tests it was trying to connect to “net:///perf/perfDB”. The connection would succeed but there is no such database. What’s more, one can’t be created in that location because its parent was already a database. Either Derby was silently ignoring the problem and returning success for all writes to this location or the Eclipse tests were eating failures and not reporting them.

After deleting the initial database and running the tests again I am now seeing results in the database from both machines.

Now to get out of the house before I sully these results by fiddling with the setup any more than I am by making this post from the database machine.