Are there any performance issues when dealing with javax.jcr.observation.EventListener? | Community
Skip to main content
Level 6
September 7, 2022
Solved

Are there any performance issues when dealing with javax.jcr.observation.EventListener?

  • September 7, 2022
  • 2 replies
  • 710 views

Hi there, we are using javax.jcr.observation.EventListener to check if every created page has a property, and if it does, do something, This is set with an absolute path to /content/my-site. (we are targeting the jcr:content nodes)

Has anyone used this before, and are there any performance impacts that we should be aware of?

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by joerghoh

Hi,

 

If you are targetting the "jcr:content" node of pages, you can refine the registration for the observation listener and express, that you are only interested in changes on nodes of nodetype "cq:pageContent".

That's a very good way to reduce the overhead, because your code is only invoked in this special case.

 

Using Sling's ResourceChangeListener is less effective in this special case, because it cannot be limited by the nodetype. And that's a very effective measure to reduce the number of invocations.

 

2 replies

arunpatidar
Community Advisor
Community Advisor
September 8, 2022

Hi,

You can also use Sling Resource Listener which provide high level API.

https://github.com/arunpatidar02/aem63app-repo/blob/master/java/SampleResourceChangeListener.java 

Arun Patidar
Level 6
September 8, 2022

Thanks, but do you know the performance for the Sling Resource Listener?

But back to my question, Are there any performance issues when dealing with javax.jcr.observation.EventListener?

How about @joerghoh? can you please shed some light?

joerghoh
Adobe Employee
joerghohAdobe EmployeeAccepted solution
Adobe Employee
September 9, 2022

Hi,

 

If you are targetting the "jcr:content" node of pages, you can refine the registration for the observation listener and express, that you are only interested in changes on nodes of nodetype "cq:pageContent".

That's a very good way to reduce the overhead, because your code is only invoked in this special case.

 

Using Sling's ResourceChangeListener is less effective in this special case, because it cannot be limited by the nodetype. And that's a very effective measure to reduce the number of invocations.