(2.9) webadmin: minor improvements to rrd4j-based pool-queue plots

There seems to be a bug in the rrd4j code. I have
reported this but am not confident anything will be done about it, since
version 2.2 came out in June of 2013 and no activity is evident
since then. In reality, the bug has already been discovered,
but the original reporter did not follow up by providing
a concrete case or data for verification. This is what I provided.

https://code.google.com/p/rrd4j/issues/detail?id=44

In essence, it seems that the stacked graphs are subject to
ghost artifacts which create a different colored border around
the area; if the time steps are narrow enough, this actually
can look as though it were displaying non-zero values for
a different data set. See the attached for comparison of
24, 48 and 96-hour graphs of the same data.

In the course of investigating this problem, I did discover
that the code was allowing unfeasible mappings of minimum
timesteps to fractions of a pixel. This has now been fixed
by automatically adjusting the width; the code also forces
at least two pixels per timestep (cfr. the 96-hour graph)
by expanding the width. This at least guarantees a certain
amount of legibility and mitigates the border-bug.

A number of other minor improvements and adjustments were
made:

-    The histogram has been slightly rewritten for efficiency;
-    An interface has been added to facilitate (1).
-    Use of the source name derived from the enum has been regularized.
-    "!" has been appended to this name, to enforce, according to rrd4j
        convention, the conversion of NaNs to 0.0s.
-    The separate refresh interval has been eliminated. The sampling should
        be congruent with the minimum time step.
-    Local variables have been added for re-used values.
-    The plot display names were being set to ALL CAPS for aesthetics/readability;
        this has been removed to favor easy cut & paste into the filter
        from other sources such as the logs or directory listings.
-    Default values for time span have been changed to something more reasonable
        (48 hours rather than two weeks).

Target: 2.9
Acked-by: Karsten
Require-book: no
Require-notes: yes
Committed: d05087656c66d036914c033b601d04cc1fdb5882

NOTE: The refresh property need not be removed in the backports (it will
just be ingored by the code).

Testing: Redeployed and observed plotting behavior (see attached) on testbed.

RELEASE NOTES:

Small adjustments to the pool queue plots in order to improve
appearance.  Some property defaults have been changed.  Note:
this patch does not entirely remedy what appears to be a bug
in rrd4j (see https://code.google.com/p/rrd4j/issues/detail?id=44).
pool: Fix pool selection bugs in migration module

There were two bugs in migration module:

- Random pool selection would select pools even when they are full.

- Proportional pool selection would trigger a NPE as it would return
  null when all pools are full.

Target: trunk
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7362/
(cherry picked from commit 55de0de55cc6940f6204dee68e29ec24a13c75d3)

Conflicts:
	modules/dcache/src/main/java/org/dcache/pool/migration/Task.java

(cherry picked from commit d85629dfba3027144ae0664d84120e2d0ce4bd92)
cell: Log exceptions within the correct cell context

Target: trunk
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7363/
(cherry picked from commit 272bfe8b53d7f01cba0a87278b95235b1ccb6544)
Merge pull request #922 from gbehrmann/fix/2.9/rb7362

pool: Fix pool selection bugs in migration module
Merge pull request #927 from gbehrmann/fix/2.9/rb7363

cell: Log exceptions within the correct cell context
Marked refresh properties obsolete.
(2.9) webadmin: fix exit login in billing refresh loop

Currently the thread which refreshes the billing plots
will exit if it encounters an unspecified error from
the billing service. But this behavior does not
take into account slow start-up of domains (i.e.,
the billing service may not be there yet but will
be eventually).

The patch fixes the logic to treat NoRouteToCell
exceptions differently by waiting for a short time
and retrying.

Testing done: On deployed service without billing,
and then with billing booted.

Target: 2.9
Patch: https://rb.dcache.org/r/7306
Acked-by: Gerd
Committed: b315fc0e4c5fdde59d926dea43706079b4957b8f
Require-note: yes
Require-book: no

RELEASE NOTES:
Fixes a bug where a simple timeout (NoRouteToCell) causes an
exit from the billing service refresh loop requiring a restart
of the domain in order to reconnect.
Made PoolQueuePlotData enum compatible with java 8.
pool: Fix ISE in 'rep ls'

Target: trunk
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7369/
(cherry picked from commit f743599fc7cc72d7a3b88fda030d088df2096bd0)
pool: Fix ISE in CacheEntryImpl#toString

Fixes

18 Sep 2014 12:57:38 (pdc_kth_se_034) [admin] Uncaught exception in thread sweeper-free
java.lang.IllegalStateException: Attribute is not defined: STORAGEINFO
        at org.dcache.vehicles.FileAttributes.guard(FileAttributes.java:150) ~[dcache-core-2.8.4.jar:2.8.4]
        at org.dcache.vehicles.FileAttributes.getStorageInfo(FileAttributes.java:296) ~[dcache-core-2.8.4.jar:2.8.4]
        at org.dcache.pool.repository.v5.CacheEntryImpl.toString(CacheEntryImpl.java:139) ~[dcache-core-2.8.4.jar:2.8.4]
        at java.lang.String.valueOf(String.java:2854) ~[na:1.7.0_51]
        at java.lang.StringBuilder.append(StringBuilder.java:128) ~[na:1.7.0_51]
        at org.dcache.pool.classic.SpaceSweeper2.reclaim(SpaceSweeper2.java:335) ~[dcache-core-2.8.4.jar:2.8.4]
        at org.dcache.pool.classic.SpaceSweeper2.access$000(SpaceSweeper2.java:39) ~[dcache-core-2.8.4.jar:2.8.4]
        at org.dcache.pool.classic.SpaceSweeper2$1.run(SpaceSweeper2.java:209) ~[dcache-core-2.8.4.jar:2.8.4]
Waiting for data... (interrupt to abort)

Target: trunk
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7368/
(cherry picked from commit c91e19508b7c32999c8ffc90ada0f1235ccf2dfc)
pool: Fix race leading to false positices in pool size health checks

The pool would register free space before actually deleting the file
from the file system. Thus for a brief moment, the pool would appear
to have more free space that is available on disk.

Target: trunk
Require-notes: yes
Require-book: no
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7367/
(cherry picked from commit dbd6b7043bca392f4ef5487b5889dadd828fec31)
Merge pull request #938 from gbehrmann/fix/2.9/rb7369

pool: Fix ISE in 'rep ls'
Merge pull request #943 from gbehrmann/fix/2.9/rb7368

pool: Fix ISE in CacheEntryImpl#toString
Merge pull request #948 from gbehrmann/fix/2.9/rb7367

pool: Fix race leading to false positices in pool size health checks
Merge pull request #904 from alrossi/fix/2.9/rrd4j-issues

(2.9) webadmin: minor improvements to rrd4j-based pool-queue plots
Merge pull request #933 from alrossi/fix/2.9/httpd-billing-timeout

(2.9) webadmin: fix exit login in billing refresh loop
spacemanager: Suppress transient deadlock resolution errors

When having non-trivial concurrent transactions, it is not unusual that
these transactions may conflict and cause deadlocks. An RDBMS will detect
such deadlocks and role back one or more of the involved transactions
to allow the rest to complete. An application is supposed to retry such
a failed transaction.

Space manager does catch and retry such transient failures. At the time
I didn't know which transient failures to expect, so I limited it to three
retries and added log output on each. After we have run the new space
manager in production, I see that DeadlockLoserDataAccessException happens
during load. This exception is absolutely expected from the RDBMS and
indiciates that the present transaction lost in conflicting updates and
has to be retried. The RDBMS should ensure that there is progress (ie
no livelock in which all transactions always fail and are retried), so
it is safe to retry such a failed transaction until it succeeds.

Therefore this patch removes the retry limit for this failure and also
lowers the log output to debug.

I will as a separate activity investigate whether some of the observed
deadlocks are avoidable (using normal deadlock prevention techniques)
and thus improve throughput.

Target: trunk
Request: 2.10
Request: 2.9
Request: 2.8
Require-notes: yes
Require-book: no
Acked-by: Karsten Schwank <karsten.schwank@desy.de>
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7371/
(cherry picked from commit 31dfdba81ebb393faf884915e3b7437f4fa7771e)
Merge pull request #953 from gbehrmann/fix/2.9/rb7371

spacemanager: Suppress transient deadlock resolution errors
pool: Fix pool size health check in case of asynchronous release of space

We have observed that operating sometimes don't report freed space
right away when deleting files. This was observed on Linux (using ext4
and Mac OS X), but the behaviour can likely be observed on many other
systems.

The pool periodically checks the free space on the pool partition and
compares it with its own internal account of free space. If the partition
does not have enough free space, the pool size is reduced accordingly.

If the operating system does not report free space right after a file
has been deleted, it may happen that the pool's internal account object
has registered free space that isn't yet reported as free by the operating
system. In that case, the periodic health check may falsely reduce the
pool size.

The patch fixes this by introducing a 60 second grace period after
the pool deletes a file. During this period, the pool size health
check is suppressed.

Target: trunk
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7366/
(cherry picked from commit b7211458b3af38206594a36a72eb87b09ffeeaee)

Conflicts:
	modules/dcache/src/main/java/org/dcache/pool/repository/v5/CheckHealthTask.java

(cherry picked from commit 97fa65a2862d7169810ba3313c9f158a20bf2de0)
chimera: fix unit tests

Two unit tests are racy because they assume at least 1 ms has elapsed
between two calls to stat.  This patch has the testing thread sleep
for a millisecond to ensure this is true.

The patch also alters how the directory listing helper handles invalid
situations, with it throwing an exception rather than logging an error.
This allows the unit-test that checks this behaviour to do so without
logging the error.

Target: master
Request: 2.10
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6

Conflicts:
	modules/chimera/src/main/java/org/dcache/chimera/DirectoryStreamHelper.java
	modules/chimera/src/test/java/org/dcache/chimera/DirectoryStreamHelperTest.java