Jazz Build Engine fails in printToBuildLog and crashes when receiving build request
We upgraded from RTC 3 to RTC 4 a few months ago. Today, we took a machine formerly configured as an RTC3 Jazz Build Engine and installed the RTC 4 build system toolkit on it.
When started, the build engine comes up and shows up in the RTC build engine list. However, when we submit a build request to this engine, the JBE java process crashes with the following exception in its log:
Exception in thread "Thread-7" java.lang.NullPointerException at com.ibm.team.build.internal.engine.BuildLoop.printToBuildLog(BuildLoop.java:1528) at com.ibm.team.build.internal.engine.BuildLoop.printSubstitutedProperties(BuildLoop.java:613) at com.ibm.team.build.internal.engine.BuildLoop.performPropertyVariableSubstitutions(BuildLoop.java:583) at com.ibm.team.build.internal.engine.BuildLoop.runLoop(BuildLoop.java:461) at com.ibm.team.build.internal.engine.BuildLoop$1.run(BuildLoop.java:211) at java.lang.Thread.run(Thread.java:738)
This is a new one, apparently nobody saw that failure before.
Developers, any idea?
When started, the build engine comes up and shows up in the RTC build engine list. However, when we submit a build request to this engine, the JBE java process crashes with the following exception in its log:
Exception in thread "Thread-7" java.lang.NullPointerException at com.ibm.team.build.internal.engine.BuildLoop.printToBuildLog(BuildLoop.java:1528) at com.ibm.team.build.internal.engine.BuildLoop.printSubstitutedProperties(BuildLoop.java:613) at com.ibm.team.build.internal.engine.BuildLoop.performPropertyVariableSubstitutions(BuildLoop.java:583) at com.ibm.team.build.internal.engine.BuildLoop.runLoop(BuildLoop.java:461) at com.ibm.team.build.internal.engine.BuildLoop$1.run(BuildLoop.java:211) at java.lang.Thread.run(Thread.java:738)
This is a new one, apparently nobody saw that failure before.
Developers, any idea?
One answer
I found the problem. It turns out that since we migrated from RTC 3, the previous version of the JBE used to run on this machine. This JBE v3 left behind a .metadata directory in the location specified by the -data JBE option.
Obviously, JBE v4 found it and promptly crashed.
Solution: remove the .metadata directory and start JBE again.
This is NOT an expected or acceptable behavior. Updating RTC 3 to RTC 4 is both supported and recommended, so why does the JBE upgrade have this kind of pitfalls?
Suggestion:
1. Put out a technote with the exception quoted so search engines can find the technote by looking up the exception text, explaining what precautions to take when migrating JBE
2. Supply a jbe-migration-checker program to run as part of the migration. The program will verify that the old metadata dir has been removed, and whatever other pitfall checks are required.
Obviously, JBE v4 found it and promptly crashed.
Solution: remove the .metadata directory and start JBE again.
This is NOT an expected or acceptable behavior. Updating RTC 3 to RTC 4 is both supported and recommended, so why does the JBE upgrade have this kind of pitfalls?
Suggestion:
1. Put out a technote with the exception quoted so search engines can find the technote by looking up the exception text, explaining what precautions to take when migrating JBE
2. Supply a jbe-migration-checker program to run as part of the migration. The program will verify that the old metadata dir has been removed, and whatever other pitfall checks are required.
