VOMS clients v. 3.0.3 and VOMS Java APIs v. 3.0.1

21 Aug 2013

The VOMS Product Team is pleased to announce the release of VOMS clients v. 3.0.3 and VOMS Java APIs v. 3.0.1.

This release provide several bug fixes, as highlighted in the release notes for the clients and the APIs. Packages can be obtained from our repositories and will soon be available on the EMI-3 repository. Follow the instructions in the releases section.

As you may already know by now, version 3 of the clients are a full rewrite based on the VOMS Java APIs 3.x which are in turn based on CAnL. The main advantages of the new clients are:

a code base that is much easier to maintain and evolve
improved error messages and debugging
full SHA-2 compliance

In order to avoid regressions as much as we could we introduced a testsuite based on the Robot framework. Each time a new issue is found or new functionality is added, new tests are added to verify the correct behaviour of the clients.

One of the problems solved with this release was spotted by this incident, which showed that VOMS clients version 3.0.x broke the WLCG VO box. In particular, it was no longer possible to renew a credential stored in a MyProxy server. This issue was caused by the wrong order in which PEM fragments were serialized to file when storing a VOMS proxy, and was quite easy to fix. Tests were also added to the testsuite to continuosly verify that the clients work as expected with MyProxy.

There are times however when it is not possible or convenient to add a test for a given regression. This incident showed a strange behaviour of the clients which was observed only in setups with very large amounts of RAM (128G). When the Java VM is started without specifiying explicitly heap memory limits, java reclaims a given fraction of the available memory for its process. On WLCG worker nodes, that can be equipped with lots of RAM (> 128G), the memory reclaimed by the Java VM hit the shell limit set for the maximum amount of virtual memory that a process can reclaim, and the clients failed to start. Actually, even

java --version

would have failed in such environment. The solution for this was to explicitly constrain the memory requested by the clients in the clients startup script to a more sensible value (i.e. 16mb).