SDConnex service cannot be started - "Key not found in dictionary", skipping creating service broker, notification queue errors in Event Log
Issue Upon starting SDConnex one can get an Info message: "Connection to SQL Server was succesful. Initializing SDConnex service now" Error messages containing text like: "Error when starting the service System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary." or "Service cannot be started. System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary." or "Skipping creating service broker as it already exists" or "Skipping creating notification queue as it already exists" The above errors will occur again and again, typically as a set of a number of identical messages whenever SDConnex is started Cause Cache Dependency issue. The SDConnex caching and queuing feature is out of step with the database. This appears to happen sometimes during SES upgrades, but not in all cases. Theory: it could be that the database is being upgraded, but these caches and queues are not being rebuilt In the past issues could arise when database login credentials changed. It may be valuable to determine if credentials has been changed in this instance. Solution Option 1 (relatively quick to try) Reboot the ADSync machine and SQL Server and determine if that fixes the problem. Option 2 (The following steps work for sure) 1) Stop SDConnex service 2) Ask the DBA to back up the database and perform the following changes: a) Launch SQL Management Studio ALTER DATABASE <database> SET NEW_BROKER WITH ROLLBACK IMMEDIATE; 3) Now in SQL Management Studio, expand the database -> Service Broker -> Services node 4) Delete both CacheDependencyService and ClaimsRefreshService. To do this, right click on each of these nodes and in the pop-up menu that will appear, select 'Delete') 5) Next, navigate to database -> Service Broker -> Queues 6) Delete ClaimsRefreshQueue and CacheDependency Queues by right-clicking as above. 7) Restart SDConnex and re-check the logs to ensure that SDConnex starts cleanly and without throwing these log entries. The Caches and Queues will be rebuilt automatically when SDConnex starts up.
Background info: Why does SecureDoc use Broker/Queue techonolgy? The Service Broker allows SES components to give a SQL query to the SQL server. When the results of the query changes, an event is automatically fired in our code. This removes the need to have to poll the database on each request, and instead place logic on these events. Benefits: Generally this allows for substantial data access acceleration, and further enables the following scenarios" Scenario 1 1) Enables caching of data for queries in SESWeb, i.e. user list or device list. SES can serve data from the cache (much more rapidly than going back to the database) ... as long there have been no changes to the underlying data in the database. Queries against low-volatility files can be serviced from the cache. 2) When data is changed inside the database, an event is fired to SES from service broker, so SES can then invalidate the cache, forcing the next read to come from the database's base data (after which the cache will be rebuilt for future usage acceleration). Scenario 2 1) If two admins were logged into the site at the same time and Admin 1 were to revoke Admin 2’s rights from the website, then... 2) The next request for admin 2 will immediately fail, as SES will invalidate that admin's login.
Resource: NHu
|
Custom Fields
|