Hi everyone, While using DBeaver to connect to Ignite 2 through JDBC, I encountered the following error when running:
SELECT * FROM SYS.TABLE_COLUMNS; SQL Error [22000]: Serialization error during sending an sql request. The error can be caused by the fact that the classes used on the node are missing on the client. Try to use JDBC connection option 'keepBinary=true' to to avoid deserialization. Also you can use system property IGNITE_SENSITIVE_DATA_LOGGING="plain" to readable print content of a BinaryObject I found that restarting DBeaver with the following JVM option resolved the issue: --add-opens=java.base/java.math=ALL-UNNAMED The current error message does not explain the module access problem or suggest the relevant JVM option. Ideally, we would decouple the JDBC driver from Ignite core and remove the dependencies that require this access. However, that would be a larger change with potential backward compatibility implications. As a more limited improvement, I propose checking the required JVM module access before creating a JDBC connection, after parsing the connection properties and before initializing the binary context or opening network connections. The check would validate actual module access rather than look for specific strings in the JVM arguments. If access is missing, it would report the affected packages and the JVM options needed to open them. We could introduce a JDBC connection property, tentatively named moduleAccessCheck, with three modes: - strict: fail with a clear SQLException listing the missing access permissions and required JVM options. - warn: allow the connection and report the issue through logging and a JDBC SQLWarning. - off: skip the preliminary check. The off mode would let clients that cannot restart their JVM continue using operations that do not require the missing access. It would not fix operations that depend on it. We should also improve the error message when such an operation fails, preserving the underlying cause. Checking during connection creation, rather than driver registration, would allow the behavior to be configured through the JDBC URL or connection properties. What do you think about this approach? Should the default be warn or strict? I lean toward strict: failing fast with an actionable message seems preferable to discovering the problem later through a misleading serialization error.
