Restore pinboard default log level to info

module: logback.xml

pinboard default log level accidentally set back to debug.  This patch restores it to info.

Patch: http://rb.dcache.org/r/5419
Acked-by: Dmitry
Target: trunk
Require-book: no
Require-notes: no
pool: Revert change to ListenableFuture

Commit d180e90c3a56710797b239d80dcf396bd13b6f7c replaced the use of the
CompletionHandler interface with Guava's ListenableFuture.  The motivation for
this change was that CompletionHandler is an interface for async I/O in NIO 2
as thus isn't intended as a generic callback interface for async operations in
general. Future and ListenableFuture on the other hand are.

I have however discovered that ListenableFuture is seriously flawed when used
for Movers like I did. When a Future is cancelled, it immediately transitions
to the cancelled state and its get method will throw CancellationException. If
the task is already running, it will not wait for the task to complete before
considering the Future to be in a final state. When extended with listeners in
Guava, these semantics are inherited. Ie. as soon as the ListenableFuture is
cancelled, any listeners are invoked with a failure even though the mover has
not yet terminated. One consequence of that is that we would invoke post
processing even though the mover is still running.

Although I don't like the use of CompletionHandler for this use, I decided to
revert the code back to using CompletionHandler - at least until a better
solution is found. For consistency I use the same interface for the post
processing.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5434/
Fix NPE in GenericStorageInfo#equals

GenericStorageInfo has a constructor that allows it to be created
without any HSMs, yet the equals method will fail with an NPE if
such objects are compared.

This patch fixes this problem and also simplifies the remaining
check in the equals method.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5398/
pool: Allow ReplicaDescriptor#getFileAttributes on closed descriptor

The patch achieves two things. First it avoid repeated loads of
FileAttributes from the meta data store during a file transfer.
It does this by storing the file attributes inside the
ReplicaDescriptor instance. Second, it allows these file attributes
to be queried even after the descriptor is closes (which will be
usefull in another patch).

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5399
pool: Fix corruption error message

A file size mismatch was reported as a checksum mismatch.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5426/
pool: Make use of AbstractCell in NFS execution service

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5427/
Add throwable to a couple of more CacheException subclasses

Exceptions are recommended to have constructors that accept a cause.
Note that cause is a Throwable, not an Exception.

Target: trunk
Require-notes: no
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5433/
Add checkum to error message when parsing fails

Patch http://rb.dcache.org/r/5420/ fixed a bug related to checksum
parsing, however the patch didn't fix the fact that the error message
produced omited the problematic checksum string.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5435/
Make CDC AutoCloseable

Makes the CDC AutoCloseable and thus usable with the try-with-resource
construct.

This change was suggested by Paul.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5440/
Exclude Spring internal beans from 'bean ls' output

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5441/
pnfsmanager: Include legacy attributes in storageinfoof CLI output

Fixes a regression introduced in the 2.6 development cycle.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5442/
Revert "pool: Revert change to ListenableFuture"

This reverts commit 22075efe9d1fe2f4e51e7156e80db932209da55d.

I committed the wrong version of the patch.
pool: Revert change to ListenableFuture

Commit d180e90c3a56710797b239d80dcf396bd13b6f7c replaced the use of the
CompletionHandler interface with Guava's ListenableFuture.  The motivation for
this change was that CompletionHandler is an interface for async I/O in NIO 2
as thus isn't intended as a generic callback interface for async operations in
general. Future and ListenableFuture on the other hand are.

I have however discovered that ListenableFuture is seriously flawed when used
for Movers like I did. When a Future is cancelled, it immediately transitions
to the cancelled state and its get method will throw CancellationException. If
the task is already running, it will not wait for the task to complete before
considering the Future to be in a final state. When extended with listeners in
Guava, these semantics are inherited. Ie. as soon as the ListenableFuture is
cancelled, any listeners are invoked with a failure even though the mover has
not yet terminated. One consequence of that is that we would invoke post
processing even though the mover is still running.

Although I don't like the use of CompletionHandler for this use, I decided to
revert the code back to using CompletionHandler - at least until a better
solution is found. For consistency I use the same interface for the post
processing.

Target: trunk
Require-book: no
Require-notes: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5434/
pool: Allow mover queues with zero capacity

PoolV4#mover_set_max_active allows the queue capacity to be set
to zero, yet the AdjustableSemaphore rejects this value (even
though the default capacity for a newly created semaphore is
zero).

Target: trunk
Require-book: no
Require-notes: yes
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/5425/