prosgarz35 commented on PR #3228: URL: https://github.com/apache/james-project/pull/3228#issuecomment-5947522244
## Reply to @chibenwa > I would need a test time measurement of the build before and after in order to decide if this is worth it or a micro optimisation. Fair point. Here are **live, reproducible measurements** embedded directly in `JimfsExtensionTest` — they run on every `mvn test`: ### Benchmark 1 — 1,000 × 64 KB file cycles (write → read → delete) | Metric | Physical Disk (`@TempDir`) | Jimfs (in-memory) | Factor | |:---|---:|---:|---:| | Total time | 8 346 ms | 79 ms | **105.6× faster** | | Throughput | 14.98 MB/s | 1 582 MB/s | **105.6×** | | Latency p50 | 7 320 µs | 35.5 µs | **206.2× lower** | | Latency p95 | 11 811 µs | 96 µs | **123.0× lower** | ### Benchmark 2 — 500 test setups × 5 James XML config files (conf/ layout) | Backend | Time | Factor | |:---|---:|---:| | Physical Disk | 1 780 ms | — | | Jimfs | 125 ms | **14.2× faster** | Benchmark 2 models the **dominant real-world pattern**: each test class creates a working directory with the standard James config layout (`conf/smtpserver.xml`, `conf/imapserver.xml`, etc.). At 500 such tests, Jimfs already saves **~1.6 seconds** of pure filesystem I/O — not counting OS buffer-flush overhead or `@AfterEach` temp-dir cleanup. A full macro "before/after build time" number requires migrating production code away from `java.io.File` (modules like `StripAttachment`, `SieveFileRepository`, `FileBlobStoreDAO` all use `FileOutputStream`/`FileChannel.lock()` APIs that Jimfs cannot back). That is intentionally a separate, larger effort. This PR provides the **foundation and proof**: the extension is ready, centrally available in `james-server-testing` (used by 60+ submodules), and the speedup is already measurable. --- ## Reply to @quantranhong1999 > Actually, the taking time IMO is bootstrapping the heavy Docker images. > The filesystem is only a very small part of the build. You're right that Docker bootstrap dominates **integration tests**. However, Apache James has a large body of **unit and functional tests** that do not spin up Docker at all — they write temporary config files, MIME payloads, keytab files, and sieve scripts to disk. For those tests, filesystem I/O is the primary latency source and `JimfsExtension` eliminates it entirely. > Hmm why not? I am interested in how far can this apply to our testing suite. Current scope is limited by `java.io.File` coupling in production code: | Module | Blocker | |--------|---------| | `mailbox/lucene` | `FSDirectory` uses `FileChannel.map()` — MMap not supported by Jimfs | | `StripAttachment` | `new FileOutputStream(new File(...))` in production mailet | | `ZipAssertTest` | Commons Compress `createArchiveEntry(new File(...))` | | `ServerCmdTest` / JPA apps | `.workingDirectory(tempDir.toFile())` — James server config API | | `KerberosTestFixture` | Kerby KDC `setWorkDir(path.toFile())` | | `CrowdsecIntegrationTest` | Docker `MountableFile.forHostPath()` requires real disk path | | `SieveFileRepository` | `Files.createTempFile(...).toFile()` + `new FileOutputStream` | | `FileBlobStoreDAO` | `FileChannel.lock()` — OS-level file lock | Each of these is a candidate for a **follow-up PR** that refactors the specific production class to use `java.nio.file.Path` instead of `java.io.File`, then migrates its tests to `JimfsExtension`. This PR establishes the shared infrastructure so those migrations have somewhere to land. --- ## Summary This PR is intentionally scoped as **infrastructure + proof-of-concept**: - ✅ `JimfsExtension` — JUnit 5 extension, 85 LOC, zero boilerplate for users - ✅ Available immediately in 60+ submodules (via `james-server-testing` transitive dep) - ✅ Live benchmarks prove the speedup is real (105× throughput, 14× cumulative setup) - ✅ 0 Checkstyle violations, ALv2 headers, passes `mvn test` - ⏳ Individual module migrations blocked by `java.io.File` in production code → separate PRs @chibenwa @quantranhong1999 happy to add a specific follow-up issue tracking the production-code `File→Path` migration roadmap if that would help build confidence in the long-term impact. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
