[
https://issues.apache.org/jira/browse/SLING-9906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17273081#comment-17273081
]
Stefan Egli commented on SLING-9906:
------------------------------------
* started prototyping on this in a forked branch
[here|https://github.com/stefan-egli/sling-org-apache-sling-event/tree/SLING-9906]
(still in early stages though)
* the idea being to have a unit test (not pax exam as that is too shielded for
this case) and for that some package-protected methods and constructors were
added/modified. shouldn't have any influence on package versioning though.
* the plan is to look into "halting" topics that have
{{ClassNotFoundException}} when loading jobs. It is of course an open question
as to what to do with those jobs - as it could in theory be that only a couple
of jobs of a topic have this issue, and then halting the entire topic might be
seen as unfair. However I believe that this is a failure in the setup if this
case happens - so halting a bit too much shouldn't be an issue at that stage
IMO.
* besides introducing this "halting", the idea is also to reduce the log.warn
noisiness as suggested.
* will also be looking into the re-assigning issue - probably as the last step
(as I fear that wouldn't have helped in the issue at hand).
> Avoid retrying to load jobs if classes are missing
> --------------------------------------------------
>
> Key: SLING-9906
> URL: https://issues.apache.org/jira/browse/SLING-9906
> Project: Sling
> Issue Type: Improvement
> Components: Event
> Reporter: Carsten Ziegeler
> Assignee: Stefan Egli
> Priority: Major
> Fix For: Event 4.2.14
>
>
> When a Sling job is tried to be loaded, it might reference public api classes
> provided by bundles - although that is a bad pattern that should be avoid,
> sometimes this is used.
> While the job engine does not try to reload those jobs for execution - unless
> such a new job is created (which is unlikely as the class is missing), the
> re-assigning of jobs from a removed instance to a new one suffers from the
> same problem. And that is retried over and over again.
> So there are probably several possible improvements:
> - make sure that jobs are not reloaded when public classes are missing during
> job execution (unless bundles have changed)
> - reduce log output to a log statement (except of stack trace) if
> classloading for jobs fails
> - change re-assigning of jobs to not require classes to be available. This
> can probably be solved by using ResourceResolver.move
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
