chimera: special files mtime should be always current time

recently added '.(get)(<file>)(locality)' special file uses mtime from the original file.
As file is not changes the mtime get not updated. This tells NFS client that content is
not changes and cached value is OK.

Set mtime always to be current time to invalidate NFS client cache.

Acked-by: Paul Millar
Target: trunk, 2.6
Require-book: no
Require-notes: no
patch: http://rb.dcache.org/r/5471/
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
pool: Fix CPU spin in Netty based transfer services

Netty 3.5.7 modified the channel factory to no longer lazily
instatiate the worker threads at channel registration. Instead
it starts the workers in its constructor.

In some cases - and I haven't figured out exactly what those
cases are - the resulting worker begins to spin on the empty
selector. This may be a problem limited to Mac OS X, or it
may be a more generic problem.

I tried to write a test program to reproduce the problem, but
the problem is not easy to reproduce. For this reason it is
also difficult to report this problem to the Netty project.

As a solution this patch adds lazy instantiation of the channel
factory. Althoug one may consider this a woraround, the change
is necessary to avoid instantiating the worker unless we need
them. The premis that creating the channel factory early is cheap
no longer holds.

Target: trunk
Request: 2.6
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5466/
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
spacemanager: fix NPE and corresponding logging

Acked-by: Paul Millar
Target: trunk, 2.6
Require-book: no
Require-notes: no
Patch: http://rb.dcache.org/r/5484/
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
nfs: add a possibility to list exports per host

Acked-by: paul Millar
Target: trunk, 2.6
Require-book: no
Require-notes: yes
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
gplazma: Remove internal principals from reply

Addresses compatibilty issues between 2.2 head nodes and 1.9.12 pools.

Some plugins, like the kpwd plugin, do not fill well into gPlazma 2's
architecture. The kpwd file plays the role of all four steps of a
gPlazma login and the plugin must do tricks to pass information from
one phase to the next. It does this by injecting a KpwdPrincipal that
holds the kpwd record.

Unfortunately, this principal escapes gPlazma and is passed along to
other dCache components as part of the Subject. Besides exposing
plugin specific internal principals, and making the subject unnecessarily
larger, this poses a compatbility problems with 1.9.12 pools - these
pools do not have the means to deserialize the internal KpwdPrincipal.

This patch solves the problem by removing all non-public principals
before constructing the gPlazma reply.

Target: trunk
Request: 2.6
Request: 2.2
Require-notes: yes
Require-book: no
Patch: http://rb.dcache.org/r/5487/
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
pool: Make access time update non-blocking

Addresses a performance issue when reading files from a pool.

Patch http://rb.dcache.org/r/4568/ modified the pool to let access
time be updated whenever a file is read. The update is however blocking,
which means that the notification thread in the pool is blocked until
a reply from PnfsManager is received. Given that we do not use the
reply for anything, we can just as well turn the access time update
into a non-blocking notification.

Target: trunk
Request: 2.6
Require-notes: no
Require-book: no
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: http://rb.dcache.org/r/5472/
Merge pull request #2 from dCache/fix/2.6/gplazma-internal-principals

gplazma: Remove internal principals from reply
Merge pull request #4 from dCache/fix/2.6/pool-atime-notification

pool: Make access time update non-blocking
pool: Don't claim a restore was successfull when it failed

Addresses the issue that the pool logs "File successfully
restored from tape" no matter whether the restore was
successful or not.

Target: trunk
Request: 2.6
Request: 2.2
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5485/
Merge pull request #7 from dCache/fix/2.6/dont_claim_success_on_failed_restore

pool: Don't claim a restore was successfull when it failed