Upon further investigation, I've seen if there are more than 4 files in the log directory, mounting takes significantly longer but i've also seen 20+ files mount instantly. I had the idea of monitoring that directory to see if the file count changes during the recovery process. It does, but sometimes the count goes up, other times it goes down or does not change until shutdown.. I was hoping to get a notice to the user of something like 30% complete or a progress bar kind of thing. So no luck there.
Is this information exposed as a mxbean by chance? Even with cranking up the logging for derby, there doesn't appear to be any indication of what's going on. On Sun, Feb 7, 2021 at 2:12 PM Alex O'Ree <alexo...@apache.org> wrote: > That's perfect, although from my testing, it seems like more than 4 files > indicate an unclean shutdown. I just want to alert the user that it may > take some time to fire up the database connection > > On Sun, Feb 7, 2021 at 10:24 AM Peter Ondruška <peter.ondru...@kaibo.eu> > wrote: > >> There is very easy way to check if you are going to run database recovery >> at boot time by looking into logs subfolder. If you gracefully shut down, >> there are only two log files. If there are more your database will perform >> roll forward recovery, in worst case applying all the log files. >> >> >> >> *From:* Rick Hillegas <rick.hille...@gmail.com> >> *Sent:* Sunday, February 7, 2021 4:11 PM >> *To:* Derby Discussion <derby-user@db.apache.org>; Alex O'Ree < >> alexo...@apache.org> >> *Subject:* Re: Slow mount times >> >> >> >> I don't know of any special trace flags for this. Maybe something will >> turn up in derby.log if you set the diagnostic logging level to its most >> verbose level by running the application with the following system property: >> >> >> >> -Dderby.stream.error.logSeverityLevel=0 >> >> >> >> Hope this helps, >> >> -Rick >> >> >> >> On 2/6/21 6:53 PM, Alex O'Ree wrote: >> >> Thanks i'll give it a shot. >> >> Is there any logging in derby that i can enable into regarding this? >> >> >> >> On Sat, Feb 6, 2021 at 7:08 PM Rick Hillegas <rick.hille...@gmail.com> >> <rick.hille...@gmail.com> >> >> wrote: >> >> >> >> The usual cause for this behavior is that the application was brought >> >> down ungracefully, say via a control-c or by killing the window where it >> >> was running. The engine then needs to reconstruct the state of the >> >> database by replaying many recovery logs. To gracefully exit Derby, you >> >> need to explicitly shutdown Derby as described here: >> >> https://db.apache.org/derby/docs/10.15/devguide/tdevdvlp20349.html >> <https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdb.apache.org%2Fderby%2Fdocs%2F10.15%2Fdevguide%2Ftdevdvlp20349.html&data=04%7C01%7Cpeter.ondruska%40kaibo.eu%7C0ab75b41f6904f15603308d8cb7aa472%7C971fa002c3a649c18191cb7e49d9cb77%7C0%7C0%7C637483074906136655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HPDIFmPdYNgi7O9ALYzgmUdyyxRa7i99KSdPPWkL6pc%3D&reserved=0> >> >> >> >> On 2/6/21 3:39 PM, Alex O'Ree wrote: >> >> Sometimes when my app starts, it can take several minutes to initialize >> >> the >> >> database. Is there a way to find out whats going on? There isn't much log >> >> output. I have overridden derby.stream.error.method but other than the >> >> the >> >> startup message, I don't have much to go on. >> >> >> >> Is there perhaps a startup database file check or something? >> >> >> >> >> >> >> >> >> >> >> >
