Over the last couple of days, the game finder on FUMBBL has been acting a bit erratic. I was going to write this in a forum response, but decided that it would be better to post as a blog entry.

The core functionality of the game finder is actually not that hard to explain. Simplifying a bit, the system does the following:

1. Track which teams are entered into the system.
2. Find matches that are valid.
3. Show these matches to coaches in a list
4. Track offers (ie, the accept/decline status) for each match
5. Start matches which have been accepted

To actually make this happen, though, is much much harder. FUMBBL is mainly written in the PHP language, which is really great for certain things, but one of the major limitations of it is that it is very hard to maintain a persistant "state". This means that it's hard to keep track of things between each page load. The game finder system, for example, needs to keep a list of potential matches and the accept/decline state of each match. While this could be done in a database, it would end up being pretty slow when there are many people active in the game finder.

When I made the decision to build the game finder in the first place I decided to build it in Java, which was partly possible because of the upgraded web server (ie, I added a fair amount of RAM and could afford to set up a Java EE server). Having the Java server up and running means that I can utilize a persistent state and keep certain things in the game finder in memory.

Some time ago, when I built the blackbox scheduler (also in Java, but in SE rather than EE), I developed a database abstraction layer to simplify the access to the FUMBBL database from Java. This is a relatively complex task in itself and involved a number of subcomponents. The most important one in this context is a cache, which allows the system to not be forced to make database queries every time the application needs data. Without this cache and abstraction layer, code would look somewhat like this (very much simplified):

resultSet = database.query(TEAM_SQL, teamId)
teamName = resultSet.firstResult.get("name")
teamTV = resultSet.firstResult.get("tv")

display(teamName, teamTv)
... etc

In real code, this would probably be moved over to some kind of class though:

class Team {
var name
var tv

method load(teamId) {
resultSet = database.query(TEAM_SQL, teamId)
name = resultSet.firstResult.get("name")
tv = resultSet.firstResult.get("tv")
}
}

team = Team.load(teamId)
display(team.name, team.tv)


While this method is better, it's still wasteful of resources since every time you want to access team information, you'd need to load the team data from the database. To solve this problem, you add a cache. Simply put, a cache is a place where you can store things for later use. With a cache, the code would become something like this:

class Team {
var name
var tv

method load(teamId) {
if (cache.getTeam(self, teamId)) {
done;
}

resultSet = database.query(TEAM_SQL, teamId)
name = resultSet.firstResult.get("name")
tv = resultSet.firstResult.get("tv")

cache.storeTeam(self, teamId)
}
}

team = Team.load(teamId)
display(team.name, team.tv)


The main difference here is that when loading a team, the code checks if the team was already stored and if so, fetches the information from the cache rather than reading it (again) from the database. Of course, there is much more to caching than this but I'm simply trying to illustrate the core concept.

Although this is greatly simplified, the game finder is using a system that is similar to this. One of the major problems with caching in general is that if you have multiple systems (for example, the FUMBBL PHP website) that can modify data, caching can lead to displaying outdated information. For example, if the Java application has the team information in the cache (in memory) and the team name would be changed in the database, the Java application would not see this change. If you remember the early days of the new game finder, this was the case for some teams where the TV seen in the game finder wasn't the TV seen on the website. Basically, an uploaded result updated the database, but since the team was in the Java cache, the old TV was used for game finding. The way this was solved was to make the PHP site send a message to the Java application to "flush" (ie, remove) the specific team object from the cache when PHP code changed data on the site (of course, this is more complex than it sounds).

To get back to the game finder itself, the way that it functions is that it keeps a list of teams, and every time a request is made from someone showing the game finder view is that it searches through all possible matchups and gives back a list of them, together with their state (the accept/decline status of the match). There are a few of problems with this method:

1. This is very time consuming. Checking each possible match is a slow process, where the code checks each possible opponent for each team in the system (this is called O(n^2) complexity) and this will slow down exponentially as the number of teams increase.
2. Since the method is called every time a list of matches is requested (once every 4 seconds when you're on the game finder page), this slows down the web server pretty quickly. I've found that the Java process that does this is making page loads on the site slow down.
3. Keeping the list of teams in memory creates similar problems as with caching. The team objects are not released at any point, and the cache isn't given an opportunity to refresh outdated data.

The third point, together with a similar issue with a "coach" object stores a list of teams, is creating the problems that people are seeing with the game finder now. The reason it is a bit more broken than it was last week is that I made an attempt to fix the slowness by improving how things are processed (which highlighted the core problem to a greater extent).

In order to fix these problems, I will need to do a relatevly significant rewrite of the game finder. A couple of things I will be doing is:

1. Decouple the game finder lists from the actual abstract objects. Instead of storing a list of Team objects, I will store a list of team IDs, and repeatedly ask the cache object for the teams when needed. This will allow the cache to properly refresh team information as appropriate.
2. Maintain a list of possible matches properly, and update this properly when a team is added, removed or changed. This will improve the performance of the system, and the site as a whole since teams changing is significantly less frequent than requests for possible matches.
3. Properly isolate the list of teams from the "framework" code for the game finder. Currently, the code is somewhat monolithic with too much logic running in the same code context. Doing this will improve the readability and maintainability of the code.

Since this is having a relatively big impact on the site at the moment, I am hoping to be able to find the time to sit down and work on this this weekend. Until then, I am thanking you for your patience and apologize for the inconvenience of the game finder not working as it should.