Expand my Community achievements bar.

SOLVED

AEM 6.3 | Retrieving page references issue

Avatar

Adobe Champion

Hi all,

We have the following scenario, all steps performed via JAVA API (so no editorial UI involved).

  1. page /content/mysite/page1/pageA is referenced by pageB (content path irrelevant).
  2. page /content/mysite/page1/pageA is moved to /content/mysite/page2/pageA, reference in pageB is adjusted properly (via PageManager API).
  3. retrieving reference for pageA now, returns an empty collection, as if it's not referenced at all.
  4. reference retrieval done via ReferenceSearch API.

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

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

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

View solution in original post

5 Replies

Avatar

Level 10

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

Avatar

Adobe Champion

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?

Avatar

Level 10

Yes there is - you can use a JCR Event that is fired when a node is moved. Observation in JCR - Experience Delivers

Avatar

Adobe Champion

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.

Avatar

Correct answer by
Employee Advisor

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