AM and I spent a lot of time today trying to debug the joins which occur when using a remote resolver.
The first part was trying to print out the constraint expression tree. Yesterday we discovered that this was causing a
NullPointerException, and we spent some hours tracking it down.
The problem occurred during the sort of a
Tuples. This created a new
HybridTuples (via a factory method, so we didn't see immediately that the returned type was really a
HybridTuples), and it was in the
HybridTuples constructor that we discovered that the incoming
Tuples object was being kept, but not being cloned. Consequently, when the tuples which had been given to this constructor was closed later, the
HybridTuples object became invalid.
Once this was solved, we were able to observe the constraint tree. It was immediately apparent there was a problem, as the entire tree was being duplicated, with the results of both sides being unioned (and duplicates removed). While this worked for some queries, it created a problem for others when the joining code expected the columns of the tuples to be ordered in a particular way.
AM had seen something like this before, and discovered the problem in a piece of code which builds up the constraints. It was a simple typo with the wrong constraint variable being used.
A concern here was that AM says that he has fixed this code before. This seems similar to a problem he had a couple of weeks ago where a "cvs update" was not getting the latest version of a file. We could look at the CVS log for the file, and everything seemed in order, but for some reason the latest version of the file would not come down for him. In the end he had to delete the file and get it again. In this case he was lucky that it was not a file he had modified.
Friday, November 12, 2004