Warning related to "Large multi valued property"

[Shailesh_Bassi_]

Getting the below warning in the logs

14.06.2022 20:17:59.104 *WARN* [sling-default-1-com.day.cq.replication.audit.impl.EventProcessor:a8f5e0b5-14fa-48fb-b6ad-53bfe8ed1f72] org.apache.jackrabbit.oak.jcr.session.NodeImpl Large multi valued property [/var/audit/com.day.cq.replication/etc/d8a323ac-6c3c-4ca0-b848-dc86533f812c/paths] detected (1339 values).

14.06.2022 18:41:55.508 *WARN* [sling-threadpool-29fa2e7d-f868-4810-959e-ca29886398a3-(apache-sling-job-thread-pool)-31-<main queue>(ref-updater/references)] org.apache.jackrabbit.oak.jcr.session.NodeImpl Large multi valued property [/var/eventing/jobs/assigned/319d72ae-89e3-4a79-ab7b-e2e767500a08/ref-updater.update/2022/6/14/18/41/319d72ae-89e3-4a79-ab7b-e2e767500a08_22384/refs] detected (7717 values).

Can anyone provide some pointers, why could this happen and how to fix it?

[Jörg_Hoh]

Having many large nodes does have a negative impact on performance, because they consume large amount of cache for little benefit. Also it's a hint that your information architecture might be in-balanced.

In the above mentioned message Oak complains about large audit events which do have many values in the path resp ref property.

The first entry is an audit entry which records all paths which were replicated in a single call. That means, it's not necessarily a problem of the information architecture, but here it indicates that your application replicated once 1139 paths in a single call. It's perfect fine to do so (at least in AEM 6.x there is no limit to this, while in Cloud Service there is, see the documentation[1]), but you consider to use smaller batches. I would consider the CS limits a reasonable guideline also for AEM 6.x.

The second message indicates that there is a large job node. That's driven by the implementation of this specific job, and I don't think that it's easy to fix. Nevertheless this should be a temporary node (it will removed eventually), thus I would recommend to ignore it.

Technically both are just warnings and there is functional problem with it. It's just that too many of them will impact the effectivity of your caches.

[1] https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/operations/replicat...section "path and size limits"

[Shailesh_Bassi_]

@Jörg_Hoh Is there any way by which we can determine what is the path on which the job "ref-updater/references" so that the information architecture at that path can be corrected?

Tried adding the logs for the package "org.apache.jackrabbit.oak.jcr.*", but there is no logger to indicate where the path.

Thanks

[Jörg_Hoh]

It's a Sling job, so its payload should be stored. I would check in

/var/audit/com.day.cq.replication/etc/d8a323ac-6c3c-4ca0-b848-dc86533f812c/

and

/var/eventing/jobs/assigned/319d72ae-89e3-4a79-ab7b-e2e767500a08/ref-updater.update/2022/6/14/18/41/319d72ae-89e3-4a79-ab7b-e2e767500a08_22384

[Shailesh_Bassi_]

@Jörg_Hoh Is there a way we can stop the deletion of the nodes under the path "/var/eventing/jobs/assigned/*" so that the "cq:path" property value from the node.

Thanks

[Jörg_Hoh]

I don't think so, this is the active queue and job definitions are stored there. They will be removed when the job has completed.