Background update actions

Build 1501 on 14/Nov/2017  This topic last edited on: 29/Aug/2014, at 10:11

Every time an object is created or modified the system must:

Request the update of the full-text indexes to the Exalead server (if full-text indexing is enabled).

Send alerts to all the clients that requested them for the updated objects (see Alerts).

Schedule the execution of workflow triggered by the updates (see Triggers).

If the object being modified is a partition, a folder's partition or an expiration rule re-compute the expiration rules for all the objects in the modified partition/folder/expiration rule (see Expiration rules and Back4 Cleanup Process).

These operations are execute in background by a separate thread on the server, so that the client does not have to wait for their completion.

If an error occurs in any of these operations, errors are logged in either the Windows Event log or the server textual log (or both) - depending on what is enabled. For example an error in the full-text indexing will look like this in the Windows Event Viewer:

eventlog

In the textual log (GN4.log) it appears as:

/*

  Error while indexing objects after an update:

Exalead indexing failed. Error: 'Unable to connect to the remote server' (ERR2001)

 

  2011-03-18T21:54:10.503+01:00

*/

 

An unexpected/unhandled error will look like this in the Event Viewer:

eventlog2

and like this in GN4.log:

/*

  Unhandled exception while executing actions after an update:

Value cannot be null.

Parameter name: login

   at TeraDP.GN4.Server.TriggerActions.Execute(ServerLogin login) in C:\Tera\GN4\Main\Src\Serve

   at TeraDP.GN4.Server.AfterUpdateActions.Execute(Object state) in C:\Tera\GN4\Main\Src\Server

 

  2011-03-18T21:42:27.783+01:00

*/