scripts: allow java8 runtime

Acked-by: Paul Millar
Target: master, 2.9, 2.8, 2.7, 2.6
Require-book: no
Require-notes: no
(cherry picked from commit 4a838d240102db12eaa1d0fc035155e1b22495eb)
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
xrootd: Upgrade to xrootd4j 1.3.3

Fixes IPv6 compatibility for kXR_locate request.

Target: trunk
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: https://rb.dcache.org/r/7034/
(cherry picked from commit cabce532b44e6c3252b3cd344b1feabbd98f65a7)
dcache-webadmin: fix login redirect bug which misleadingly results in Access Denied Page

The following sequence of actions results in an Access Denied Page:

1.  Click on a bookmarked webadmin page (\*\*\* but see Testing below).
2.  On the user panel (below the DCache Bird at far right top),
    click login.
3.  Fill in user/password in login page, and click login.

The problem, which actually exists since Wicket 1.5, is that
the return URL used by Wicket to redirect from the intercept
page actually contains, as its query part, the subcomponent
of the page that generated the intercept request.

The problem is benign because returning to the home page
after the Access Denied Page appears shows that the user
is properly logged in.

In order to maintain correct redirection after intercept,
the only choice seems to be to override the exception-handling
pattern which Wicket uses to control the destination,
and to then force the reset of the target response page.

This is enabled by exposing the previously unexposed constructor
for the BasePage which allows PageParameters to be passed in,
and determining the bookmarked page class from the first
parameter.  If none is set, it then defaults to the home
page, as before.  In order to redirect with to an intercept
page, the RestartResponseAtInterceptPageException thrown
for this purpose should thus be constructed with the log in
page class and page parameters.

At present I cannot determine if there are any preferred
workarounds for this.  The problem presented at this link:

http://apache-wicket.1842946.n4.nabble.com/RestartResponseAtInterceptPageException-problem-in-1-5-td4255020.html

is precisely the one at issue here, but the suggestion
made by the developer is irrelevant.

This bug has actually been present since we migrated from
1.4 to 1.5, but has gone undiscovered until now (or at
least unreported).  Jan's and Tanja's code undoubtedly worked
correctly in the pre-1.5 context in which it was originally
written.

Target: 2.9
Committed: 39c2c0ebc16d97c1446c11c4a7a77c0d4862228f
Acked-by: Tigran
Patch: http://rb.dcache.org/r/6987
Bug: http://rt.dcache.org/Ticket/Display.html?id=8266
Require-book: no
Require-notes: yes

RELEASE NOTES:  Fixes a bug where clicking the login link from the
dCache bird panel on webadmin pages and then signing in via the
login page brings up an Access Denied Page (but which nonetheless
results in the user being properly logged after having
navigated to the home page).

TESTING:

***It is best to use a non-admin page to test this.
The reason is that currently, multiple gids are not
supported for administration access, and unless the
user cert is directly mapped to the admin user, navigating
to an admin page results in an automatic sign-in
via the cert; the user then is required to log out
and log in as admin, so the final response page in
this case is actually the log in page. The problem
of multiple gids will need to be addressed in the future.

After application of this patch, the Access Denied page
no longer appears and the user is redirected back to the
original page after login.
Merge pull request #603 from kofemann/j7-2.9

scripts: allow java8 runtime
Merge pull request #607 from gbehrmann/fix/2.9/rb7034

Fix/2.9/rb7034
Merge pull request #610 from alrossi/fix/2.9/webadmin-login

Fix/2.9/webadmin login
xrootd: Fix error message for read patch check

Target: trunk
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Karsten Schwank <karsten.schwank@desy.de>
Patch: https://rb.dcache.org/r/7035/
(cherry picked from commit 1933780bcd0d1622497d246aec0d7aae2d21dcbd)
Merge pull request #616 from gbehrmann/fix/2.9/rb7035

Fix/2.9/rb7035
xrootd: Quote IPv6 addresses in kXR_redirect replies

The client concatenates the returned host name and the
binary encoded port number into a URI. This fails if
the host name is an IPv6 address as the client fails to
quote the address.

The xrootd spec doesn't say that the server should quote
the address, however the answer we got from the xrootd
developers is that all IPv6 addresses must be quoted by
the server.

This patch quotes the address in the reply. Until the spec
is updated, I consider this a workaround.

Target: trunk
Require-notes: yes
Require-book: no
Request: 2.9
Request: 2.8
Request: 2.7
Request: 2.6
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7046/
(cherry picked from commit 4137a0029247ee5f0bfb864b9fbc927cfbb82309)
Merge pull request #620 from gbehrmann/fix/2.9/rb7046

Fix/2.9/rb7046
[maven-release-plugin] prepare release 2.9.4
[maven-release-plugin] prepare for next development iteration
srm: Fix lock congestion

To support SRM_FILE_BUSY, both get and ls requests scan for active
put requests. This causes lock congestion as reading the SURL of
the put request acquires a read lock, while abort and put done calls
are processed with a write lock (and these calls trigger callouts
to pnfsmanager).

The read lock to access the surl is however unneeded as surl is a
final field. This patch removes the read-lock for surl access. The
patch also removes the read-lock on several other final fields, as
well as marking several fields that are not modified as final.

Target: trunk
Request: 2.9
Request: 2.8
Request: 2.7
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: https://rb.dcache.org/r/7054/
(cherry picked from commit 3ac48ab7b5e81965f900b9546e53f6d0e929a7b0)
pinmanager,srm,spacemanager,xrootd: Fix pool monitor expiration

The pool manager state (aka pool monitor) is cached in a number of
other services. A recent change modified the cache logic to trigger
in-thread asynchronous updates rather than dedicated an entire thread
to the update. The Guava cache class is configured to trigger an update
after 20 seconds, however the update is asynchronous, meaning that the
first access after 20 seconds will still get the old data. There is a
total lifetime of 10 minutes, meaning that once the entry is 10 minutes
old, it is purged and a blocking update is done instead (i.e. you
never get data older than 10 minutes).

Unfortunately the cached pool state in pool monitor is considered
invalid after 5 minutes and the pool is then treated as offline. On
a lightly loaded system this causes some strange effects.

The immediate fix is to reduce the max lifetime to 3 minutes (allowing
some slack up to the 5 minute lifetime of the pool data). An async.
update is still triggered after 20 seconds.

Longer term, the pool information should be channelled directly from
pools to the services that need it.

Target: trunk
Request: 2.9
Require-notes: yes
Require-book: no
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: https://rb.dcache.org/r/7055/
(cherry picked from commit ab39955ff726598e30f8d9ff714b96e1d9bb27ec)
xrootd,nfs: Add support for space management

Xrootd and NFS doors fail to include the space manager in pool manager
requests, thus failing to support space management. Even though the
protocols don't have explicit support for space management, they may
still be used with the WriteToken tag or with implicit reservations.

If space manager is disabled, the message flow is unaffected. Even if
space manager is enabled, read requests or writes to unmanaged space
are simply passed through in space manager (which when space manager
is placed in the same domain as pool manager is fairly cheap).

Target: trunk
Require-notes: yes
Require-book: yes
Acked-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Patch: https://rb.dcache.org/r/7049/
Request: 2.9
Request: 2.8
Request: 2.7
(cherry picked from commit 93e94bee1bf3773cd62b19f0da556ed05e14ee89)
Merge pull request #629 from gbehrmann/fix/2.9/rb7055

Fix/2.9/rb7055
Merge pull request #626 from gbehrmann/fix/2.9/rb7054

Fix/2.9/rb7054
Merge pull request #630 from gbehrmann/fix/2.9/rb7049

Fix/2.9/rb7049
http: fix multipart response size

Acked-by: Paul Millar
Target: master
Require-book: no
Require-notes: no
(cherry picked from commit 5c63d0e26a408eacd1c5d8d8398e47fd3eaad045)
Signed-off-by: Tigran Mkrtchyan <tigran.mkrtchyan@desy.de>
Merge pull request #638 from kofemann/fix-davix-2.9

http: fix multipart response size