cells: Fix login manager login limit interpretation

Addresses an issue in FTP and DCAP doors in which the login limit
was would allow n + 1 logins when n was given as a limit. Also
addresses an issue in which a limit of zero was considered to
be no limit at all. The correct value for disabling the limit is
-1.

Target: trunk
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Christian Bernardt <christian.bernardt@desy.de>
Patch: http://rb.dcache.org/r/5676/
info-provider: Escape percent sign in entity values

Percent signs are the only characters not allowed literally
in entity values, thus these must be escaped when exporting
the dCache configuration to an XML DTD.

The patch addresses the problem that info-provider is broken
by a recent patch adding logback formatting strings as
configuration values.

Target: trunk
Request: 2.6
Require-book: no
Require-notes: yes
Acked-by: Christian Bernardt <christian.bernardt@desy.de>
Patch: http://rb.dcache.org/r/5673/
poolmanager, doors: Don't retry stage requests on the same pool

Addresses a regression introduced between 1.9.12 and 2.2. The regression
means that poolmanager would not remember the previously tried stage pool
and thus could select the same pool twice in a row when retrying failed
stage requests.

The patches addresses this problem. To be effective, both pool manager
and doors have to be updated, although the patch does not break any
version compatibility.

Target: trunk
Request: 2.6
Request: 2.2
Require-notes: yes
Require-book: no
Acked-by: Albert Rossi <arossi@fnal.gov>
Patch: http://rb.dcache.org/r/5678/
srm: Implement SRM_FILE_BUSY response

Addresses the issue, that the SRM is ignorant to other SRM requests
it may have on the same SURL. This leads to the dreaded "Already have 1
record" error in space management, as two concurrent puts on the same
file will be allowed by the SRM, but fail in space manager. More over,
there is currently no way for the user to abort the earlier requests if
they do not have the request number.

The SRM spec says that an upload operation should cause most other
operations on that SURL to fail with SRM_FILE_BUSY. srmRm should cause
existing get and put operations on the SURL to be aborted. This patch
implements those aspects of the SRM spec.

The patch does not implement this logic for srmCopy. This will be done
in a separate patch.

Since the patch addresses a real world issue we (and probably other
sites) suffer from, I request this to be merged into 2.6. Given the
change in observable behaviour, I am reluctant to merge this into 2.2
at this point.

Target: trunk
Request: 2.6
Require-notes: yes
Require-book: no
Acked-by: Dmitry Litvintsev <litvinse@fnal.gov>
Patch: http://rb.dcache.org/r/5677/
dcache-webadmin: avoid rrd4j timestep error statement

module: dcache-webadmin (pool queue plots)

Under certain restart conditions, the rrd4j utility will report that the call to write is doing so with a timestamp which is less than 1 second since the last update.  While this error is not fatal, it is annoying to see in the log.

The extra check simply avoids writing the data under these conditions and waits till the next iteration.

TESTING DONE:

Without the patch, rapid multiple restarts of the webadmin service/httpd domain will probably produce a trace similar to this:

26 Jun 2013 09:32:47 (System) [] problem running collectPoolSeclectionUnit
java.lang.IllegalArgumentException: Bad sample time: 1372257000. Last update time was 1372257000, at least one second step is required
        at org.rrd4j.core.RrdDb.store(RrdDb.java:553) ~[rrd4j-2.1.1.jar:na]
        at org.rrd4j.core.Sample.update(Sample.java:197) ~[rrd4j-2.1.1.jar:na]
        at org.dcache.webadmin.model.dataaccess.util.RrdPoolInfoAgent.storeToRRD(RrdPoolInfoAgent.java:331) ~[classes/:na]
        at org.dcache.webadmin.model.dataaccess.util.RrdPoolInfoAgent.processPools(RrdPoolInfoAgent.java:291) ~[classes/:na]
        at org.dcache.webadmin.model.dataaccess.util.RrdPoolInfoAgent.run(RrdPoolInfoAgent.java:138) ~[classes/:na]
        at java.lang.Thread.run(Thread.java:722) [na:1.7.0]

With the patch, the log remains clean during multiple successive attempts to restart.

Target: master
Patch: http://rb.dcache.org/r/5680
Require-notes: yes
Require-book: no
Request: 2.6
Acked-by: Gerd

RELEASE NOTES:  The cause of the stack trace occasionally seen in the webadmin log file (on restart of the service) has been addressed.