Category: Activities

I’m working on the type of bug that might take me a day, it might take me a week, or it might cause me to give up entirely.

In our system, there is a process of mine (the schedule daemon) that gets events from another process (the event broker) and does some database manipulation. Because the events can come thick and fast, and because I don’t want them stepping on each other, each event causes a separate thread to be spawned, and the thread action is guarded by a global “synchronized” object (this is in Java, by the way). Most of the time, this works fine – if an event happens while another thread is still processing, the second one waits for the first one to relinquish the lock, and it does its thing. The event processing threads generally take 5-15 seconds to run.

But I have a log file I from a customer site, where it appears that one of these event threads started at 04:17, and never finished and never relinquished the lock. So events that happened at 04:51, 05:52 and 06:01 never got processed. And I can’t for the life of me figure out why.

I’ve looked extensively at the code between the last progress message from the 04:17 thread and the progress message it should have printed next. Nothing leaps out at me. And like I said, this code works all over the place, even at this customer site most of the time.

One possibility is that some other program is manipulating the database at the time. I do know that the Playlist that was being retrieved at the time of failure is not present in the next day’s backup, so something may have been deleting it at the time.

I wrote a program that calls the same database method as the one that hung over and over again, and ran that in a continuous loop while doing other stuff to the database including deleting the playlist in question. But while I’ve got my test program to fail with an exception numerous times, it never hangs. (I’m assuming that if a thread dies with an exception, it will release its locks. Something else to investigate, I guess.)

I guess my next step is to step up the tree a bit, and instead of calling the low level query multiple times, try spawning the thread that hung multiple times. Other than that, I’m baffled.

Our two TiVos are networked together over our wireless network. This allows us to transfer shows between the two, as well as doing the daily call over the internet. But the wireless dongle on the upstairs TiVo occasionally drops connection. In the past, I’ve just unplugged the dongle and let it cool down a bit, plug it back in, and everything was fine. But twice in the last two days, when I unplug the dongle, the whole TiVo reboots. That’s not good.

I wonder if it’s time to buy a new dongle. Or maybe I should just hold out for the TiVo Series III.

I now have my name on a second patent. 7,034,916 is basically our old patent 6,812,994 with a few little changes to incorporate some changes we (I) made to indicate whether the feature is ready to play or not.

Take a look at the list of inventors. Curtis is the only other programmer on that list, and he left the company last year before we did this change. Everybody else is middle management and the guy from Corporate Design and Usability whose sole contribution to this change from the old one was to say that we should use blue rather than green to indicate the “ready to play” status. The guys responsible for the code that sends up the information from the feature player as to whether the status is good or not aren’t mentioned on the patent, just me because I take that information and change the colour of the blob of colour on the screen and provide a tooltip. But the guy who signs my timesheet is. That doesn’t seem fair to me.

I have an AbstractDocument in a JTextArea in a JScrollPane. I’m writing to the AbstractDocument from a thread that watches a log file – basically doing the equivalent of a “tail -f”. So far, so good.

Here’s the part that isn’t my favourite thing in the world: If I want the JScrollPane to automatically scroll to the bottom of the file when I write to it, I have to do my AbstractDocument.insertText in the event queue thread (using SwingUtilities.invokeLater), but if I don’t want it to scroll to the bottom, I have to do the insertString in a different thread. Is this fucking stupid, or what? Wouldn’t you expect “Scroll to the bottom on input” to be a property somewhere?

So I’ve got a flag for whether I want it to scroll to the bottom or not, and when it’s true, I use SwingUtilities.invokeLater and when it’s false I call insertString directly.

According to the Java bug parade, people want this property, but even when it’s available, they want the current behaviour to remain the default because so many of us have had to write code this way.