(2.9) dcache-webadmin: change Jetty setting so .war is not unpacked

See http://rt.dcache.org/Ticket/Display.html?id=8489.

When upgrading from 2.6 to 2.10, there is a potential
for the webadmin directory timestamps to be more recent
than the timestamp of the /usr/share/dcache/classes/webapps/webadmin.war
file, which then causes Jetty to ignore the new war
and use the old directory. This subsequently provokes
jndi issues because the new httpd.batch file does not
pass through properties that the webadmin spring file
expects to find in the naming and directory interface.

The simplest solution is to turn off unpacking in
versions subsequent to 2.6.

Note that https://rb.dcache.org/r/7436/ does this for master.

Testing:

Installed 2.6.  Then updated to master (this patch) over it,
leaving the old webadmin directory intact.  Httpd confirmed
to start without issues, navigation through pages is normal.

Target: 2.9
Request: 2.8
Request: 2.7
Acked-by: Gerd
Require-book: no
Require-notes: yes

RELEASE NOTES:  The webadmin.war found in /usr/share/dcache/classes/webapps
is no longer unpacked (by default, /var/lib/dcache/httpd).  This
avoids potential conflicts between versions when update installs are run.
alarms:  fix regex for checksum alarm

The alarm definition for CHECKSUM uses the regex

Marking (.+) as BROKEN.

Unfortunately this matches both the error emitted by
the ChecksumScanner

 _log.error("Marking {} as BROKEN: {}", id, e.getMessage());

as well as the broken file message from WriteHandleImpl:

 _log.warn("Marking pool entry as BROKEN");

The latter should not produce an alarm.

The regex for the CHECKSUM alarm has been made more specific
in order to exclude matching the latter logging statement.

Note that the changes to alarms in 2.11 render this
patch unnecessary for 2.11 or master.

Target: 2.10
Request: 2.9
Request: 2.8
Reqeust: 2.7
Reqeust: 2.6
Acked-by: Dmitry
Require-notes: no
Require-book: no
webadmin: Fix ClassCastException in cell admin

Fixes

07 nov. 2014 23:32:44 (httpd) [] RuntimeException while executing runnable org.dcache.cells.CellStub$1@135dac1f with executor com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService@12afd1d3
java.lang.ClassCastException: java.lang.String cannot be cast to diskCacheV111.vehicles.Message
        at org.dcache.cells.CellStub$1.run(CellStub.java:503) ~[dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297) [guava-17.0.jar:na]
        at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156) [guava-17.0.jar:na]
        at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145) [guava-17.0.jar:na]
        at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185) [guava-17.0.jar:na]
        at org.dcache.cells.CellStub$CallbackFuture.set(CellStub.java:594) [dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at org.dcache.cells.CellStub$CallbackFuture.answerArrived(CellStub.java:616) [dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$CallbackTask.innerRun(CellNucleus.java:1050) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:1005) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297) [guava-17.0.jar:na]
        at dmg.cells.nucleus.CellNucleus.addToEventQueue(CellNucleus.java:813) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellGlue.sendMessage(CellGlue.java:557) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus.sendMessage(CellNucleus.java:371) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellAdapter.messageArrived(CellAdapter.java:831) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$DeliverMessageTask.innerRun(CellNucleus.java:1095) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:1005) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_20]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_20]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_20]

The problem was hidden by the use of a raw type and thus the compiler didn't
reject the code.

Target: trunk
Request: 2.11
Request: 2.10
Request: 2.9
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7478/
(cherry picked from commit 0b23cfca5c0faf2019dfcaa332875d00908c94f8)
Merge pull request #1066 from alrossi/fix/2.9/checksum-regex

alarms:  fix regex for checksum alarm
Merge pull request #1072 from gbehrmann/fix/2.9/rb7478

webadmin: Fix ClassCastException in cell admin
[maven-release-plugin] prepare release 2.9.14
[maven-release-plugin] prepare for next development iteration
alarms.properties fix accidental header corruption

Present only on 2.10 and 2.9 branches.

Target: 2.10
Require-book: no
Require-notes: no
Merge pull request #1077 from alrossi/fix/2.9/alarms-properties-header

(2.9) alarms.properties fix accidental header corruption
Merge pull request #1029 from alrossi/fix/2.9/war-no-unpack

(2.9) dcache-webadmin: change Jetty setting so .war is not unpacked
[maven-release-plugin] prepare release 2.9.15
[maven-release-plugin] prepare for next development iteration
dcache-webadmin: revert rrd data source names

The following releases

2.10.8
2.9.12
2.8.16
2.7.21
2.6.36

introduced improvements to the pool queue plots code
which also unfortunately altered the data source names
(mainly in order to eliminate NaNs from the underlying
store). This results in an incompatibility with
existing .rrd files preventing plot generation (see
the exception trace below).

While the round-robin datastore is transient (the old
default was 15 days of queue information, now changed to 2)
and can be eliminated and then recreated afresh, this
patch restores the old names, so that upgrades from before
these releases to the current will avoid this issue.
It turns out that the storing of NaNs has no impact
on the principal issue the original patch was trying
to address (faulty stacked rendering of histogram bars).

Those who have already moved to the indicated releases
will see the stack trace again and will have
to remove the .rrd files.  Those upgrading from
a version prior to those indicated will experience
no such error.

Target: master
Patch: https://rb.dcache.org/r/7434
Acked-by: Tigran
Require-book: no
Require-notes: yes

RELEASE NOTES:  Those upgrading to

2.10.8
2.9.12
2.8.16
2.7.21
2.6.36

Will experience an error message regarding the pool-queue plots reporting "Unknown datasource name".
The problem can be fixed in the following ways:

1) No upgrade.  Do:

dcache stop httpdDomain
rm -f /var/lib/dcache/plots/*.rrd
dcache start httpDomain

2) Upgrade to this release.

If a fix such as 1) was applied, and then an upgrade is done, 1) will have to be reapplied.

Upgrading from a version preceding the listed versions to this one should experience no
such error.
pool: Avoid interrupting Berkeley DB in migration module server

Berkeley DB for Java doesn't like thread interrupts, and the pool tries to
never interrupt threads while they update the meta data database. We however
missed at least one case:

17 Nov 2014 11:11:10 (ore_ndgf_org_001) [ore_ndgf_org_002 PoolMigrationCopyReplica 00007D0EC04343684CF6A5F78B289361CD7B] Fault occured in repository: Internal repository error
diskCacheV111.util.CacheException: No transaction is active
        at org.dcache.pool.repository.meta.db.CacheRepositoryEntryImpl.setSticky(CacheRepositoryEntryImpl.java:225) ~[dcache-core-2.10.10.jar:2.10.10]
        at org.dcache.pool.repository.v5.CacheRepositoryV5.setSticky(CacheRepositoryV5.java:890) [dcache-core-2.10.10.jar:2.10.10]
        at org.dcache.pool.repository.v5.CacheRepositoryV5.setSticky(CacheRepositoryV5.java:600) [dcache-core-2.10.10.jar:2.10.10]
        at org.dcache.pool.migration.MigrationModuleServer$Request.run(MigrationModuleServer.java:301) [dcache-core-2.10.10.jar:2.10.10]
        at org.dcache.util.CDCExecutorServiceDecorator$1.run(CDCExecutorServiceDecorator.java:104) [dcache-core-2.10.10.jar:2.10.10]
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) [na:1.7.0_71]
        at java.util.concurrent.FutureTask.run(FutureTask.java:262) [na:1.7.0_71]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:178) [na:1.7.0_71]
        at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:292) [na:1.7.0_71]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [na:1.7.0_71]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [na:1.7.0_71]
        at java.lang.Thread.run(Thread.java:745) [na:1.7.0_71]

This patch fixes this problem.

Target: trunk
Request: 2.11
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>
Acked-by: Karsten Schwank <karsten.schwank@desy.de>
Patch: https://rb.dcache.org/r/7509/
(cherry picked from commit 19d6b127d170c700f1fd77afdfd65846aab1fc0a)
Fix NPE in httpd service

The patch fixes the following NPE:

17 nov. 2014 11:52:48 (poolCollector) [] RuntimeException while executing runnable com.google.common.util.concurrent.Futures$5@2437e8e6 with executor com.google.common.util.concurrent.MoreExecuto
rs$SameThreadExecutorService@3f726b8a
java.lang.NullPointerException: null
        at java.util.TreeMap.rotateLeft(TreeMap.java:2220) ~[na:1.8.0_25]
        at java.util.TreeMap.fixAfterInsertion(TreeMap.java:2287) ~[na:1.8.0_25]
        at java.util.TreeMap.put(TreeMap.java:582) ~[na:1.8.0_25]
        at diskCacheV111.services.web.PoolCellQueryContainer.put(PoolCellQueryContainer.java:57) ~[dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at diskCacheV111.services.web.PoolInfoObserverV3$2.onSuccess(PoolInfoObserverV3.java:140) ~[dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at diskCacheV111.services.web.PoolInfoObserverV3$2.onSuccess(PoolInfoObserverV3.java:134) ~[dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at com.google.common.util.concurrent.Futures$5.run(Futures.java:1231) ~[guava-17.0.jar:na]
        at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297) [guava-17.0.jar:na]
        at com.google.common.util.concurrent.ExecutionList.executeListener(ExecutionList.java:156) [guava-17.0.jar:na]
        at com.google.common.util.concurrent.ExecutionList.execute(ExecutionList.java:145) [guava-17.0.jar:na]
        at com.google.common.util.concurrent.AbstractFuture.set(AbstractFuture.java:185) [guava-17.0.jar:na]
        at org.dcache.cells.CellStub$CallbackFuture.set(CellStub.java:594) [dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at org.dcache.cells.CellStub$CallbackFuture.answerArrived(CellStub.java:616) [dcache-core-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$CallbackTask.innerRun(CellNucleus.java:1050) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:1005) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at com.google.common.util.concurrent.MoreExecutors$SameThreadExecutorService.execute(MoreExecutors.java:297) [guava-17.0.jar:na]
        at dmg.cells.nucleus.CellNucleus.addToEventQueue(CellNucleus.java:813) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellGlue.sendMessage(CellGlue.java:557) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus.sendMessage(CellNucleus.java:371) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellAdapter.messageArrived(CellAdapter.java:831) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$DeliverMessageTask.innerRun(CellNucleus.java:1095) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:1005) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_25]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]

The patch also changes a few return types from Set to List, as the code
is more concerned about the ordering that uniqueness (and the items in
the list are still unique). Changed a TreeMap to a more efficient
HashMap.

Target: trunk
Request: 2.11
Request: 2.10
Request: 2.9
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Acked-by: Karsten Schwank <karsten.schwank@desy.de>
Patch: https://rb.dcache.org/r/7510/
(cherry picked from commit 5ee36f25234a07747e0d1b90de72141f7abdbbd8)
Fix NPE in cell initialization

Cells block delivery of messages until they have been started. Prior to being
started the message is returned to the sender. The code however suffers from a
race resulting in the following exception:

17 nov. 2014 15:01:17 (SrmSpaceManager) [] Uncaught exception in thread SrmSpaceManager-0
java.lang.NullPointerException: null
        at dmg.cells.nucleus.CellAdapter.getCellName(CellAdapter.java:325) ~[cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellAdapter.messageArrived(CellAdapter.java:784) ~[cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$DeliverMessageTask.innerRun(CellNucleus.java:1095) ~[cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at dmg.cells.nucleus.CellNucleus$AbstractNucleusTask.run(CellNucleus.java:1005) ~[cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [na:1.8.0_25]
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [na:1.8.0_25]
        at dmg.cells.nucleus.CellNucleus$3.run(CellNucleus.java:696) [cells-2.12.0-SNAPSHOT.jar:2.12.0-SNAPSHOT]
        at java.lang.Thread.run(Thread.java:745) [na:1.8.0_25]

The cause is the classic problem of leaking a reference to an object in its
constructor. In this case CellNucleus registers itself with CellGlue inside
its constructor, meaning that others may deliver messages to it even before
the final nucleus member in CellAdapter has been initialized.

This minimal patch moves the CellGlue registration into a new CellNucleus#start
method. The method is called right after the constructor returns. The patch
is kept small to allow it to be backported, however a subsequent patch for trunk
will change the code further to not start the CellNucleus until the cell has
been started, thus solving the problem of early message delivery.

Target: trunk
Request: 2.11
Request: 2.10
Request: 2.9
Request: 2.8
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Acked-by: Karsten Schwank <karsten.schwank@desy.de>
Patch: https://rb.dcache.org/r/7511/
(cherry picked from commit 019e10e1eef0469e447e4a80bde1a8e708ae2de3)

Conflicts:
	modules/cells/src/main/java/dmg/cells/nucleus/CellNucleus.java

(cherry picked from commit 6762e044e43066fd82d2835a6d344d044a68b513)
Merge pull request #1100 from gbehrmann/fix/2.9/rb7511

Fix NPE in cell initialization
Merge pull request #1097 from gbehrmann/fix/2.9/rb7510

Fix NPE in httpd service
Merge pull request #1091 from gbehrmann/fix/2.9/rb7509

pool: Avoid interrupting Berkeley DB in migration module server
Merge pull request #1085 from alrossi/fix/2.9/revert-rrd4j-sourcename

(2.9) dcache-webadmin: revert rrd data source names