I recently worked around a curious multithreading bug on IBM's AIX JRE. It was one of those painful, but interesting bugs that I thought I should share.

One of the developers I work with reported an issue with a piece of code that generates GUIDs. The error only manifested under heavy loads running in OAS and only on IBM's AIX JRE (build 1.4.1, J2RE 1.4.1 IBM AIX build ca1411-20030930). Everything ran fine on Sun Windows/Solaris/HPUX and IBM z/OS & Windows, only AIX's JRE had a problem.

The error was a pretty basic "'String index out of range:12'" that occurs when you try to substring a string without enough characters. But this wasn't the cause. The developer who wrote the code was using the MD5 algorithm from the JCE to hash up some random data and he was eating the real exception (of course really really bad, but that's another story).

Here's the defect:
java.security.NoSuchAlgorithmException: class configured for MessageDigest(provider: BootstrapProvider version 1.1)cannot be found.
com/ibm/security/bootstrap/MD5


It's doubly curious as this class does exist in the class loader (I can Class.forName it all day long) and I was explicitly using the BouncyCastle provider, not the bootstrap provider.

I tried three methods of getting an MD5 MessageDigest:

MessageDigest dm5Digest = MessageDigest.getInstance("MD5");


MessageDigest dm5Digest = MessageDigest.getInstance("MD5", BouncyCastleProvider.PROVIDER_NAME);


MessageDigest dm5Digest = MessageDigest.getInstance("MD5", new BouncyCastleProvider());


but all three of them still threw the error reporting from the IBM bootstrap provider. So it ends up that there is an error in the JRE so that it can't load the proper class under heavy load. When I explicitly called the BouncyCastle MD5 MessageDigest everything ran fine.

On a side note, since the original developer of this mangled piece of code that was causing the error is no longer with my employer, I rewrote the code so it doesn't use MD5 for a GUID. I'm also not sure why the original developer tried to write something himself rather than using the Jakarta Commons Sandbox Id project. "Not Invented Here" syndrome strikes again.