[Documentation] Sling Job documentation uses immediate component

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[Documentation] Sling Job documentation uses immediate component

justzzzz
Hi,
It has been pointed out to me that on
https://sling.apache.org/documentation/tutorials-how-tos/how-to-manage-events-in-sling.html#starting-a-job,
the sample code shows an EventHandler which has @Component(immediate=true).

As far as I know, this is an anti-pattern. The use of immediate=true is
unnecessary for EventHandlers (in general) since DS will automatically
activate them when/if an event matches the filter.

Is this understanding correct? Is there a reason our documentation has
immediate=true here?

Regards,
Justin
Reply | Threaded
Open this post in threaded view
|

Re: [Documentation] Sling Job documentation uses immediate component

Felix Meschberger-3
Hi Justin

EventAdmin will getService and ungetService the matching EventHandler services for each event to be dispatched. If the component is a delayed service, which as you state is the default, this means the instance is created and dropped for every single event. If there are a lot of them, this will place some load on the system.

If there are not many events, it might indeed be better to make it a delayed service component.

I think there once has been a discussion on some list (I cannot remember where or when, sorry) coming to the conclusion, that EventHandler services better be immediate.

Regards
Felix

> Am 10.11.2016 um 15:17 schrieb Justin Edelson <[hidden email]>:
>
> Hi,
> It has been pointed out to me that on
> https://sling.apache.org/documentation/tutorials-how-tos/how-to-manage-events-in-sling.html#starting-a-job,
> the sample code shows an EventHandler which has @Component(immediate=true).
>
> As far as I know, this is an anti-pattern. The use of immediate=true is
> unnecessary for EventHandlers (in general) since DS will automatically
> activate them when/if an event matches the filter.
>
> Is this understanding correct? Is there a reason our documentation has
> immediate=true here?
>
> Regards,
> Justin

Reply | Threaded
Open this post in threaded view
|

Re: [Documentation] Sling Job documentation uses immediate component

Carsten Ziegeler
Felix Meschberger wrote
> Hi Justin
>
> EventAdmin will getService and ungetService the matching EventHandler services for each event to be dispatched. If the component is a delayed service, which as you state is the default, this means the instance is created and dropped for every single event. If there are a lot of them, this will place some load on the system.
>
> If there are not many events, it might indeed be better to make it a delayed service component.
>
> I think there once has been a discussion on some list (I cannot remember where or when, sorry) coming to the conclusion, that EventHandler services better be immediate.
>

Right, I think we discussed this long time ago on the Felix list.

Components not providing a service should never declare immediate.
If a component provides a service it should not declare immediate. As
with every rule there are exceptions, and event handler is one of them.

 Carsten

--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Documentation] Sling Job documentation uses immediate component

Carsten Ziegeler
In reply to this post by justzzzz
Justin Edelson wrote

> Hi,
> It has been pointed out to me that on
> https://sling.apache.org/documentation/tutorials-how-tos/how-to-manage-events-in-sling.html#starting-a-job,
> the sample code shows an EventHandler which has @Component(immediate=true).
>
> As far as I know, this is an anti-pattern. The use of immediate=true is
> unnecessary for EventHandlers (in general) since DS will automatically
> activate them when/if an event matches the filter.
>
> Is this understanding correct? Is there a reason our documentation has
> immediate=true here?
>
> Regards,
> Justin
>
I've updated the docs (not published yet)


Carsten

 

--
Carsten Ziegeler
Adobe Research Switzerland
[hidden email]