It finally happened. After nearly 8 years of using Hibernate in various incarnations, yesterday I came across real honest to gosh bugs that I was able to track down and determine how to fix.

The hibernate community is big. But it, like every other good open source project is a meritocracy based organization, run by a handful (or couple handfuls) of dedicated developers. Some do it for a living (jboss / redhat employees, I’m looking at you) others do it as a way to break into the industry.

I am still a firm believer that if you want to do software development for a living, you’ll do it in your free time, and in the modern age (the last 15 years) that means you’re probably doing some FOSS in your spare time. I’ve been involved with enough other FOSS projects to know the right questions to ask and how to seek out the right people to ask them of. Here’s my take on Hibernate, now that I’ve successfully submitted 3 patches which are in consideration for 4.1.3

• Get a freenode IRC account. Register a username. /join #hibernate and #hibernate-dev
• Spend a proper amount of time searching their bug-tracker. (JIRA) Make sure your problem is unique before creating a new issue. If it’s not, make sure you read the entire thread on the existing issue. There may be a workaround listed there.
• If you plan on attempting to patch the thing yourself, talk to the guys in #hibernate-dev _before_ you start working on it.
• • Get a GitHub account. Make sure you take the time to setup your ssh keys.
  • Read over the Contributing Code document in the hibernate wiki. sebersol provided me the link when I asked what the process was in #hibernate-dev
  • When you have your fork, and you have your fork checked out, don’t bother with installing gradle locally. This was my first experience with gradle. There’s actually an embedded gradle (gradlew, as it’s called) in the hibernate source you’ve checked out. Just execute that.

That’s pretty much all the notes I have. The folks in #hibernate and #hibernate-dev are pretty helpful, and I was surprised by how open to contributions from a guy they’ve never worked with before they were. Although, it was pretty fun when one person pointed out, “If you’ve already tracked down the source of the bug, this process should be pretty easy for you.”

Perhaps that was the first piece of merit I earned — the secret handshake, so to speak.

So here’s the issues I’ve contributed fixes too.
HHH-7101
HHH-7251
HHH-7252

We just got in a couple brand-spankin’ new servers at work, 12 physical core boxes with 24 logical cores, which is a bit… umm… unwieldy to track when you’re looking at 24 discrete cpu graphs. Aggregating that into one graph certainly does help.

The most recent build of collectd in the Debian 6 repositories is 4.10.1, which is a bit older than the collectd release this cpu aggregation patch was created for. So I took the liberty to create a collectd cpu aggregation patch for debian 6 (seriously, it was stupid easy) and see where it got me.

Here’s the instructions for doing a rebuild yourself using the patch…. Enjoy!

sudo apt-get install devscripts build-essential fakeroot
sudo apt-get source collectd
sudo apt-get build-dep collectd
wget http://www.varnernet.com/~bryan/wp-content/uploads/cpuagg.patch_.tar.gz
tar -xzf cpuagg.patch_.tar.gz
cd collectd-4.10.1
patch -p0 ../cpuagg.patch
debuild -us -uc
cd ..


And sure enough… look what’s on the latest QNAP firmware?

- [Live Update] NAS might become unresponsive after firmware live update.

Really? I hadn’t noticed.

A few months ago, I enabled the ‘live update’ feature on my QNAP TS-410 NAS. It seemed like a good idea.

Unfortunately, it wasn’t. Seems that something happened with it’s auto-update feature, which caused the firmware to be completely bonkers.

So tonight, I had an interesting (har har) and fun (NOT) time using my laptop to execute the firmware recovery process. Hopefully this works.

It worked.