Fine tuning event processors? Delegated vs legacy event processors

[christianmehrin]

Hi,

We have a need to process asynchronous work in logical sequence. Now all events must be processed in order, but those with same criteria. By now we have solved this by creating a customized queue having only one event processor on the instance (vs. the default queue runs one processor per node).

On high load events getting processed with a long delay. This is causes by many events in very short time. 

In that situation - and having multiple event processors - all new events would be claimed by next event processor started. The other processors would have nothing to do while the first still needs long time until processing latest event claimed.

Side effect is that newer events would be claimed by another processor and will be processed right now (while older ones already claimed still need to wait)

=> Is there a possibility to configure maximum number of events claimed on start of event processor (goal: divide load even on peeks and reduce risk of processing events not in sequence)

=> Is there a possibility to provide a callback that would return events that can be processed now?

Another idea was to set processOn to a date far away if another event with same criteria is still waiting for getting processed. When completed it should set processOn to now for next event. BR seems not to run when updating event to completed - so that would need a scheduled job. For this it would be good to add additional columns to sysevent table to directly store criteria and order (order, as resolution of time = 1s may not be sufficient)

Do you have comments on this?

regards,

Christian 

[Lucas Vieites]

Hi Cristian, I replied to your related question under the blog post titled Improved events processing on the ServiceNow platform. I hope I helped.

Cheers,

Lucas Vieites

[DirkRedeker]

Hi Christian

I read your article and saw, it was created 9 month ago. Do you already have a solution to your topic you might publish here?

I am also interested in how one can cope with situations like that.

Thanks a lot and

BR

Dirk

[christianmehrin]

Hi Dirk,

Not the expected one. We have increased number of nodes and started to run some jobs more often, e.g. not only once a day.

Additionally we have created a "pre-queue". From that queue a configurable number of events will be moved to sysevent queue. When claimed it will move next ones. Additional benefit is, we can control number of nodes processing a specific queue. This helps to load balance but does not solve sequence issue.

regards,

Christian

[DirkRedeker]

Hi Christian

Thanks a lot for your feedback How did you create this "preprocessor"?

Does it mean, you first write the events to a table different from sysevent, and then "move" the records over? Or how does this work in detail.

Thanks a lot, if you could supply some more information on that.

My experience is as well, that each queue catches ALL open and "unclaimed" Events in one catch, making all of them queued up in the one Queue. The next queue free, will just catch up events as soon as new events are created. That matches the solution you implemented.

I thought, there is a configuration to limit the number of Events catched by one queue, before another queue gets the chance to pick up its events. Isn't that possible? ( I haven't found out how to do, but I read somewhere).

Thanks and

BR

Dirk