Saturday, June 25, 2005

The rules engine works. Yay. :-)

While thinking about the RMI problem on Thursday night, I realised that I do want the rule configuration to serialize (I use the American spelling, with the "z" here, since all the interface and method names are spelt that way). The reason for this is because the server with the rules might be different to the server with the data.

My concern with serializing like this is unnecessarily serializing from the server to the client and back again, particularly when the client is on a separate machine to the server. Serendipitously, I'd already wrapped the rule structure in a remoteable class. This works well, because nothing gets moved to the client at all. When the server gets this reference and asks for the rules then this is the only time that the rules get serialized. If the two servers are separate then the RMI serialization is necessary, and this approach works just fine. If the server for the rules is the same as the server holding the data, then the rules will still be serialized, but it only happens once, and the RMI transfer is within the one JVM, so it should be very fast. Either way, there is no unnecessary transfer to the client.

It's amazingly satisfying to see the entailments being generated. :-)

For stability purposes, I've been coding against a version of Kowari that I picked up a couple of months ago. My code has been largely independent of other modification in the system, so this should be safe. Nevertheless, I'm about to update everything and confirm that it all still works.

Once that's done, I'll need to tidy up my tests in order to check everything in. Since it's all working (and can't break any other components), I might check it in without all of the tests. That's because a few people have been asking after these rules. Hopefully they'll like them. :-)

The algorithm for running the rules is not quite complete. At the moment each rule is dependent on finding a change in the total result of a query in order to determine if it needs to run. This requires processing, even when the rule does not need to run. The completed algorithm tests each individual constraint for changes, before testing the joined result. This means that there will be no join processing for (almost all) rules that don't need to be run, and no additional expense for those rules which do need to be run. I expect these changes to take just a few days, but they are not needed straight away.

One feature that might be nice to add would be to keep a total of all entailed statements and return this to the user when done. I'll look at doing this soon as well.

I've gained quite a bit out of using Eclipse, but it's been frustrating me lately. I often find myself typing up to a line ahead of the rendering, and often have to wait for the IDE to finish processing before I can do anything. As a result, I've started using VIM again whenever I want to do fast changes. I'll have to work out some way to use Eclipse again without having to spend half my day waiting for it.

Maybe it's just that my notebook is too slow. It's only a 1.33 GHz G4 (with a GB of RAM). This isn't as fast as many desktop systems, but it's quite responsive on every other application I use, so I expected that it should be fast enough.

Last night I had a go at running Eclipse on my Linux desktop, and piping the display to the X server on this notebook, but that kept crashing. On the Linux-GTK setup it crashed with a GTK Window error whenever I selected the "File" menu. So I tried the Linux-Motif setup, but that caused a Hotspot error. Yuck. I haven't tried it on the local display, plus I was using Java 1.5, so there are a few things that could be causing these errors. I guess that will keep me occupied for a day or so, when I get the time to look at it.


Anonymous said...

Hi Paul,

You might try JDeveloper from Oracle instead of Eclipse. JDeveloper is now free. I have been using the "beta" version in production for almost a year (why does Oracle have something in beta for many months???).

The way I work is to do the builds outside of JDeveloper and debug/run using the created .jar. You can set breakpoints normally.

I have never seen JDeveloper be slow to echo characters when typing. Not to say this cannot happen but it uses Oracle's own JVM (if it can) for common platforms and may give priority to such events.

Creating a project is simple -- in the list of sources just navigate to the /src directory and it will find all the .java files. Use the libraries to enter the .jar of the product from the build (or you can specify this in the run tab with a -jar). You do not want to let it compile or it will try to run the local .class instead of the .jar.

You can probably configure the external tools to do the build.bat/.sh run but I have not done this so far. It does support Ant so if one could eliminate the build.bat/.sh file....


Joe McDaniel

Quoll said...

The problem is that everyone else I know is using Eclipse, and it's become a standard at Herzum Software (where I work now). So I really need to keep going back to it until I can get to a point where I'm happy with it.

In the meantime, I *really* like using VIM, so that is probably just making the transition all that much harder. :-)

BTW, the only reason to use the build script in Kowari, is so that Ant can be launched with a specified classpath, and a couple of JVM arguments. The classpath is needed for optional ant targets, like <script language="javascript">, and the JVM arguments are just to provide set up some environment variables, and increase the available memory.