In Gatling 3.15, what happened to the `eager` and `batch` feeder loading modes, and what now decides how a file-backed feeder is loaded?

## What was removed Up to Gatling 3.14 a file-based feeder builder carried two extra methods that forced how the file was read: `eager`, which parsed the whole file into memory up front, and `batch`, optionally with a buffer size, which streamed it in chunks instead. **Gatling 3.15 dropped both.** The upgrade note is explicit about the reasoning: the automatic behaviour had given ample satisfaction, so it was made the only behaviour and the SDK surface was simplified. There is no deprecation shim. On 3.15 the methods do not exist, so a simulation that calls `csv("users.csv").batch(500)` no longer compiles — which is the good outcome, because a silently ignored call would have left a false impression about how the file is being read. ## What decides the loading mode now For the **line-based** file sources — `csv`, `ssv`, `tsv`, `separatedValues` and `jsonlFile`, the ones that read a file line by line — Gatling looks at the **file's size** and compares it against `gatling.core.feederAdaptiveLoadModeThreshold`, a value in megabytes that defaults to **100**: - **at or below the threshold**, the file is parsed once and held as records in memory; - **above it**, the file is streamed from disk in blocks as records are consumed. The choice is made per feeder, when the feeder is built at start-up, and it is the only lever left — a configuration key rather than a call in the simulation. The threshold does not reach every file-backed feeder, though. `jsonFile` and `sitemap` are file-based feeder builders in the same sense — same four strategies, same `unzip` option — but each parses its whole document up front and serves the records from memory, never reading the threshold. A 500 MB JSON feeder file is still loaded whole, so the windowing effect described next cannot arise for it. ## Why this belongs in a discussion about consumption order The loading mode is not purely a memory concern, because it changes what two of the four strategies mean: | strategy | loaded in memory | streamed from disk | |---|---|---| | `queue` | file order, once each | file order, once each — identical | | `circular` | file order, wrapping | file order, wrapping — identical | | `shuffle` | one permutation of the **whole file** | the file is shuffled **within a rolling block** | | `random` | an independent draw over the **whole file**, with replacement | a shuffled pass over a rolling 2,000-record block, without replacement | `queue` and `circular` are unaffected: both are sequential walks, and a walk over a stream is the same walk. But `shuffle` and `random` are defined by drawing from a population, and above the threshold the population they can see at any moment is the block currently buffered, not the file. A "random" row from a very large file is therefore random within the current window: record one million cannot appear before the stream has read that far. Streamed `random` also stops being a *draw*. Gatling fills a 2,000-record buffer from the stream, shuffles it, and hands the records out **in order** until it is spent, then refills — restarting the file when the stream runs dry. Inside one block a record cannot come up twice; the in-memory form promises no such thing, since every call there is an independent pick over the whole record vector. Crossing the threshold does not merely narrow what `random` can see: it turns sampling with replacement into a block-local shuffle. For most suites this never matters, because feeder files are far below 100 MB and are loaded whole. It matters when someone points a `random` feeder at a multi-gigabyte extract and expects a uniform draw across all of it. ## The trap The word `batch` still turns up in Gatling's own material and codebase, and none of those occurrences mean the removed feeder mode: - the published **cheat sheet** still lists `batch` under "Feeder options", with its buffer-size signature. That page is a draft, it predates 3.15, and it is wrong for current Gatling; - the identifier exists elsewhere in the codebase for unrelated components. So finding the word is not evidence the feature is back. Anchor the check on the call form — `someFeeder.batch(...)` on a feeder builder — and on the version, not on the bare word. ## Why the removal was the right call Forcing the mode was a foot-gun in both directions. Forcing eager loading on a very large file bought an out-of-memory failure at start-up; forcing streaming on a small one bought disk reads for no benefit. Neither choice could be made well without knowing the file's size, which is exactly what the runtime knows and the author often does not. Making it automatic also removes a class of stale simulation: a file that grows over months used to keep whatever mode was hard-coded when it was small. Now the decision is re-taken every run, against the file as it actually is. ## What to check when you upgrade - **Grep the suite for the two method names.** They fail at compile time, so the build finds them for you, but knowing what they were tells you what the author was worried about. - **Check whether any feeder file is near the threshold**, and if one is, ask whether it uses `shuffle` or `random` — those are the two whose meaning changes as a file crosses it. - **Distrust secondary sources on this.** The removal is stated in the upgrade notes for 3.15; reference pages and blog posts written before it still show the old calls as current.