dCache 1.9.0-9 Release Notes

dCache 1.9.0-9 is a maintenance release.

Summary

SRM client: reads config file from $HOME/.srmconfig/config.xml.

All: Fixed memory leak in logging system.

Init script: Added dcache version command (thanks to Lionel Schwarz).

FTP door: Fixes a bug minor bug in FTP doors, which could cause a wrong error message to be generated on permission errors.

Info service: Fix null pointer exception.

Info service: Fixed bug in the update logic that caused the info service to loose information about pool groups.

PnfsManager: Performance isolation between databases (see below).

PnfsManager: Use separate queues for cache location operations (see below).

SRM: Fixed a bug that caused some database tables of the SRM to be recreated on every restart.

Upgrade Instructions

There are no restrictions on the upgrade order from 1.9.0-8 to 1.9.0-9. Any mix of 1.9.0-8 and 1.9.0-9 is supported. Please consult the upgrade instructions of previous releases for mixing 1.9.0-8 and 1.9.0-9 components with earlier releases.

PnfsManager has two new configuration parameters: pnfsNumberOfLocationThreads and pnfsNumberOfThreadGroups. The default values are chosen to maintain the exact behaviour of previous releases. The parameters are defined in dCacheSetup and the description from dCacheSetup.template is reprinted below.

#  ---- Number of cache location threads
#
#   The number of threads used for cache location updates and 
#   lookups. If 0 then the regular pnfs manager thread queues are
#   used for cache location lookups. If non-zero then dedicated 
#   threads for cache location operations are created.
#
#pnfsNumberOfLocationThreads=0

#  ---- Number of thread groups
#
#   A PNFS tree may be split into multiple databases. Each database is
#   single threaded and hence accessing the same database from
#   multiple threads provides only a minor speed-up. To ensure good
#   load balancing when using multiple databases, the PnfsManager
#   supports thread groups. Any database is assigned to one and only
#   one thread group, thus databases assigned to different thread
#   groups are guaranteed not to block each other. Each thread group
#   will have $pnfsNumberOfThreads threads.
#
#   For best performance isolation, set this to be equal the largest
#   database ID defined in PNFS. When increasing
#   pnfsNumberOfThreadGroups, you may want to lower
#   pnfsNumberOfThreads.
#
#   Notice that PNFS access is still subject to the number of threads
#   created in the PNFS daemon. If this number is lower than the
#   number of concurrent requests, then contention may still occur
#   even though multiple databases are used.
#
#pnfsNumberOfThreadGroups=1

Changelog