Create a Dedicated Event ProcessorIssue Most events go into the sysevent table with no queue specified. These events are picked up and processed by the event processors' jobs, referred to as general events. Events such as the Text Index events (text_index) are added to the sysevent table with a queue of text_index, and these events are processed by the Text Event Processor. These events have a dedicated job process. This knowledge article will provide the benefits, cases where they can be used, and instructions on how to set up the dedicated event processor. Benefits This allows for the separation of workA dedicated (worker) job to process only the events configuredCan be used to help control backlogs caused by slower eventsCan be used to better control priority events Use Case A customer executes a large clean-up script or sync job that updates all change requests. As a result, a large spike in 'ci.affected' events is created. This, in turn, delays all other general event processing. The customer sees the impact on a downstream process as those events are not being processed in a timely manner. ReleaseAll releasesResolutionCreate a Dedicated Event Process job for just the impacted events. This solution greatly reduces the chances that the impacted events could be delayed due to other issues that may be occurring with the instance or the general event queue. How-To Setup Note: The standard Event Processor uses a delegate model where events are pushed, processed, and limited to 500 events per node. This method will not do that. When the job starts, 100% of the pending events for that queue will be claimed. This method was not designed to be multiple-threaded (multiple jobs). Log in as an Admin account to the instanceNavigate to the System Policy > Registry module.Filter on the event name, IE. x_snc_employee_spe.employeeOccasionOpen the record, and input the desired queue name under Queue. IE, my_queue for the use case. Then save the record.You can repeat steps 2-4 for any other named events you want to route to this new dedicated events processor. For example, you might want to route similar events to a single event processor.All newly created events from step 4 now have a queue specified. This is confirmed by going to the System Logs > Events module and filtering down matching event name. The specified queue is only added to newly created events. Create the dedicated Event Processor job for the newly created queue by navigating to the System Scheduler > Scheduled Jobs module.Click the New button.Enter the following values for the fields and then click Submit. (Swap out QUEUENAME for the queue name set in step 4) Name: QUEUENAME events processSystem ID: -- None --Job Context: fcScriptName=javascript\:GlideEventManager('QUEUENAME').process();Trigger type: IntervalRepeat: 30 seconds(Leave all other fields as default, in our example, we used 'my_queue'. Ensure that the Job ID field defaults to RunScriptJob) To verify the new processor is working as expected, navigate to System Logs > Events module, filter down matching event name, and confirm that newly created events are being marked processed. Validation Make sure that you validate that everything is working as expected! Check that the newly created events are going into the correct queueCheck that the newly created events are being processed Video overview of the feature Related LinksReview the related problems fixed in R - VR - Vulnerability Response - Utah 2023 Q1 2: KB1217314 Delayed processing of high priority events due to sn_vul.countforVR event KB1281126 Performance - Calculate Related VI counts for vulnerability may run for days due to inefficient queries