On Fri, Jun 1, 2018 at 7:58 PM, Eric Berryman <[email protected]> wrote: > I apologise, my subject line is not fitting. > > But, if I upgrade to oak ... What's the odds this would solve my problem?
Considering to move to oak might be good in general for other reasons (e.g, architectural concerns), but not for this problem. Jackrabbit 2 doesn't have this kind of basic issues. I would look into the problem further to determine whether it's a bug or not. If there's any known issue in 2.6, I would upgrade it to the latest stable one (2.16.x at the moment) first. Regards, Woonsan > > On Fri, Jun 1, 2018, 13:29 Eric Berryman <[email protected]> wrote: > >> Hello! >> >> I have an application that uses jackrabbit to save images, using the >> database filestore. >> I have jackrabbit clustered (node1, node2). >> This was working for me fine, but I started seeing an oddity. >> Node1 inserts an image, but node2 doesn't seem to see it when queried >> anymore. >> So, node2 is now missing about the last 2 weeks of images. >> I can see the correct image as a blob in the jcr_ds_DATASTORE table. >> >> And, node2 logged that the journal has been applied. >> The LOCAL_REVISIONS table shows both nodes have a revision id of 605 >> (although I do have 1364 images). >> >> I've tried adding enableConsistencyCheck=true and >> forceConsistencyCheck=true to the index part of the repository.xml file. >> But, I don't see any errors. Just, that the consistency check happened. >> >> I've also tried clearing the index directory of node2. Jackrabbit >> recreates the index, applies the 605 journal entries, then ends up in the >> same state without the last two weeks of images. >> >> Are there any ideas to fix what seems to be an index issue. >> >> Any help or ideas to troubleshoot are greatly appreciated. >> (jackrabbit 2.6) >> >> Thank you! >> Eric >>
