OutOfMemory error initializing replication using jdbc postgres backend

[ldap4life]

Describe the bug
When initializing a new database from an existing database using the jdbc postgres backend an OutOfMemory error is encountered during the index initialization phase. Replicating the same database using a je backend succeeds. OpenDJ version 5.0.4

To Reproduce
Steps to reproduce the behavior:

1. Inititialize replication from a large replica (~40 million entries) to a new replica using the jdbc postgres backend. The new replica has a 48GB heap.
2. wait for entries to be copied and index initialization to begin.
3. Logs repeatedly report 0% complete on all indexes until out of memory happens.

Additional context

• Removing all indexes before initializing still results in an out of memory failure. (dn2id index still gets built in this phase and doesnt appear possible to remove.)
• this setup succeeds on a smaller database with the jdbc backend(~20,000 entries.)
• during the index initialization phase large amounts of data can be seen being transferred by postgres

Vote to raise the priority 🖐️

[vharseko]

@ldap4life — thanks for the detailed report. PR #711 (#711) has a fix, and I'd appreciate a verification run against your dataset, since your ~40M-entry replica is the scale that actually triggers the OOM.

To get the artifacts: build the branch features/jdbc-cursor-708 from PR #711 (git fetch the PR head and mvn clean install, or grab the CI build artifacts from the PR's Actions run). Then run your initialize scenario and let me know whether it completes without OutOfMemoryError. Thanks!

[ldap4life]

Thank you for the quick response and apologies i have a lot of competing priorities at this time -- if I find the time I will report back. If theres an updated image, i can probably test quicker with that.

[vharseko]

@ldap4life — no worries. If you want to test without building locally, you can grab a ready-to-run distribution straight from the CI build of PR #711. No Maven, no compilation.

From the browser (easiest):

1. Open the green Build run for the branch: https://github.com/vharseko/OpenDJ/actions/runs/28752217012 (you need to be signed in to GitHub to download artifacts).
2. Scroll to the Artifacts section at the bottom of the run summary.
3. Download ubuntu-latest-11. (Any of the *-latest-* artifacts works — they're just different build platforms/JDKs; the resulting server runs on any supported JRE ≥ 11. Grab ubuntu-latest-11 unless you specifically want macOS/Windows.)
4. GitHub hands you a .zip wrapper. Unzip it, then unzip the actual server distribution inside it:

unzip ubuntu-latest-11.zip -d cifix
# the server distribution is here:
#   cifix/opendj-server-legacy/target/package/opendj-5.1.2-SNAPSHOT.zip
unzip cifix/opendj-server-legacy/target/package/opendj-*.zip -d /opt
# -> /opt/opendj with setup, bin/, etc.
/opt/opendj/setup ...   # your usual setup, then re-run the initialize scenario

(The same artifact also contains .deb / .rpm / .msi packages under opendj-packages/… if you prefer installing one of those instead of the plain .zip.)

Or with the GitHub CLI (auto-extracts, skips the wrapper zip):

gh run download 28752217012 --repo vharseko/OpenDJ -n ubuntu-latest-11
unzip opendj-server-legacy/target/package/opendj-*.zip -d /opt

A note on the image you asked about: CI doesn't publish a public Docker image for a PR branch (it only builds one into a throwaway local registry for the test job), so the artifact above is the fastest ready-to-run path. If you'd rather have a container, you can build one from that distribution .zip.

One caveat: build artifacts are kept for 5 days, so this particular run expires around 2026-07-10. If the link has gone stale by the time you get to it, just ping me here and I'll kick off a fresh build. Thanks for taking a look when you can!