disable distributed garbage collection via RMI

Any java written application which interfaces with Confluence as a client, via the SOAP and/or XML/RPC interface, because they are themselves their own JVM, maintain a list of 'clean' and 'dirty', references to objects which the client knows about, across the wire.

When a remote client of Confluence calls a regular System.gc() as a part of it's usual automated garbage collection routine, it will notify the remote peer (in this case, Confluence), that any objects it was holding, of which Confluence was tracking in it's own reference object graph, are now dirty and those references should be cleaned.

Currently the Hotspot JVM performs this action as a serial, single-threaded System garbage collection. This can lead to rare circumstances whereby a remote client, if poorly written, or resource starved in the JVM, can fatally spam Confluence with full system GC calls until (if) it recovers.

The effect is similar to:

378.030: [GC [PSYoungGen: 13733K->10886K(418816K)] 257769K->254922K(1336320K), 0.0438305 secs] [Times: user=0.05 sys=0.00, real=0.05 secs] 
378.074: [Full GC (System) [PSYoungGen: 10886K->0K(418816K)] [ParOldGen: 244036K->244138K(917504K)] 254922K->244138K(1336320K) [PSPermGen: 66190K->66190K(135168K)], 1.5175107 secs] [Times: user=4.92 sys=0.05, real=1.51 secs] 
379.924: [GC [PSYoungGen: 15258K->712K(435328K)] 259396K->244850K(1352832K), 0.0091928 secs] [Times: user=0.00 sys=0.00, real=0.02 secs] 
379.933: [Full GC (System) [PSYoungGen: 712K->0K(435328K)] [ParOldGen: 244138K->240486K(917504K)] 244850K->240486K(1352832K) [PSPermGen: 66592K->66590K(131072K)], 1.6306610 secs] [Times: user=4.53 sys=0.00, real=1.63 secs] 
382.535: [GC [PSYoungGen: 19106K->11462K(431104K)] 259592K->251948K(1348608K), 0.0230824 secs] [Times: user=0.06 sys=0.00, real=0.03 secs] 
382.558: [Full GC (System) [PSYoungGen: 11462K->0K(431104K)] [ParOldGen: 240486K->240176K(917504K)] 251948K->240176K(1348608K) [PSPermGen: 66648K->66646K(131072K)], 1.3173999 secs] [Times: user=4.14 sys=0.00, real=1.31 secs] 
383.926: [GC [PSYoungGen: 12066K->5636K(446080K)] 252242K->245812K(1363584K), 0.0219822 secs] [Times: user=0.05 sys=0.00, real=0.03 secs] 
383.949: [Full GC (System) [PSYoungGen: 5636K->0K(446080K)] [ParOldGen: 240176K->245655K(917504K)] 245812K->245655K(1363584K) [PSPermGen: 66668K->66668K(131072K)], 1.2802751 secs] [Times: user=4.03 sys=0.00, real=1.27 secs] 
385.301: [GC [PSYoungGen: 7271K->224K(441408K)] 252926K->245879K(1358912K), 0.0217929 secs] [Times: user=0.03 sys=0.00, real=0.03 secs] 

Rendering the installation incapacitated.

From Sun:

Another way applications can interact with garbage collection is by invoking full garbage collections explicitly by calling System.gc(). This can force a major collection to be done when it may not be necessary (i.e., when a minor collection would suffice), and so in general should be avoided. The performance impact of explicit garbage collections can be measured by disabling them using the flag -XX:+DisableExplicitGC, which causes the VM to ignore calls to System.gc().

One of the most commonly encountered uses of explicit garbage collection occurs with RMI's distributed garbage collection (DGC). Applications using RMI refer to objects in other virtual machines. Garbage cannot be collected in these distributed applications without occasionally collection the local heap, so RMI forces full collections periodically.

The frequency of these collections can be controlled with properties. For example,

java -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 ...

specifies explicit collection once per hour instead of the default rate of once per minute. However, this may also cause some objects to take much longer to be reclaimed. These properties can be set as high as Long.MAX_VALUE to make the time between explicit collections effectively infinite, if there is no desire for an upper bound on the timeliness of DGC activity.

Originates from CSP-38789. Explicit remote GC can be completely disabled (ignored) via -XX:+DisableExplicitGC in Tomcat startup parameters, under Sun Hotspot. Recommend we add this to the distribution startup parameters. Ignoring client requests for GC should not have any impact moving forward as Confluence has already been notified that the object is dirty, or dereferenced, and will reclaim it as part of normal collections.