Hi Eric, On Fri, Jun 1, 2018 at 1:29 PM, 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.
Are you sure you are able to query or find the images in node1? Blob data in the table doesn't necessarily mean that the binary data is stored in a JCR node's binary property. The blob data could be referred by another node or versioned frozen node or non-existing node which can be caused by node deletion but the binary data wasn't garbage-collected. So, I'd traverse the nodes through simple JCR API and validate if the nodes really exists even in node1. You might need to ask around about the paths of the recently added nodes containing the binary data to do that. > > 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. I'm kind of suspicious that some of the new nodes in last two weeks might have been removed for some reasons. You can perhaps rule out this possibility by inspecting JCR nodes on node1 first. Regards, Woonsan > > Any help or ideas to troubleshoot are greatly appreciated. > (jackrabbit 2.6) > > Thank you! > Eric
