At work there can be more productive weeks, and there can be less productive weeks. Last week, for me, frustratingly, was a less productive week. It was a reminder that working on multiple things at once isn’t good if you don’t get any of them done.

Part of the reason is that we are simply in that post-code-freeze mode of fixing bugs, testing, doing spring cleaning, that sort of thing. By its very nature you tend to work on a lot of little things.

During the first part of the week, I tried to help debug a seg fault we were seeing in the vm when using the ibm jdk, but I got nowhere. One of my teammates was making some progress when it was decided that other issues were higher priority.

So I switched to bug fixing. The best progress I made all week was on this issue. I have the issue reproduced in a system test, but I’m stalled on a solution and am waiting to talk it over with my team. It’s an interesting question – how should we handle read-only style methods (like Calendar.get()) which, counterintuitively, modify the internal state of the instance? In theory you should be able to use a mutable but safely-published instance in multiple threads without any synchronization, if it’s state is never changed. But, Terracotta throws a runtime exception if an attempt is made to change the state of a clustered object outside of a lock, even if that change is unexpected such as in the case of Calendar.get().

I then switched to this issue, which has to do with Terracotta integration with Spring. I’ve got the problem reproduced in a unit test, but once again I’m not entirely sure what the solution should be, so this morning I’m looking to fire up Spring and Terracotta for real and play around with various patches.

I did do my first phone-screen for Terracotta this week. I talked to a QA Engineering candidate. (Terracotta is hiring).

Here’s hoping for a more productive week this week…