I can't tell if you are saying you get an exception thrown, that is recovered from over and over, and finally completes in 1-2 days --OR-- if you are experiencing normal processing with no issues, but it is just taking too long (days). If it's an exception, please send us the stack trace, and a little more info. If it's just taking too long, you need to try and locate the bottleneck, because there might be one. You'd have to create an experimental copy of this setup, and use it to start removing indexes until you find which one is making it slow, then address that specific problem. I'm not proficient in these areas of the API myself, but making couple of general observations.
Best regards, Clay Ferguson [email protected] On Thu, Dec 29, 2016 at 2:54 AM, <[email protected]> wrote: > Hi Guys, > > we faced the problem with "Unable to lock global revision table" after an > Index rebuild. > The Index build takes 1-2 days. After that process, the revisions of this > range gets synchronized. > > Is there any possibility to make this revision sync after index build > smoother? The syncDelay for the journal is set to 2seconds for our servers, > is this also used for the rev sync after an index build? If true, maybe we > can set this value higher for the index rebuild startup an lower it again > after the sync process. > > We try to calculate the time to move this process in the nightly hours, > but this isnt relyable. > > Thanks a lot. > Michael >
