Re: Slow mount times
The Derby engine has some trivial mxbeans which return simple, static facts--but nothing which would give you visibility into the progress of boot-time recovery. On 2/15/21 10:15 AM, Alex O'Ree wrote: 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 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 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 *Sent:* Sunday, February 7, 2021 4:11 PM *To:* Derby Discussion ; 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 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=04%7C01%7Cpeter.ondruska%40kaibo.eu%7C0ab75b41f6904f15603308d8cb7aa472%7C971fa002c3a649c18191cb7e49d9cb77%7C0%7C0%7C637483074906136655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=HPDIFmPdYNgi7O9ALYzgmUdyyxRa7i99KSdPPWkL6pc%3D=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?
Re: Slow mount times
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 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 > 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 >> *Sent:* Sunday, February 7, 2021 4:11 PM >> *To:* Derby Discussion ; 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 >> >> >> 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=04%7C01%7Cpeter.ondruska%40kaibo.eu%7C0ab75b41f6904f15603308d8cb7aa472%7C971fa002c3a649c18191cb7e49d9cb77%7C0%7C0%7C637483074906136655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=HPDIFmPdYNgi7O9ALYzgmUdyyxRa7i99KSdPPWkL6pc%3D=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? >> >> >> >> >> >> >> >> >> >> >> >
Re: Slow mount times
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 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 > *Sent:* Sunday, February 7, 2021 4:11 PM > *To:* Derby Discussion ; 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 > > > 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=04%7C01%7Cpeter.ondruska%40kaibo.eu%7C0ab75b41f6904f15603308d8cb7aa472%7C971fa002c3a649c18191cb7e49d9cb77%7C0%7C0%7C637483074906136655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=HPDIFmPdYNgi7O9ALYzgmUdyyxRa7i99KSdPPWkL6pc%3D=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? > > > > > > > > > > >
RE: Slow mount times
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 Sent: Sunday, February 7, 2021 4:11 PM To: Derby Discussion ; Alex O'Ree 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 <mailto: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=04%7C01%7Cpeter.ondruska%40kaibo.eu%7C0ab75b41f6904f15603308d8cb7aa472%7C971fa002c3a649c18191cb7e49d9cb77%7C0%7C0%7C637483074906136655%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000=HPDIFmPdYNgi7O9ALYzgmUdyyxRa7i99KSdPPWkL6pc%3D=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?
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 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 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?
Re: Slow mount times
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 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 > > 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? > > > >
Re: Slow mount times
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 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?
