19

I believe the primary reason is each event has an associated target database. Found a brief explanation here by Kiran Patils on how the event queuing works: The CM instance triggers an event such as "publish:end:remote". The triggered event is added to the EventQueue table in the database that is targeted by the event. For example, the publish:end:remote ...


17

In order to know which if the events have already been processed, you will need to check the Properties table. Using Sitecore OOTB You need to see the http://[domain]/sitecore/admin/EventQueueStats.aspx page. This page allows you to see if there are still events being processed. If we take the above as an example, it means that all events have been ...


11

In Sitecore 9.x There is a new message bus implementation based on Rebus with an RabitMQ Transport Provider. This can be leveraged for your own custom requirements too. It is used already in Sitecore 9 by: EXM Dispatch Marketing Automation xConnect There is more info on this here: https://doc.sitecore.com/developers/90/platform-administration-and-...


8

Answer All databases have an [EventQueue] in order to help spread out responsibilities and reduce the load on a particular database. Explanation The [EventQueue] table exists as a means of communication among all web servers that connect to it. One web server can queue an event in any database it has access to. This event is then read by any other web ...


7

In Sitecore 9 the event model has changed somewhat and events are now queued within each DB (master, core, web etc). This is partially correct. You could always queue remote events in your Sitecore database of choice. Sitecore 9 still has a concept of a preferred event queue database. Two options for queueing a remote event Sitecore.Eventing....


7

The event queue table has two columns related to the matter. They are RaiseGlobally (true by default) and RaiseLocally (false by default). These flags control the event execution appropriately (i.e. if RaiseGlobally is false, the event will not be processed by remote servers) In order to control those flags, you can use the second overload of the ...


6

After having processed an event from the queue each instance updates the associated last processing timestamp (LPT) which is stored in the Properties table and has the key in the following format 'EQStamp_{Sitecore-Instance-Name}' Therefore, you can use the LPT to filter out events which have already been processed by a given instance - literally just the ...


6

Not out of the box. You could theoretically craft something on top of the EventQueue, but I would probably look to third party solutions. https://particular.net/nservicebus https://azure.microsoft.com/en-us/services/service-bus/ Edited to add: Enterprise Service Bus (ESB) within an environment that includes Sitecore There are indications that Sitecore ...


6

I found out that field is populated with UTC regardless of what the server time zone is.


5

In order to be 100% sure that a particular event was processed by all servers, you would need to write a rather complex query. To illustrate, I've written a query to return all events processed by a single web server: SELECT * FROM [EventQueue] where [Stamp] <= ( select Cast(CONVERT(nvarchar(100), [Value]) as int) from [Properties] where [Key] = ...


4

You can usually improve this by tuning the settings for our queues. A good post in this can be found here: https://briancaos.wordpress.com/2016/08/12/sitecore-event-queue-how-to-clean-it-and-why/ What I normally do: On the CM: clean the eventqueue very aggressively On the CD: poll the eventqueue less aggressively disable the eventqueue cleaning Example:...


4

Expanding from the above answer you can try the below SQL Query to know the Number of Records to be processed from a given time and date: SELECT COUNT(*) FROM EventQueue WITH (NOLOCK) WHERE (InstanceName <> @p1 AND RaiseGlobally=1 OR InstanceName = @p1 AND RaiseLocally=1) AND Stamp >= @p2 AND Created >= @p3 where @p1 = InstanceName ...


3

For reference there is a nice response on StackOverflow as to how cleanup the queue. Sitecore recommends fewer than 1000 items in the table and the solution to keep them below that is to run the agents more frequently. Assuming the server times are synchronized and properly configured, you should expect within a few minutes of the agent running that the ...


3

Technically you could run a custom SQL query to see if a server completed execution of a Remote Event, but I wouldn't recommend it. When you say: Is there anyway i can get notified except watching for EventQueue table status? This operation happens automatically when the EventProvider polls the various [EventQueue] tables. Therefore, part of what you ...


3

The solution mentioned in Dan Sinclair's comment worked to fix this issue. Thanks Dan! DELETE FROM [Core].[dbo].[Properties] WHERE [Key] LIKE '%_LAST_UPDATED_TIMESTAMP%'


3

I was suffering from a similar issue for the SQL server for different databases. Below are the details. Cloud Environment: Sitecore Managed Cloud XP-Small and XP-Medium Sitecore Version: Sitecore 9.1 Update 1 Cause of the issue: By default from Sitecore Managed Cloud Team indexing strategy was set to "onPublishEndAsyncSingleInstance" in CD role. And ...


2

Can't say I've had to do this, but firing up my friend ILSpy, I've got a few ideas for you: You can open Sitecore.Kernel and find IEventQueue and "analyze" the QueueEvent() method to find places it's used in real code. That lets me find this code: private Handle QueuePublish(DistributedPublishOptions[] options, Language clientLanguage) { Handle handle ...


1

Sitecore has released on 8.2 the publishing service which is not built into the product but it's a service that works really well for that. This is more as an FYI. But you said you are running on 8.1 so the only way you can get around that is by establishing processes if upgrading is not an option. For example do all of those users need publishing ...


1

I think it's your big event queue. Try the following - Make sure your CD indexes indexing strategy is set to manual. This will prevent double indexing of the web content. Of course there may be exceptions. Another issue might be excessive processing of the event queue. Apply this patch - https://kb.sitecore.net/articles/930920 and see if it makes a ...


1

Every time an index update operation occurs, an index update timestamp is written to the Property table of the core database. This is a known issue related to this behavior. This happens because Sitecore Content Search uses the Properties database table for storing instance specific search indexes metadata. For example, it stores the time of the last index ...


1

transpires that contrary to previous advise from sitecore support that you should be replicating the properties table, as otherwise the CM and CD servers have no knowledge of each others event queues. seems to me that by doing this you are potentially replicating the properties table before the event has actually been processed but i'm led to believe that ...


Only top voted, non community-wiki answers of a minimum length are eligible