Just some ideas: 1) are you sure you're "gracefully" terminating the app always? For performance Lucene/JCR etc. does a lot of stuff lazily so you want to make sure you don't just kill the process. For example, I *think* i'm doing a proper shutdown in the close() method here: https://github.com/Clay-Ferguson/meta64/blob/master/src/main/java/com/meta64/mobile/repo/OakRepository.java
If you don't shutdown in a proper way I think the DB will have to go thru a lot of checking and recovery next time it starts. 2) Go into your logger config and set level to TRACE for maximum logging in jackrabbit packages 3) You could create a copy of the DB to experiment with and start removing indexes one at a time, to see which one has the big impact on startup in case it's related to a specific index. 4) Remember your backing DB (MySQL or Mongo, etc) may also have logging configs of it's own you can turn on to get more details what's happening. Best regards, Clay Ferguson [email protected] On Mon, Jun 20, 2016 at 1:44 AM, <[email protected]> wrote: > Good Morning guys, > > we use Jackrabbit in an production environment and detected a wait time in > Workspace Index Init process of about 10min. > Nothing happens in the log between these two lines, anybody knows whats > happening in this step and any ideas why this took so much time? > This is the biggest part of our server restart process. In another > workspace with 50% less data, there is no such "stop" phase. > > 12:34:12.706 *INFO* org.apache.jackrabbit.core.fs.local.LocalFileSystem > LocalFileSystem initialized at path /workspaces/myworkspace > 12:43:24.549 *INFO* org.apache.jackrabbit.core.query.lucene.SearchIndex > Index initialized: /workspaces/myworkspace Version: 3 > > Thanks for any advices and have a nice day, > Michael >
