- Graphwise Platform Documentation
- Graphwise Platform Overview
- How to Install & Manage Graphwise Components
- Installation & Migration
- PoolParty 10 Migration Guide
- PoolParty 10 Migration Troubleshooting Guide
PoolParty 10 Migration Troubleshooting Guide
04/09/2026
This guide summarizes the most common troubleshooting topics related to migrating from Graph Modeling (formerly PoolParty) 9 to 10.
During the migration process, especially when handling large instances with numerous or high-volume repositories, you may encounter a failure due to GraphDB exhausting its allocated memory. This typically results in the process being terminated by the system.
If the migration fails, check the logs for the following exception:
org.eclipse.rdf4j.repository.RepositoryException: org.apache.http.conn.HttpHostConnectException: Connect to graphdb:7200 [graphdb/10.61.32.3] failed: Connection refused
This error is generally triggered when the GraphDB process is killed by the operating system (OOM Killer) because it exceeded memory limits while attempting to initialize or migrate multiple repositories simultaneously.
To resolve this, you must temporarily restrict the number of active repositories and shorten their memory residency. Follow these steps to adjust your configuration:
Navigate to your GraphDB installation directory and open the
graphdb.propertiesfileAdd or update the following properties to minimize the memory footprint during migration:
graphdb.repository.expiry.after.minutes = 1graphdb.max.active.repositories = 2
Tip
While the values provided above are optimal for resolving most memory-related migration failures, you may tweak them further if your specific hardware constraints require even stricter limits.
Save the
graphdb.propertiesfile and restart your GraphDB instance
Once the migration has successfully completed, revert these properties to their original values (or remove them if they were not previously present) and restart GraphDB once more to restore standard performance levels.
This section addresses errors encountered during the migration process related to improper repository state transitions, specifically within the GraphDB storage layer.
During the migration of RDF4J or embedded GraphDB repositories, the application may fail with a RepositoryException. This typically indicates that a previous transaction was not closed correctly, leaving a "stale" precommit file in the storage directory.
[ERROR] b.p.m.PoolParty10MigrationApplication] MIGRATION REPOSITORIES (RDF4J AND EMBEDDED GRAPHDB) FAILED org.eclipse.rdf4j.repository.RepositoryException: java.lang.IllegalStateException: Bad transition from INITIAL to PRECOMMIT
Check the stack trace for a log line indicating which specific repository ID failed to open:
FAILED: embedded GraphDB repository '<REPOSITORY_ID>' -> 'pp_project_<REPOSITORY_ID>' (failed to open)
Root Cause
The Bad transition from INITIAL to PRECOMMIT error is usually caused by an uncommitted or improperly terminated transaction that left a temporary index file on the disk. This prevents the database engine from successfully initializing the repository during the migration task.
Resolution (Manual Workaround)
If you are using a version of GraphDB prior to 11.4, follow these steps to manually clear the blocked state:
Stop the Graph Modeling (formerly PoolParty) and GraphDB services.
Perform a full backup of the database directory before modifying any files.
Navigate to the specific repository storage folder and delete the stale precommit index file:
data/graphdb/repositories/<REPOSITORY_ID>/storage/predLists.index.precommitNote
Replace
<REPOSITORY_ID>with the ID identified in the error logs.Restart the GraphDB and Graph Modeling services. The migration tool should now be able to access the repository.
Important
Starting with GraphDB 11.4, the internal StorageTool has been updated to detect and automatically resolve these state inconsistencies during startup. If you encounter this issue frequently, consider upgrading your GraphDB instance to leverage this automated recovery feature.
This troubleshooting section covers the scenario where the migration tool identifies redundant or conflicting repository definitions, which halts the migration to prevent data inconsistency.
The migration tool performs a pre-check to ensure each project maps to a unique repository. If the tool detects that a repository with the same identifier already exists in the target environment or is defined twice in the source, the process will fail:
[ERROR] b.p.m.PoolParty10MigrationApplication] MIGRATION REPOSITORIES (RDF4J AND EMBEDDED GRAPHDB) FAILED java.lang.RuntimeException: Repository pp_project_<REPOSITORY_ID> already exists
Root Cause
This conflict typically arises from old configurations in PoolParty 9.x, specifically:
Both the RDF4J Server and Embedded GraphDB were being used simultaneously for the same project.
A project was moved from one repository type to another (e.g., from RDF4J to Embedded GraphDB), but the original repository was not fully decommissioned or deleted, leaving a "ghost" entry.
Resolution
To resolve this conflict, the repositories must be consolidated before the migration tool is executed again.
As of migration tool version 1.1.0, the tool automatically generates a report. Check the standard output (
stdout) or the generated analysis file in the application directory to see exactly which repository IDs are duplicated.Manually review the storage locations (RDF4J Server vs. Embedded GraphDB) and move or delete the conflicting/obsolete repository so that each project ID is associated with only one data source.
Once the duplicates are removed and only one instance of the repository remains, re-run the migration script.