[
https://issues.apache.org/jira/browse/DERBY-4329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rick Hillegas updated DERBY-4329:
---------------------------------
Attachment: derby-4329-01-aa-dontSwallowExceptions.diff
I have pushed this forward a small distance. It seems to me that there are two
issues involved here:
1) Cleanup logic in BaseMonitor swallows the initial triggering exception if an
error occurs while performing cleanup. I have attached a patch which addresses
this particular swallowing: derby-4329-01-aa-dontSwallowExceptions I suspect
that this pattern of exception swallowing occurs elsewhere in this class. The
patch is incremental improvement but, as a follow-on effort, it would be
worthwhile to fix other instances of this exception swallowing.
2) I believe that the attached patch will fix this bug. However, checking in
this patch will mask a second issue. Before checking in this patch, it would be
good to understand that second issue: StorageFactoryService, during cleanup
initiated by BaseMonitor, asserts that an in-memory service does not have the
expected name. I don't know why the expected service name is not the service
name returned by VFMemoryStorageFactory.getCanonicalName(). The expected
service name starts with the memory subsubprotocol keyword but that keyword is
missing on the name returned by VFMemoryStorageFactory.getCanonicalName().
Perhaps the in-memory experts can shed some light on this.
> If you try to create an in-memory database with an illegal encryption key
> size, you get an ASSERT failure rather than a diagnostic telling you that the
> key size is unsupported.
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-4329
> URL: https://issues.apache.org/jira/browse/DERBY-4329
> Project: Derby
> Issue Type: Bug
> Components: Store
> Reporter: Rick Hillegas
> Attachments: derby-4329-01-aa-dontSwallowExceptions.diff
>
>
> The following script shows this problem for me when I use a Java 5 VM on Mac
> OS X. The first connection (to an in-memory database) raises an assertion. In
> contrast, the second connection (to an on-disk database) gives useful
> diagnostics:
> ij version 10.6
> ij> connect
> 'jdbc:derby:memory:encdbcbc_256;create=true;dataEncryption=true;encryptionKeyLength=256;encryptionAlgorithm=AES/CBC/NoPadding;bootPassword=Thursday';
> ERROR XJ001: Java exception: 'ASSERT FAILED serviceName =
> memory:/Users/rh161140/derby/dummy/encdbcbc_256;storageFactory.getCanonicalName()
> = /Users/rh161140/derby/dummy/encdbcbc_256:
> org.apache.derby.shared.common.sanity.AssertFailure'.
> ij> connect
> 'jdbc:derby:encdbcbc_256_disk;create=true;dataEncryption=true;encryptionKeyLength=256;encryptionAlgorithm=AES/CBC/NoPadding;bootPassword=Thursday';
> ERROR XJ041: Failed to create database 'encdbcbc_256_disk', see the next
> exception for details.
> ERROR XBM01: Startup failed due to an exception. See next exception for
> details.
> ERROR XBCX0: Exception from Cryptography provider. See next exception for
> details.
> ERROR XJ001: Java exception: 'Illegal key size:
> java.security.InvalidKeyException'.
> ij
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
