Reporting data not updating, stuck in Server.Log

Topic

Even though workflows start and run fine in some cases the workflow instance reporting data is not updated. There can be many reasons why this would happen and this article will focus on one specific scenario where there are multiple K2 Servers in the farm, new servers are added and old servers removed from the farm.

 

This can cause reporting data assigned to the server removed to get stuck and not process. This article will help with identifying this type of scenario and fixing it.

Instructions

First step is to identify if this could be the cause. To do this the below query can be run which checks for entries in the Server.Log and Server.LogProcInst tables that has a ServerID assigned that belongs to a server that is not running. If no results are returned this scenario does not apply.

_________________________________________

-- Check Server.Log

Select * from [Server].[Log]
where [ServerID]
not in (Select [ID] from [Server].[Server] where [Running] = 1) --- Add only rows that is assigned to a non running K2 Server
AND [ServerID] <> 0 --- Remove rows in the queue from the results

 

-- Check Server.LogProcinst

Select * from [Server].[LogProcinst]
where [ServerID]
not in (Select [ID] from [Server].[Server] where [Running] = 1) --- Add only rows that is assigned to a non running K2 Server
AND [ServerID] <> 0 --- Remove rows in the queue from the results

____________________________________________

To fix the issue the following can be done:

1) Stop all K2 Services (All K2 Servers in the farm)

2) Update the ServerID back to 0 to allow a valid server to pick it up on the next interval to process it. The below script can be used.

____________________________________________

/*
--- Update ServerID assigned to K2 Server that is not running
Update [Server].[Log]
Set [ServerID] = 0
where [ServerID]
not in (Select [ID] from [Server].[Server] where [Running] = 1) --- Add only rows that is assigned to a non-running K2 Server
AND [ServerID] <> 0 --- Remove rows in the queue from the results
*/

/*
--- Delete Server.LogProcinst entries assigned to K2 Server that is not running. These will be repopulated when the Server.Log record is assigned to another server
Delete from [Server].[LogProcinst]
where [ServerID]
not in (Select [ID] from [Server].[Server] where [Running] = 1) --- Add only rows that is assigned to a non-running K2 Server
AND [ServerID] <> 0 --- Remove rows in the queue from the results
*/

___________________________________________

3) Start K2 Service

Additional Information

The problem that can happen due to this is no reporting data is being processed or reporting data processes slow. The reason for that is since the row is assigned to process on a server it uses one of the 5 available K2 Logging threads per server in the farm and if all the threads are hung up on items like this there is not threads to process the Log queue.

 

NOTE:

This article was created based on K2 Five 5.4, direct DB manipulation is not supported. If this articles and the checks leads you to believe this might be the issue, please ensure to open a Nintex case and reference this article. Support will advise if it is safe to run the DB updates.

 

Labels: (1)
Comments

These events include all successful logon attempts to a system. Each event includes categories of information: Log details – log name, source, severity, event ID, and other log information. Subject – account name, domain, and security information about the login. Logon information – type is the method used to log on, such as using the local or remote keyboard (over the network). This field value is expressed as an integer, the most common being 2 (local keyboard) and 3 (network). Additional details about the logon are also available. Impersonation Level – how much authority is given to the server when it is impersonating the client. New Logon – name, domain, and other details for the new logon for the account that was logged on. Process Information – name and ID of the originating process. Network Information – name, IP address, and port where the remote logon request. originated. These values are left blank for local logins, or if the information can’t be found. Detailed Authentication Information –Bazoocam Ome tv details about this specific logon request.

Version history
Revision #:
12 of 12
Last update:
3 weeks ago
Updated by:
 
Contributors