When Your Demo Derby Database Blocks a Striim Restart

TL;DR

• Applying a license key to a Derby-backed demo/eval Striim install can leave the environment unable to restart.
• The failure shows up in striim.server.log as a DerbySQLIntegrityConstraintViolationException — a duplicate key on WACTIONOBJECT.
• The fix: stop Striim, remove the two “sks” (security keystore) files under conf/, re-run sksConfig.sh, then restart.
• This gets a demo environment back online — it isn’t a substitute for moving your metadata repository off Derby before you go to production.

You Apply a License Key, and Striim Won’t Come Back Up

If you’ve been evaluating Striim in a demo environment, there’s a good chance it’s running on the bundled Derby database for its metadata repository (MDR). That’s exactly why Derby is the default — no setup required, up and running in minutes. It works fine right up until the day you buy the license.

You stop Striim:

sudo systemctl stop striim-node
sudo systemctl stop striim-dbms

(Running Striim as a foreground process instead of a service? Ctrl-C does the same job.)

You drop the real ProductKey and LicenseKey into startUp.properties, and you try to bring the environment back up. And it doesn’t come back up.

A Duplicate Key on WACTIONOBJECT

striim.server.log tells you where to look:

Internal Exception: org.apache.derby.shared.common.error.DerbySQLIntegrityConstraintViolationException:
The statement was aborted because it would have caused a duplicate key value in a unique or primary
key constraint or unique index identified by 'URI_UK' defined on 'WACTIONOBJECT'.

followed by an EclipseLink persistence exception and a MetadataRepository connection failure. Read literally: Derby is refusing an insert into WACTIONOBJECT — the table backing Striim’s notification/WAction store — because a row with that URI already exists, and URI_UK is a unique constraint.

Flagging this honestly rather than smoothing it over: the source material behind this post documents the fix that worked, not a confirmed engineering root-cause writeup. The most plausible read is that the restart re-runs metadata initialization against an MDR that’s already partially populated — possibly because the security keystore and the Derby metadata state fell out of sync during the license-driven restart — and the initializer collides with objects that are already there. That’s an inference, not a confirmed mechanism. Get engineering sign-off on the actual causal chain before citing this externally.

Clear the Keystore, Reinitialize, Restart

The fix that resolved this doesn’t touch the Derby files directly — it clears and rebuilds the security keystore, then lets Striim reinitialize around it:

cd $STRIIM_HOME/conf
rm -f ./sks.p12
rm -f ./sksKey.pwd

cd ../bin
./sksConfig.sh

cd ../bin
./server.sh

sks.p12 and sksKey.pwd are Striim’s local security keystore and its password file. Removing them and re-running sksConfig.shforces Striim to regenerate both from a clean slate before it tries to bring the metadata repository back online — which is what gets the restart past the duplicate-key error. Running Striim as a service rather than a foreground process? Restart with the matching service commands (sudo systemctl start striim-dbms, then sudo systemctl start striim-node) instead of ./server.sh.

Know What You’re Trading Away

This is a recovery procedure for a demo or eval environment — not a general-purpose move to reach for on anything you’d call production. Regenerating the security keystore and clearing metadata initialization state is the kind of step you take on a Derby-backed environment you can afford to rebuild, not on a deployment holding application definitions and checkpoint state you actually depend on. If this exact error shows up on something closer to production, stop and loop in your Striim technical contact before running these commands — don’t assume the demo-environment fix generalizes.

What This Failure Is Really Telling You

If you’ve hit this specific error, it’s also a decent signal that it’s time to stop treating Derby as a long-term home for your metadata repository. Derby is genuinely fine for a first install and a demo. It isn’t designed to be the thing your license state, your checkpoints, and your recovery bookkeeping depend on once you’re running for real. Moving the MDR to a database you already operate — Striim supports Oracle and PostgreSQL — means backups, monitoring, and access control stop being a special case for one file-based database nobody’s watching. See the walkthrough for moving the MDR to PostgreSQL for the concrete steps.

Bottom Line

A duplicate-key error on WACTIONOBJECT after a license-driven restart is fixable in about four commands: clear the sksfiles, re-run sksConfig.sh, restart. Treat it as a prompt to plan your move off Derby before this environment becomes something you can’t afford to rebuild.

Questions on this one? Reach out to your Striim technical contact, or check the Striim documentation for metadata repository configuration options.

Please follow and like: