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 <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?
