Hi all,
We have the following scenario, all steps performed via JAVA API (so no editorial UI involved).
Has anyone encountered this? Trying step 3 after a while returns the proper reference, I am not sure if Oak somehow "caches" the reference info
Thank you in advance,
Kimon
Solved! Go to Solution.
Hi,
A large number of indexes in Oak are update asynchronously (that applies to all Lucene Indexes). By default the indexing thread is scheduled to run every 5 seconds, and depending on the amount of changes and the time required for indexing the delay can be larger.
The reference search is using the fulltext index, which is a Lucene index.
That means, that you cannot find nodes you just modified/created. You always have to wait a bit. With AEM 6.3 the NRT (near-realtime) indexes have been introduced, which reduce this latency to about 1-2 seconds, but it is still async.
Jörg
Do you have all this in code - what API are you using? PageManager API? Can you show your code - it will help community figure out the issue
Views
Replies
Total Likes
Code segments shown below:
1. Method to retrieve reference paths:
public static String[] getPageRefPaths(String path, ResourceResolver resolver) {
final ReferenceSearch referenceSearch = new ReferenceSearch();
referenceSearch.setExact(false);
referenceSearch.setHollow(false);
referenceSearch.setMaxReferencesPerPage(-1);
List<String> refPaths = new ArrayList<String>();
referenceSearch.search(resolver, path).entrySet().forEach(foundRef -> {
refPaths.add(foundRef.getValue().getPagePath());
});
return refPaths.toArray(new String[refPaths.size()]);
}
2. Moving /content/mysite/page1/pageA to /content/mysite/page2/pageA and adjusting references:
String[] refsToAdjust= getPageRefPaths(currentPage.getPath(), resolver);
Page movedContentPage = pageManager.move(currentPage,targetPath, null, false, true, refsToAdjust,ArrayUtils.EMPTY_STRING_ARRAY);
//after this the page is moved and references are properly adjusted from /content/mysite/page1/pageA to /content/mysite/page2/pageA
3. Later in the code, attempting to get the references of the MOVED page:
//using a different resource resolver than above
//the below returns an empty array
String[] refsOfMovedPage = getPageRefPaths(movedPage.getPath(), resolver);
NOTE:
Running the same exact code as per step 3 above a second time, returns the proper references results. Hence my question on indexing/caching of references in Oak repo.
I noticed ReferenceSearch is doing a JCR Query in the background, so these could be connected.
NOTE 2 - Workaround:
I induced a delay in the code, just before step 3, via Thread.sleep(10000) and seems to have done the trick - the references are now picked up.
However this is not really clean or proper way to do that, in my opinion; maybe there's some sort of repository Event to catch instead of Thread.sleep() approach?
Views
Replies
Total Likes
Yes there is - you can use a JCR Event that is fired when a node is moved. Observation in JCR - Experience Delivers
Views
Replies
Total Likes
Thank you for your reply. I was wondering if there is some sort of JCR Event to catch that is very specific to the context of the flow described above, which indicates that the updated references can be resolved properly. Using a JCR Observers (or Event Listeners) would be a bit of an overkill, I feel (as I would need them only for the scenario above).
To be honest it's not clear to me why the updated references have some "lag time" until they can be resolved via ReferenceSearch; so even if I catch the event I am not really sure what to do with it.
Views
Replies
Total Likes
Hi,
A large number of indexes in Oak are update asynchronously (that applies to all Lucene Indexes). By default the indexing thread is scheduled to run every 5 seconds, and depending on the amount of changes and the time required for indexing the delay can be larger.
The reference search is using the fulltext index, which is a Lucene index.
That means, that you cannot find nodes you just modified/created. You always have to wait a bit. With AEM 6.3 the NRT (near-realtime) indexes have been introduced, which reduce this latency to about 1-2 seconds, but it is still async.
Jörg
Views
Likes
Replies