Skip to main content
Sign in

JDBC connector using Databricks driver fails in Fusion 5.9.12 due to missing Java runtime flag

  • Updated

Issue

JDBC connector jobs intermittently fail to start after upgrading to Fusion 5.9.12. The logs may show:

java.lang.RuntimeException: Failed to initialize MemoryUtil. Was Java started with --add-opens=java.base/java.nio=ALL-UNNAMED?

Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field long java.nio.Buffer.address accessible: module java.base does not "opens java.nio" to unnamed module @663a8de6

                at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:354)

                at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)

                at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:178)

                at java.base/java.lang.reflect.Field.setAccessible(Field.java:172)

                at com.databricks.client.jdbc42.internal.apache.arrow.memory.util.MemoryUtil.<clinit>(MemoryUtil.java:88)

In some cases, jobs that previously succeeded start failing on subsequent runs with errors such as:

com.lucidworks.fusion.job.controller.backends.JobBackendException: Problem while starting job. Error while starting job '<job-name>'
The state should never be null

These failures often occur after restarting the connectors-backend pod or performing a Helm upgrade.

 

Diagnosis

This issue is likely to occur if the Fusion deployment is:

  • Using Fusion 5.9.12 or a similar version

  • Deployed with Java 17 as the runtime environment

  • Running the JDBC connector plugin (especially with Apache Arrow-based drivers such as Databricks)

  • Missing the --add-opens JVM argument in the connector’s configuration

To confirm, check the logs of the connectors-backend pod after a failed JDBC job for the Caused by: java.lang.reflect.InaccessibleObjectException message.

 

Environment

Fusion 5.9.12
Kubernetes 1.29 (Amazon EKS)
Self-hosted deployment
JDBC V2 connector (packaged with Fusion 5.9.12)
Java 17 runtime environment

 

Cause

Java 17 enforces stricter module access rules. Apache Arrow (used in some JDBC drivers) requires reflective access to internal Java APIs such as java.nio.Buffer.address. Without the appropriate --add-opens JVM argument, these libraries fail to initialize.

The default connectors-backend microservice in Fusion 5.9.12 does not include this argument, resulting in job failures during startup.

 

Resolution

Add the following JVM option to the connectors-backend microservice configuration in your Helm values file to persist the change across pod restarts:

 

Update Helm values.yaml

Locate the connectors-backend section and include the javaOpts parameter:

connectors-backend:
  javaOpts: "--add-opens=java.base/java.nio=ALL-UNNAMED"

 

Apply the configuration

Run the following Helm upgrade to apply the updated values file:

helm upgrade <release-name> lucidworks/fusion \
  -n <namespace> \
  -f values.yaml

Replace <release-name> with your Helm release name and <namespace> with your Fusion namespace.

 

Confirm the change

After applying the update:

  • Restart the connectors-backend pod

  • Check the pod spec or logs to verify the --add-opens argument is now included

  • Run a JDBC crawl job to confirm the issue no longer occurs

 

Notes

  • This change ensures the JVM flag is preserved across restarts and upgrades.

  • If deploying connectors via the Fusion UI, ensure backend-specific settings are updated in Helm-managed configurations.

If errors persist, check for additional misconfigurations or conflicting environment variables in the connectors-backend definition.

 

 

 

 

 

Related articles

Powered by Zendesk