Public class MyJobConsumer implements JobConsumer can be used for replacing the matched part. It registers itself as an OSGi service together with a property defining which topics this consumer can process: import .annotations.Component Job ConsumersĪ job consumer is a service consuming and processing a job. When the scheduled time is reached, the job is automatically added as regular Sling Job through the JobManager. But in addition they are persisted (by default below /var/eventing/scheduled-jobs) and survive therefore even server restarts. Internally the scheduled Jobs use the Commons Scheduler Service. something went wrong here, use scheduleBuilder.add(List) instead to get further information about the error ScheduleBuilder.daily(0,0) // execute daily at midnight ScheduleBuilder scheduleBuilder = jobManager.createJob("my/special/jobtopic").schedule()
#Configure simultaneous processes coda 2 code#
For that the ScheduleBuilder must be used which is retrieved via JobBuilder.schedule().Īn example code for scheduling a job looks like this: import .JobManager Scheduled Jobs are put in the queue at a specific time (optionally periodically). The last method being called on the JobBuilder must be add(.), which finally adds the job to the queue. Instead of creating the jobs by calling JobManager.addJob("my/special/jobtopic", props) the JobBuilder can be used, which is retrieved via JobManager.createJob("my/special/jobtopic"). This is required as the job is persisted and unmarshalled before processing.Īs soon as the method returns from the job manager, the job is persisted and the job manager ensures that this job will be processed exactly once. All objects in the payload must be serializable and publically available (exported by a bundle). The job topic follows the conventions for the topic of an OSGi event. JobManager.addJob("my/special/jobtopic", props) Import class M圜omponent JobManager jobManager A client can initiate a job by calling the JobManager.addJob method: import .JobManager
This approach is preferred over the still supported but deprecated event admin way.Ī job consists of two parts, the job topic describing the nature of the job and the payload which is a key value map of serializable objects. While older versions of the job handling were based on sending and receiving events through the OSGi event admin, newer versions provide enhanced support through special Java interface. The Sling Jobs Processing adds some overhead, so in some cases it might be better to use just the Commons Scheduler Service or the Commons Thread Pool for asynchronous execution of code. However this is considered a deployment error. Of course, if there is no job consumer for a job, the job is never processed. Therefore a job consumer should be prepared to process a job more than once. It happens if the instance which processes a job crashes after the job processing is finished but before this state is persisted. However, the time window for a single job where exactly once can't be guaranteed is very small. To be precise, the processing guarantee is at least once. A job is a special event that has to be processed exactly once. The Sling Event Support adds the notion of a job. Typical examples are sending notification emails (or sms), post processing of content (like thumbnail generation of images or documents), workflow steps etc. On the other hand, there are use cases where the guarantee of processing is a must and usually this comes with the requirement of processing exactly once. Processing of an event could fail, the server or bundle could be stopped etc. As the event mechanism is a "fire event and forget about it" algorithm, there is no way for an event admin to tell if someone has really processed the event.
Therefore, it can't decide if an event is important and should be processed by someone. In general, the eventing mechanism (OSGi EventAdmin) has no knowledge about the contents of an event. To get some hands on code, you can refer to the following tutorials: The bundle provides the following features The Apache Sling Event Support bundle adds additional features to the OSGi Event Admin and for distributed event processing.
0 kommentar(er)
