Friday, June 25, 2004

For those who didn't know, I've been on holidays this week. No work meant no need to blog. I'd meant to mention this in my entry for Friday evening when I finished last week, but I was caught up with trying to get away and didn't write it.

Anyway, I thought I'd better write what I remember of that Friday before I get back to work on Monday.

Reflections on SessionFactoryFinder
My morning was spent tracking down this week-old problem in the resolver code. It became apparent very quickly that the problem was in the path being provided by Ant, but at first glance the XML configuring this looked fine. What I didn't realise was that the jar files mentioned for the path were all in the obj directory. I hadn't really looked at this directory before, but each of the jars in there all hold only a small portion of the system. They get glued together to create the distribution jars.

After much experimentation and grepping through jar listings, I was able to get the junit tests running. They reported an error, but that's a lot further than they had been getting. :-)

The plan is to track down this error on Monday.

RMI Retries
At the moment, if a server is restarted then any iTQL command line programs will also need to be restarted. This is because iTQLInterpreter objects keep hold of an RMI session object, and use this object for all queries. If the server is restarted then this remote object is destroyed, and all subsequent attempts to use it will result in an RMI failure.

While correct in one sense, this behaviour is really annoying. Since sessions are stateless, it is possible to obtain a new session when an old one dies, and to use that session instead. In fact, all methods on a session are effectively static, but static methods can't be described in an interface. More importantly, RMI does not support the concept of a class method.

The solution here is to catch all exceptions when calling a session object, and find those which were caused by an object no longer existing. At this point a new session can be instantiated, and the original call retried. It may be better to do this with a proxy class, but for the moment I did it with brute force.

To prevent infinite recursion on failed connections I introduced a retry count. This is set to the default value on creation of the remote session class, and is decremented with each reconnection attempt. When it hits zero a reconnection is not attempted and the original exception is thrown. After a method is successfully called, or an exception is sent back to the caller, then this value is reset to the original retry value.

Most of this functionality happens in one private method, but the reset of the retry count has to be done in each individual method invoking the remote session. This was boilerplate for most of the methods, which is why I started thinking that a proxy class may have been better. However, the need to get it running before I left, and the intricacies of several methods which didn't behave in the same way as the rest, led me to continue changing the remote session class without introducing any new ones.

The changes appeared to work initially, but after a couple of restarts of the server I had a strange exception come up. It was due to some of the changes caused by working with the resolver classes, but that wouldn't be a problem for others as my code is not checked in yet. Unfortunately this was at the last minute on Friday, leaving me with no time to try the changes on a clean checkout. I left it all for TJ to integrate, and according to the early tests it should have worked fine for him. I suppose I'll find out in a couple of days.

The reason I was in a hurry to get out on Friday was because someone had arranged to come over to check out the Dell notebook I was selling. Turned out that he liked it, and I sold it on the spot. So in some of my free time this week I ordered a new PowerBook from a friend at Apple. It doesn't have many of the features I'd like (backlit keyboard being first among them), but it's mostly there. In the end I opted for the 12" PowerBook as it is powerful enough for what I want to do, and is portable enough to be useful. Of course I love large screens, but that is counter to the desire for portability. Besides, large screens are what desktop machines are for.

Now I have to see if I can get MythTV going under OSX.

While I was away during the week I've had several items show up for my application to UQ. CQU have sent a corrected set of results, and our company has provided a letter of support for my study (unlike some universities, UQ does not require this, but I'm told it might help). I'd better get that proposal finished soon!

I did no where near as much reading as I thought I would this week, and most of it was on subject matter that I hadn't planned on. Holidays can be like that. I'm part way into a book called "Teach Yourself Mathematical Groups" by Tony Barnard and Hugh Neill. Kind of an "Idiots' Guide". I'm about a third of the way through, and I haven't encountered anything new yet, but I think I'll be covering new ground in the next chapter. It's been a while since I've looked at the syntax the authors use, so it has been helpful covering the old ground, plus it helps stroke my ego before it gets shredded with the tough content later.

I also started "C++ GUI Programming With QT3", by Jasmin Blanchette and Mark Summerfield. I've been meaning to start this for a while now. I already know a little GTK/Gnome, but I wanted to learn more QT to program my Zaurus (which I'm sure is feeling neglected by now). I originally opted away from QT because it only really supports C++, but who am I kidding? I was going to program GTK in C++ anyway!

I'm only 4 chapters into the book so far, but I'm already starting to form opinions. Those parts which describe pure code implementations are really well written, while those describing QT Designer leave me unsatisfied. The pure code descriptions provide useful examples, with each element described in detail. Alternatives and unused options are also described, answering all of the questions I've had so far. Conversely, the QT Designer sections tend to use examples with explanations that only cover the basics, with no or deferred explanations of other options which are clearly available. I suspect this is due to the dual authorship. Overall though I'm still learning from it, and it appears to be a useful book.

No comments: