One part of DevOps that gets less attention is the first 3 letters of the buzzword – DEV. Let’s be real – part of achieving continuous flow very often involves some changes or tweaks to the development side of the equation. A lot of software delivery friction can be caused by the simple fact that development is handing off something that is difficult to deliver. Remember both Dev and Ops have to concur on what the pieces look like – otherwise you end up with a ‘throwing over the wall’ scenario no matter how many times you say “Continuous” or “DevOps”. To that end, we sometimes get involved deeply with development tools of one for one reason or another and kick over some interesting rocks in the process. We recently ran into a very tricky / time consuming problem at a customer that was due to some relatively obscure and undocumented configuration files in the ClearCase product. Given how hairy it was to figure out, we thought we would share with the community. The tee-up:
- The customer is trying to modernize tooling and has a large amount of code in Rational ClearCase.
- They have largely moved their Work Items into Rational Team Concert and are looking at more Agile Development processes.
- The move to RTC Work Items and planning is much easier / faster than moving the code from ClearCase, so they want to use the ClearCase Bridge feature in the interim.
- Most of their code is C/C++/C# and generally Windows-technology related and they are heavy Microsoft Visual Studio users.
- Windows 7 Professional OS (32bit)
- ClearCase Client 8.0.1 – Fixpack 2
- RTC Client 4.0.3 (based on Eclipse 4.2)
- ClearTeam Extension 8.0.1 – Fixpack 2
- Microsoft Visual Studio 2010 SP1
The problem: While the installation and configuration of the ClearCase Bridge was very straightforward and worked pretty much first time from the Eclipse client, the Visual Studio integration simply did not. The visible symptom was that it would appear to hang while trying to launch the integrated dialog boxes. After a couple of reconfiguration and re-installation cycles – complete with the ‘fresh machine’ repeat of everything, we were stuck and could not find or get any information about the cause – the configuration was fine according to support. First clues: After some digging around, we discovered that there were some Java core dumps under the TeamConcert directory. Reading those, it was readily apparent that we simply had a JVM heap size problem. No sweat, right? So, since we were dealing with the shell sharing of the RTC client and the ClearTeam Explorer and did not know which configuration would be used when being launched from MS Visual Studio, we went off and modified the eclipse.ini file under TeamConcert and the ctexplorer.ini under CTE. NEITHER FILE HAD ANY EFFECT. And no one could tell us or find a reference that said where the launch command was or how it was configured when it was initiated from the Visual Studio IDE. The big magic secret: As you may have guessed, it turns out there is a third file that governs the launch. We found this through a big pile of tedious investigation. The file is buried in the ClearCase installation directory at a default location of: C:\Program Files\IBM\RationalSDLC\ClearCase\RemoteClient\WANPackage\ccvsrtcintegration.ini There are 2 problems with this file:
- It is obscure – if you Google for it, you will not find it.
- It uses a JVM call that has limits on its heap size when launching Eclipse. There are a number of technotes about this style of launch, but the one that tipped us off was this one: http://www-01.ibm.com/support/docview.wss?uid=swg1PM52774
The fix: We modified this file to use the JAVAW style launch in the ccvsrtcintegration.ini file. Our ‘finally fixed it’ example is here, though we have tweaked the heap sizes a bit for our environment.
-vm C:\Program Files\IBM\RationalSDLC\common\JAVA5.0\jre\bin\javaw.exe --launcher.appendVmargs(Executable) -vmargs -Xms256m -Xmx512m -Xmnx128m -Xgcpolicy:gencon -Xscmx96m
Update – 5/9/2014
The above .INI file has been edited to include the following line:
This was done to reflect some operational experience with the tool. We discovered that the tuning parameters were not really being respected as one would expect. So, after some investigation and discussion with IBM, we added the line as a way to force it to ignore the command line’s attempt to override the .ini file. Technically the parameter causes the INI files to be appended to the command line no matter what, so the command line that eventually launches the tool is forced to have the tuning parameters. This tweak has so delivered a much more stable end-user experience.
The summary: So, if you are using the CCBridge with Visual Studio and your attempts to launch the association dialogs appear to ‘hang’:
- Check for Java core dumps under TeamConcert
- If you find a heap size or ‘out of memory’ problem in them, look at the ccvsrtcintegration.ini file and modify it to use the javaw.exe launch rather than the DLL.
- Modify your heap sizes as necessary to fine-tune.