rpm,deb: limit max open files to 65535

Good enough

Acked-by: Paul Millar
Target: master
Require-book: no
Require-notes: no
dcache (billing): rewrite triggers to eliminate multiple repeated updates

This is the first in a series of patches which seek to improve the billing insert performance.

The issue was brought forward by U. Michigan (Tier 2) when their 2.2 installation began to experience OOM in the billing domain.  After repeated attempts at diagnosis, with provisional patches deployed and observed using jConsole and their logs rsync'd to a web page, it was finally discovered that the root cause of their problem was the fact that the triggers attached to the main (fine-grained) billing tables, which derive aggregate data to be inserted into a subset of 24-hour tables, were being defeated by the way PostgreSQL implements M.V.C.C.  In particular, each UPDATE is actually a creation of a new row (rather than a change to the existing one). The old row still exists and has an older transaction id associated with it. If these old rows are not cleaned by autovacuum, then eventually we run out of transaction ids and a full vacuum is required, locking up a table completely.  HOT (Heap Only Tuples), which allows in-place updates, does so only for rows that do not contain unindexed columns.

In order to avoid multiple frequent updates, the triggers have been rewritten to check for the maximum dated entry and only insert a new row if the current time has exceeded 24 hours since that time.  The single operation is slightly more expensive, because it aggregates from the maximum time to the present, adding the appropriate missing rows, but our measurements for aggregation over 50M rows+ was approximately 1 minute, which we observed under continuous load was sustainable. In the case of a first entry into an empty aggregate table, the backward aggregation is limited to a 24-hour period.

Two notes are in order.  First, there are no doorinfo triggers, and it is only there that the datestamp frequently reflects the beginning of an operation greater than 24 hours prior to its being registered (since the request could be cached).  The storage and billing data does not usually reflect such long periods (we queried our production systems and found very few instances where the actual mover timestamp suggested a transfer lasting greater than 24 hours, and all of these were from more than two or three years in the past).  The reason that this matters is that once the new tuple/entry is aggregated, it never gets updated after that.  Given the very low frequency of these occurrences, the statistical error of the aggregated value is negligible.  If it becomes desirable to catch these cases, there are a couple of potential remedies:  increase the "window", so that we aggregate only after a longer period (say 48 vs. the current 24 hours), or we simply do an update operation on these outliers (which is slightly more costly), perhaps using a separate trigger.

Second, the triggers are not DRY.  The problem, however, is that to achieve reuse for anything more than the simple alternative values of a parameter on a given table, the function would need to be parameterized against tables and column names, requiring dynamic SQL which would then be executed, defeating the purpose -- which is to make the trigger as efficient as possible.

Finally, we have directly altered the hsqldb liquibase changesets, since the database is recreated when system-tests is rebuilt.

It should also be noted that one field on the billinginfo_tm_daily table has been altered (name changed from totaltime to average) in order to store the average rather than computing it in memory.  The changeset provides the update logic, which should not be extremely costly as the number of rows in the table will be no more than 366 per year of data taken.

A separate patch for version 2.2 will be posted.

Testing:

Built system test and ran. Deployed rpm, ran stress tests (plain SQL and full billing message passing), observing performance and queues.

Further discussion at

https://srm.fnal.gov/twiki/bin/view/DcacheCorner/BillingDatabase#PERFORMANCE_OBSERVATIONS_AND_ISS;

see in particular the final performance graphs:

https://srm.fnal.gov/twiki/bin/view/DcacheCorner/BillingDatabase#Modified_triggers

UMichigan Atlas T2 deployed the triggers on Septeber 5th and have not experienced an OOM so far:

http://head01.aglt2.org:2288/

Target: master
Request: 2.7
Request: 2.6
Patch: http://rb.dcache.org/r/5983/
Bug: http://rt.dcache.org/Ticket/Display.html?id=7915
Require-book: no
Require-notes: yes
Acked-by: Dmitry

RELEASE NOTES:

Fixes a problem with the billing database triggers which under continuous heavy loads (> 300 Hz of billing messages) led eventually to an Out-Of-Memory error in the billing domain.
webadmin: eliminate system-specific dir for unpacking of war file

The directory where the webapp war should be unpacked is currently set to /var/tmp.  This location, however, is susceptible on some systems to periodic deletion, in which case the web application fails to be found by the server.

For this version, we have simply switched this location to /var/lib/dcache/httpd.

Separate patch for 2.6 will be posted.

Testing:

Built rpm and ran instance, checking for presence of webapp directory in /var/lib/dcache/httpd, and for sanity of webadmin pages.

Target: master
Request: 2.7
Patch: http://rb.dcache.org/r/6002
Require-book: no
Require-notes: yes
Bug: http://rt.dcache.org/Ticket/Display.html?id=7979
Acked-by: Paul

RELEASE NOTES:

Fixes bug where on some systems automatic cleanup of temporary directories was eliminating the webapp application files and thus causing the webadmin pages to fail to be found.
srmclient: Fix failure detection

Addresses an issue in failure reporting for failed SRMv1 requests.

SRM v1 on master is currently broken. Our srmclient however provides a secondary
and non-informative failure:

srmcp -1 file:////bin/bash srm://localhost:8443/disk/test-1379612127-1/a
Thu Sep 19 19:35:50 CEST 2013: incorrect number of RequestFileStatusesin RequestStatus expected 1 received 0
Thu Sep 19 19:35:50 CEST 2013: java.io.IOException: incorrect number of RequestFileStatusesin RequestStatus expected 1 received 0
srm copy of at least one file failed or not completed

This is caused by the SRM client checking the number of file-level status
entries before it checks the status of the response itself. This patch resolves
the issue. The client now produces:

srmcp -1 file:////bin/bash srm://localhost:8443/disk/test-1379612984-1/a
Thu Sep 19 19:50:04 CEST 2013: rs.state = Failed rs.error = getRequestStatus(): request #-2147483645 owned by [GidPrincipal[1000,primary], UidPrincipal[1000], S:/127.0.0.1, UserNamePrincipal[behrmann], /O=Grid/O=NorduGrid/OU=nordu.net/CN=Gerd Behrmann] read-write / does not belong to user [GidPrincipal[1000,primary], UidPrincipal[1000], S:/127.0.0.1, UserNamePrincipal[behrmann], /O=Grid/O=NorduGrid/OU=nordu.net/CN=Gerd Behrmann] read-write /
Thu Sep 19 19:50:04 CEST 2013: java.io.IOException: rs.state = Failed rs.error = getRequestStatus(): request #-2147483645 owned by [GidPrincipal[1000,primary], UidPrincipal[1000], S:/127.0.0.1, UserNamePrincipal[behrmann], /O=Grid/O=NorduGrid/OU=nordu.net/CN=Gerd Behrmann] read-write / does not belong to user [GidPrincipal[1000,primary], UidPrincipal[1000], S:/127.0.0.1, UserNamePrincipal[behrmann], /O=Grid/O=NorduGrid/OU=nordu.net/CN=Gerd Behrmann] read-write /
srm copy of at least one file failed or not completed

I am aware of the double logging (caused by logging and throwing an
exception), however that's a different problem and not addressed by
this patch.

Target: trunk
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Patch: http://rb.dcache.org/r/6019/
srm-client: Added missing srm-abort-files options in help text

Target: trunk
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6028/
srm: Introduce srm-common module and rename existing srm modules

Addresses bloat in the srmclient packages.

srmclient relies on srm for protocol and utility classes. The dependency
causes the srmclient packages to include lots of transitive dependencies
not actually needed by the client. Those dependencies increase the size
of the RPM and increase the startup time of the clients as the classpath
is longer.

This patch moves those classes to a new srm-common module. The srmclient
module is renamed to srm-client and the srm module to srm-server; this
follows the naming scheme used by other modules.

The patch also restricts the scope of some powermock components to
testing. This avoid that these are included in the final product.

The effect of the pathc is that the RPM shrinks from a bit above 16 MB
to sligthly below 8 MB.

The patch removes a few old build files and build instructions that
no longer apply.

Target: trunk
Require-notes: yes
Require-book: no
Acked-by: Paul Millar <paul.millar@desy.de>
Patch: http://rb.dcache.org/r/6024/
srm: Fix authorization for srmv1 requests

Addresses an authorization regression in SRMv1 support.

When AuthorizationRecord was replaced by DcacheUser, SRMv1 authorization
broke. The SRMv1 code relies on SRMUser#equals to determine whether
the request query or update came from the same user that created the
request in the first place. Since DcacheUser doesn't implement equals,
this check always fails.

Rather than implement DcacheUser#equals, the SRM code is updated to
compare the IDs of the users instead. This SRM specific user identifier
is what is stored in the database, and in contrast to the DcacheUser
record, the ID can be restored from disk. The ID also ignores principals
like the Origin, which means that a request query or update will be
authorized even when issued from a different client host.

The patch only affects srmv1. Apparantly srmv2 doesn't do any
authorization checks.

Target: trunk
Request: 2.7
Require-notes: yes
Require-book: no
srm: Inject data source and transaction manager from Spring

The patch gets rid of the JdbcConnectionPool class. The BoneCP
dataSource and transaction manager are instantiated by Spring
and injected into the classes that operate on them.

Besides simplifying the code, the patch has the admin visible
consequence that only one connection pool is created in the
SRM. Previously there was one for the authentication store and
one for the remaining SRM tables. These are now served by a
single BoneCP connection pool (the wonders of using
standardized interfaces...).

New properties are:

srm.db.connections.partition-count=1
srm.db.connections.max-per-partition=50
srm.db.connections.min-per-partition=1

Target: trunk
Require-notes: yes
Require-book: yes
srm: Treat TReturnStatus as immutable

Replaces most TReturnStatus instantiations to treat the object as
immutable. Since TReturnStatus is auto-generated, it isn't possible
to actually make it immutable, but our code becomes cleaner if we
treat it as if it was.

I deliberately didn't change any of the status messages, except when
it was obviously wrong. Subsequent patches will focus on the status
messages.

Target: trunk
Require-notes: no
Require-book: no
srm: Clean up SRMServerV2

- Make fields private and final
- Use class name as name of the logger and make logger static and final
- Catch specific excptions
- Improve error messages, both as logged and returned to the client
- Use varargs when possible
- Treat srmPing differently than other requests

srmPing is special as it cannot return a failure. Therefore the failure
code had a special case to return a regular ping reply even in case of
failure (eg authentication failure). Rather than trying to force srmPing
into the regular handler processing, this patch adds an implementation
of srmPing directly in SRMServerV2 and completely bypasses the usual
request processing. Besides speeding up srmPing processing, this allows
us to remove the workaround in the failure path.

Target: trunk
Require-notes: no
Require-book: no
srm-server: Minor cleanup in Job class

Target: trunk
Require-book: no
Require-notes: no
Interim