Tag Archives: fix

Two bug fixes in JDK6u34 worthy of note

JDKu34 fixes a lot of bugs but two, in particular, struck me as particularly worthy of note.

  • Bug 7027300 – Unsynchronized HashMap access causes endless loop
  • Bug 6941923 – RFE: Handling large log files produced by long running Java Applications

The first fix really made me laugh as this problem has existed for so long, been widely written about on the web and plagued many who made the rather novice and deadly mistake of using hashmap unsynchronized over the years. It’s also been a tricky one to debug once you’re hit with it as nothing really happens other than the one thread executing the hashmap code going into an infinite loop whilst still remaining in a RUNNABLE state and not a BLOCKED state which is what people tend to look for in thread dumps. The application may become unresponsive which may lead you to think that it’s probably just some slow code if you’re working with cpu intensive code like aggregate statistical calculations.

The key to effective debugging of such subtle concurrency bugs is to always have jvisualvm open on local processes and to check the real time thread visualisation tab frequently to see what your application is doing or if running live then to take multiple thread dumps either manually or programmatically and check for differences between them.

The second fix also made me laugh as this is another issue, though less critical than the previous one, has caused much inconvenience to both java developers, system administrators and support staff over the years. Large log files have resulted in periodic process restarts being incorporated and numerous emails being sent about running out of disk space. Can you believe that in this day and age we still run out of disk space? Much bash code has also been written to do log rotation manually as was the case in my last workplace and processing or reading large log files is also much slower.

Though, to be honest, I have to confess I’m a little confused by the Oracle bug system. On the second bug above it says ‘Closed, Will not Fix’ but at the same time under ‘Evaluation’ it says three new flags have been introduced so has the issue been fixed or not? I also noticed another bug which looked interesting: bug 7071826 – UUID.randomUUID() race condition. ID generation is a very critical function of any environment and if there was a race condition it could potentially be a serious and widespread issue but I noticed that in that bug there was no description of the problem; merely pointers to comments elsewhere but where? Where are those comments being held? Help me out if you know.

On a related note JDK7u6 introduces JDK and JRE support for Mac OS X!

Java 7 loop predication bugs surface and workaround known

Software and bugs always have been and always will be inseparable. Java 7 certainly wasn’t going to be the first exception to this rule. Unsurprisingly, since internal testing can never compete with the testing that takes place through mass adoption, in less than a day after Java 7’s release bugs surfaced with loop predication.

Oracle are aware of the issues and Mark Reinhold has suggested a work around while they work on fixes for an early update release. Though apparently update 1 will be security fixes only and loop fixes are more likely to appear in update 2 though they will try to push into update 1 if possible. Keep at it Oracle – you have our support.

Supposedly the bugs were found by Apache Lucene and Solr but I’m sure I’m not the first to wonder why these projects neglected to test with all the openjdk nightly snapshots and particularly with the release candidate.

Update [01/08/2011]: The following links provide a bit more insight on what happened: ‘The real story behind the Java 7 GA bugs affecting Apache Lucene / Solr‘ and ‘Don’t Use Java 7? Are you kidding me?

Fixing Java UnknownHostException on Ubuntu

On Ubuntu, on fresh installs, I frequently tend to get UnknownHostException(s) while running Java such as below.

INFO: I/O exception (java.net.UnknownHostException) caught when processing request: repository.springsource.com.s3.amazonaws.com

This normally happens for me when running 32-bit Java on 64-bit Ubuntu. The solution is simply to install lib32nss-mdns as follows and then retry.

sudo apt-get install lib32nss-mdns

Sources (ubuntu bug, ehow).