Re: Database shutdown not releasing file handles
On 04.04.12 05:23, Trejkaz wrote: We have the occasional user reporting that after shutting down the database, they can see file handles still open. We're using ;shutdown=true (or at least the DataSource equivalent of it) to do this, and we were led to believe that this would be sufficient to release all file handles. Hi, Yes, it should, but can you please clarify if you're talking about database shutdown or Derby system shutdown? Also, do you know to what kinds of files Derby keeps open handles? Is it possible that shutdown doesn't actually shut the database down? Which version of Derby are you running with? Regards, -- Kristian TX
Re: Database shutdown not releasing file handles
On Wed, Apr 4, 2012 at 4:46 PM, Kristian Waagan kristian.waa...@oracle.com wrote: On 04.04.12 05:23, Trejkaz wrote: We have the occasional user reporting that after shutting down the database, they can see file handles still open. We're using ;shutdown=true (or at least the DataSource equivalent of it) to do this, and we were led to believe that this would be sufficient to release all file handles. Hi, Yes, it should, but can you please clarify if you're talking about database shutdown or Derby system shutdown? Just individual database shutdown. Also, do you know to what kinds of files Derby keeps open handles? The files which are held are: seg0\c951.dat seg0\c861.dat seg0\c211.dat seg0\c71.dat seg0\c130.dat seg0\c731.dat seg0\cf0.dat These do seem to be closed at some point *after* shutdown returns, leading us to believe that shutdown doesn't necessarily shut down now, but rather some time in the future. The timing is like this: 11:09:02.0444360 AM - close call presumably finishes around here 11:10:00.8759376 AM - we attempt to rename the directory 11:10:00.8760454 AM - first close call after our rename attempt 11:10:12.4420715 AM - last close call after our rename attempt Is it possible that shutdown doesn't actually shut the database down? Which version of Derby are you running with? v10.8.2.2. Another probably-critical piece of information I missed was that the OS is Windows. (If it had been Linux, we probably wouldn't ever notice this sort of thing since we discovered the issue when trying to move a file which was held open.) Daniel
Re: Database shutdown not releasing file handles
On 04.04.12 09:27, Trejkaz wrote: On Wed, Apr 4, 2012 at 4:46 PM, Kristian Waagan kristian.waa...@oracle.com wrote: On 04.04.12 05:23, Trejkaz wrote: We have the occasional user reporting that after shutting down the database, they can see file handles still open. We're using ;shutdown=true (or at least the DataSource equivalent of it) to do this, and we were led to believe that this would be sufficient to release all file handles. Hi, Yes, it should, but can you please clarify if you're talking about database shutdown or Derby system shutdown? Just individual database shutdown. Also, do you know to what kinds of files Derby keeps open handles? The files which are held are: seg0\c951.dat seg0\c861.dat seg0\c211.dat seg0\c71.dat seg0\c130.dat seg0\c731.dat seg0\cf0.dat These do seem to be closed at some point *after* shutdown returns, leading us to believe that shutdown doesn't necessarily shut down now, but rather some time in the future. Yes, if the handles are closed shortly after shutdown has returned this is unfortunately the currently expected behavior. Not sure if we have a JIRA for that, at least it has been discussed at some point. Hopefully some time in the future is only a few seconds away. The timing is like this: 11:09:02.0444360 AM - close call presumably finishes around here 11:10:00.8759376 AM - we attempt to rename the directory 11:10:00.8760454 AM - first close call after our rename attempt 11:10:12.4420715 AM - last close call after our rename attempt Is it possible that shutdown doesn't actually shut the database down? Which version of Derby are you running with? v10.8.2.2. Another probably-critical piece of information I missed was that the OS is Windows. (If it had been Linux, we probably wouldn't ever notice this sort of thing since we discovered the issue when trying to move a file which was held open.) Yes, that's typical, and the community sometimes observes the same thing when such a bug is introduced by someone developing on a non-Windows machine and then the nightlies fail on the Windows platform after the commit. -- Kristian Daniel
Re: Random DRDA Error on IBM J9 JVM
Brandon, just an idea, are you sure you use 10.8.2.2 jars also on client accessing this Derby network server? Once I switched everything to 10.8.2.2 I stopped seeing the errors on IBM J9. On Wed, Apr 4, 2012 at 8:57 PM, Brandon L. Duncan brandonl.dun...@gmail.com wrote: Hi all, I am seeing intermittent failures on 10.8.2.2 running on J9. I switched to lib-debug to add line numbers in the stack. Per your recommendation Myrna, I'm putting together a test scenario that I can attach to a possible JIRA. However, I was wondering in the mean time if the 10.8.2.2 stack with line numbers indicated a possible area to isolate on in my attempt to recreate? Thanks Wed Apr 04 14:46:14 EDT 2012 : Apache Derby Network Server - 10.8.2.2 - (1181258) started and ready to accept connections on port 1555 Wed Apr 04 14:46:21 EDT 2012 : Connection number: 1. Wed Apr 04 14:46:21 EDT 2012: Shutting down instance a816c00e-0136-7ead-b0af-cab24f1a on database directory /database with class loader sun.misc.Launcher$AppClassLoader@376a376a Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248) at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1447) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1397) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3248) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1177) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:982) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Cleanup action completed Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248) at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1447) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1397) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3248) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1177) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:982) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Cleanup action completed Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] (DATABASE =
Re: Embedded derby fails to start
Yes, we opened a JIRA defect with derby. https://issues.apache.org/jira/browse/DERBY-5676 This is running in embedded mode on IBM z/OS Mainframe. We checked quite a few things including whether the disk was full, write permissions, dual booting etc. At this point I think it could be either IBM 's jvm or AES encryption we use on db creation. We will try to recreate db with no encryption and see. If there are other ideas out there, please share. Thx. Bryan Pendleton-3 wrote: On 03/22/2012 01:38 PM, cruise27 wrote: Source) Caused by: java.lang.NullPointerException at org.apache.derby.impl.store.raw.log.Scan.getNextRecordForward Ouch! That's not ever supposed to happen. Do you still have the log file? It would be worth filing a Jira issue and attaching the log, so the developers can have a look at it. Did your log file disk fill up, perhaps? Did you have a system crash or power failure while Derby was running? Has your system reported any disk I/O errors on the disk drives? The Derby logging system is supposed to be pretty well hardened against these sorts of errors, but if you can gather any information about what might have occurred just before this problem started, that might help the developers. thanks, bryan -- View this message in context: http://old.nabble.com/Embedded-derby-fails-to-start-tp33544635p33563259.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: Random DRDA Error on IBM J9 JVM
Peter, definitely using the 10.8.2.2 jars. The scenario, which I'm in the process of parsing down to share on JIRA is a single shell script called from qsh to start the network server, run ij, and finally shutdown the network server. The same classpath is shared through all three java calls. On Wed, Apr 4, 2012 at 3:25 PM, Peter Ondruška peter.ondruska+de...@kaibo.eu wrote: Brandon, just an idea, are you sure you use 10.8.2.2 jars also on client accessing this Derby network server? Once I switched everything to 10.8.2.2 I stopped seeing the errors on IBM J9. On Wed, Apr 4, 2012 at 8:57 PM, Brandon L. Duncan brandonl.dun...@gmail.com wrote: Hi all, I am seeing intermittent failures on 10.8.2.2 running on J9. I switched to lib-debug to add line numbers in the stack. Per your recommendation Myrna, I'm putting together a test scenario that I can attach to a possible JIRA. However, I was wondering in the mean time if the 10.8.2.2 stack with line numbers indicated a possible area to isolate on in my attempt to recreate? Thanks Wed Apr 04 14:46:14 EDT 2012 : Apache Derby Network Server - 10.8.2.2 - (1181258) started and ready to accept connections on port 1555 Wed Apr 04 14:46:21 EDT 2012 : Connection number: 1. Wed Apr 04 14:46:21 EDT 2012: Shutting down instance a816c00e-0136-7ead-b0af-cab24f1a on database directory /database with class loader sun.misc.Launcher$AppClassLoader@376a376a Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248) at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1447) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1397) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3248) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1177) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:982) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Cleanup action completed Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248) at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1447) at
Constraint already exists in Schema 'APP'
I have three tables Person, Patient, and Employee. Both Patient and Employee have a Foreign Key to Person; however, when creating the constraint for the second time I get the following error: Constraint 'PERSON_FK' already exists in Schema 'APP'. [code] CREATE TABLE PERSON ( PERSON_ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1) ); CREATE TABLE PATIENT ( PATIENT_ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), PERSON_ID INTEGER NOT NULL ); ALTER TABLE PATIENT ADD CONSTRAINT PERSON_FK Foreign Key ( PERSON_ID) REFERENCES PERSON ( PERSON_ID); CREATE TABLE EMPLOYEE ( EMPLOYEE_ID INTEGER NOT NULL GENERATED ALWAYS AS IDENTITY (START WITH 1, INCREMENT BY 1), PERSON_ID INTEGER NOT NULL ); ALTER TABLE EMPLOYEE ADD CONSTRAINT PERSON_FK Foreign Key ( PERSON_ID) REFERENCES PERSON ( PERSON_ID); [/code] What do you do in this situation? Do you only create on constraint and then reference it when using it again? If so, how? Thanks, John Steele -- View this message in context: http://old.nabble.com/Constraint-already-exists-in-Schema-%27APP%27-tp33564657p33564657.html Sent from the Apache Derby Users mailing list archive at Nabble.com.
Re: Random DRDA Error on IBM J9 JVM
On Wed, Apr 4, 2012 at 12:43 PM, Brandon L. Duncan brandonl.dun...@gmail.com wrote: Peter, definitely using the 10.8.2.2 jars. The scenario, which I'm in the process of parsing down to share on JIRA is a single shell script called from qsh to start the network server, run ij, and finally shutdown the network server. The same classpath is shared through all three java calls. On Wed, Apr 4, 2012 at 3:25 PM, Peter Ondruška peter.ondruska+de...@kaibo.eu wrote: Brandon, just an idea, are you sure you use 10.8.2.2 jars also on client accessing this Derby network server? Once I switched everything to 10.8.2.2 I stopped seeing the errors on IBM J9. On Wed, Apr 4, 2012 at 8:57 PM, Brandon L. Duncan brandonl.dun...@gmail.com wrote: Hi all, I am seeing intermittent failures on 10.8.2.2 running on J9. I switched to lib-debug to add line numbers in the stack. Per your recommendation Myrna, I'm putting together a test scenario that I can attach to a possible JIRA. However, I was wondering in the mean time if the 10.8.2.2 stack with line numbers indicated a possible area to isolate on in my attempt to recreate? Thanks Wed Apr 04 14:46:14 EDT 2012 : Apache Derby Network Server - 10.8.2.2 - (1181258) started and ready to accept connections on port 1555 Wed Apr 04 14:46:21 EDT 2012 : Connection number: 1. Wed Apr 04 14:46:21 EDT 2012: Shutting down instance a816c00e-0136-7ead-b0af-cab24f1a on database directory /database with class loader sun.misc.Launcher$AppClassLoader@376a376a Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248) at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257) at org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1447) at org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1397) at org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3248) at org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1177) at org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:982) at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295) Cleanup action completed Wed Apr 04 14:46:21 EDT 2012 Thread[DRDAConnThread_11,10,main] Cleanup action starting java.lang.NullPointerException at org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541) at org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443) at org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394) at org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845) at org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682) at org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560) at org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979) at org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550) at org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697) at org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385) at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70) at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248) at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126) at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257) at
NPE in Store on boot (was Re: Random DRDA Error on IBM J9 JVM)
On 4/4/2012 12:43 PM, Brandon L. Duncan wrote:
Peter, definitely using the 10.8.2.2 jars. The scenario, which I'm in
the process of parsing down to share on JIRA is a single shell script
called from qsh to start the network server, run ij, and finally
shutdown the network server. The same classpath is shared through all
three java calls.
Looking at the stack trace. I think we are losing the initial boot
exception that leads to the shutdown because of the NullPointerException.
As a quick hack to see what the exception is you can put a
t.printStackTrace() about line 1829 of BaseMonitor.
} catch (Throwable t) {
.
if (ts != null) {
ts.shutdown(); It is in here that the NPE occurs.
synchronized (this) {
services.remove(ts);
}
I'd check the database and make sure it is consistent [1] and also if
you have a reproduction that you cannot share, perform JIT diagnostics.
First disable JIT with -Xint and see if it still reproduces. Hopefully
your reproduction starts with a new database each time.
I think you should go ahead and file the Jira and include the derby.log,
the jvm information and as much information as you can and add the
reproduction once you get it to a state where you can attach.
Thanks
Kathey
[1] http://wiki.apache.org/db-derby/DatabaseConsistencyCheck
action starting
java.lang.NullPointerException
at
org.apache.derby.impl.store.raw.data.BaseDataFileFactory.stop(BaseDataFileFactory.java:541)
at
org.apache.derby.impl.services.monitor.TopService.stop(TopService.java:443)
at
org.apache.derby.impl.services.monitor.TopService.shutdown(TopService.java:394)
at
org.apache.derby.impl.services.monitor.BaseMonitor.bootService(BaseMonitor.java:1845)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startProviderService(BaseMonitor.java:1682)
at
org.apache.derby.impl.services.monitor.BaseMonitor.findProviderAndStartService(BaseMonitor.java:1560)
at
org.apache.derby.impl.services.monitor.BaseMonitor.startPersistentService(BaseMonitor.java:979)
at
org.apache.derby.iapi.services.monitor.Monitor.startPersistentService(Monitor.java:550)
at
org.apache.derby.impl.jdbc.EmbedConnection.bootDatabase(EmbedConnection.java:2697)
at
org.apache.derby.impl.jdbc.EmbedConnection.init(EmbedConnection.java:385)
at org.apache.derby.jdbc.Driver40.getNewEmbedConnection(Driver40.java:70)
at org.apache.derby.jdbc.InternalDriver.connect(InternalDriver.java:248)
at org.apache.derby.jdbc.EmbeddedDriver.connect(EmbeddedDriver.java:126)
at org.apache.derby.impl.drda.Database.makeConnection(Database.java:257)
at
org.apache.derby.impl.drda.DRDAConnThread.getConnFromDatabaseName(DRDAConnThread.java:1447)
at
org.apache.derby.impl.drda.DRDAConnThread.verifyUserIdPassword(DRDAConnThread.java:1397)
at
org.apache.derby.impl.drda.DRDAConnThread.parseSECCHK(DRDAConnThread.java:3248)
at
org.apache.derby.impl.drda.DRDAConnThread.parseDRDAConnection(DRDAConnThread.java:1177)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:982)
at org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:295)
