Hello, I would like to share a reproducible engineering study involving Apache Commons JCS:
Beyond Throughput: A Reproducible Benchmark of Java Caches in a Tomcat Lifecycle The study compares Caffeine, Ehcache, cache2k, and a pinned Apache Commons JCS 4 snapshot while running the same application-level workload inside Apache Tomcat. JCS 3.2.1 and a no-store implementation are also included in the lifecycle analysis. The goal is not to establish a universal ranking. Throughput, latency, semantic correctness, and behavior across undeploy and redeploy are measured and reported as separate results. The canonical campaign used: - 36 independent JVM processes; - 180 complete Tomcat lifecycle cycles; - 360 timed workload windows; - a balanced Williams design for execution order; - deterministic and paired operation plans; - automated semantic and provenance validation. All 360 timed windows passed the semantic correctness checks. In the configured application path, the median throughput results were: - cache2k: 30.777 / 30.589 Mops/s; - Caffeine: 27.218 / 26.581 Mops/s; - Ehcache: 24.813 / 24.626 Mops/s; - JCS 4 snapshot: 0.965 / 0.969 Mops/s. The values are shown as initial deploy / redeploy. These measurements include the provider, application adapter, counters, cache configuration, and workload implementation. Therefore, the paper identifies a difference in the complete application path but does not attribute it exclusively to the JCS core. The JCS lifecycle investigation is presented separately from the performance comparison. While analysing JCS 3.2.1, I identified the worker-thread retention pattern reported as JCS-248. The upstream resolution adopted by the maintainer was broader than the initial proposed change. Under the frozen protocol: - JCS 3.2.1 reproduced the defined retention pattern in 6/6 JVM processes and 60/60 corroborated lifecycle intervals; - the pinned JCS 4 revision reproduced it in 0/6 JVM processes and 0/60 intervals. The tested JCS 4 revision is: fb3f101b87709b713468e8d827b8612e6e65f29b This result shows that the specific worker-thread retention pattern observed with JCS 3.2.1 is no longer reproduced in the tested JCS 4 revision. It is not intended to prove the absence of every possible memory or resource leak. The complete material is available here: Repository: https://github.com/tbuffagni/brainy-java-cache-lab English paper: https://github.com/tbuffagni/brainy-java-cache-lab/releases/download/v1.0.0/beyond-throughput-tomcat-lifecycle-en.pdf Release and evidence archive: https://github.com/tbuffagni/brainy-java-cache-lab/releases/tag/v1.0.0 The repository contains the protocol, benchmark implementation, tests, result tables, workbook, figures, validation tools, and a Git submodule pinned to the JCS 4 revision used by the study. I would particularly appreciate feedback from the JCS maintainers and contributors on: 1. whether the JCS configuration is representative and fair; 2. whether any relevant JCS-specific operating mode should be added; 3. whether the lifecycle classification accurately represents the JCS 3.2.1 and JCS 4 behavior; 4. which measurements would best help separate adapter overhead from costs inside the JCS engine; 5. any corrections that should be made before extending the experiment. Critical reviews and independent reproductions are welcome. If errors or ambiguities are identified, I will record and correct them transparently. Best regards, Thomas Buffagni https://www.linkedin.com/in/thomasbuffagni/
