Troubleshooting Notification Generation

This section covers problems that might occur while generating notifications. Some of these are problems with the generator itself, and others are problems with the input it is given and the logic that it executes.

The Generator Is Not Running

This section covers problems that prevent the generator from running.

The SQL-NS Service Hosting the Generator Is Not Started

Refer to the earlier section "The SQL-NS Service Hosting the Event Provider Is Not Started" (p. 510) and apply the information given there to the SQL-NS Service hosting the generator.

The Generator Is Not Enabled

Symptom: The generator is not running, and its status is reported as Disabled or Disable Pending.

Cause: Either the generator was never enabled after the instance was created or updated, or it was explicitly disabled.

Action: Use the nscontrol enable command to enable the generator from the command line. If you want to enable only the generator, without enabling other components, you can use the -generator option. Alternatively, use the Instance Properties dialog box to enable the generator from Management Studio. The section "Enabling and Disabling Components" (p. 492) in Chapter 14 provides details on the use of these tools.

No Notifications Are Generated

This section covers situations in which the generator is running, but no notifications are actually generated.

There Are No Events to Process

Symptom: No notifications are generated, and there are no events in the event tables or event chronicles.

Cause: Either no events were submitted into the system, or the event chronicle rules did not update the event chronicles correctly.

Action: If there are no events in the events tables, refer to the earlier "Troubleshooting Event Submission" section (p. 510) for an explanation of some possible causes.

If there are events in the events table, but the event chronicles do not contain the expected data, some of the event chronicle rules may have encountered runtime errors when they were invoked. The common rule firing errors are covered in the sections "A Rule Timed Out" (p. 516) and "An Error Occurred During Rule Execution" (p. 516), later in this chapter. Consult those sections and apply their recommendations to diagnose problems executing the chronicle rules.

Even if the chronicle rules execute without errors, they may still contain logic flaws that cause them to produce incorrect results. Examine the rules' statements, and use the SQL-NS debugging stored procedures to execute them manually and check their results. Chapter 11, "Debugging Notification Generation," provides information on how to use the debugging stored procedures.

There Are No Subscriptions to Process

Symptom: No notifications are generated, and there are no errors in the Application Event Log.

Cause: There might not be any subscriptions in the system, or the subscriptions that exist might be disabled or not be scheduled to run at the current time.

Action: Examine the subscription tables to determine whether there are subscriptions in the system. If not, add subscriptions using the Subscription Management Interface, a T-SQL script that inserts into the subscription views, or the SubscriptionLoader tool supplied with this book's source code. For information on the SubscriptionLoader tool, see the section "Testing Scheduled Subscriptions" (p. 176) in Chapter 6, "Completing the Application Prototype: Scheduled Subscriptions and Application State."

If the subscriptions table does contain subscriptions but they are disabled (the values in the Enabled column are all 0), they will not be matched to produce notifications. Enable the subscriptions via the SQL-NS Subscription Management API (covered fully in Chapter 7, "The SQL-NS Subscription Management API") or by updating their Enabled values to 1 using T-SQL statements against the subscription views.

If the subscriptions in the system are all scheduled subscriptions, their schedules might be such that they are not due to be evaluated at the current time. You can use the NSScheduledSubscriptionList and NSScheduledSubscriptionDetails stored procedures to determine which subscriptions are scheduled to run at the current time (refer to the "Using the Scheduled Subscription Debugging Stored Procedures" section, p. 411, in Chapter 11 for more information).

Subscription and Event Data Do Not Match

Symptom: There are events in the system, the event chronicles are updated as expected, and the subscriptions tables contain valid subscriptions to process, but no notifications are generated, and no errors appear in the Application Event Log.

Cause: The events and subscriptions are matched based on the logic defined in the match rules. The match rule might contain a logic flaw, or it might simply be the case that the event data being submitted does not match any of the defined subscriptions.

Action: Examine the event and subscription data and verify the results of the match rules using the debugging stored procedures (described in Chapter 11). If the rule logic contains an error that prevents event and subscription data from being matched as they should, you will have to edit the rules and update the application. If the rule logic is correct, you should add different subscriptions or change the incoming event data to force some matches.

A Rule Timed Out

Symptom: The Application Event Log on the generator machine contains an entry with event ID 4045 and an error message indicating a rule timeout.

Cause: The execution of a match rule or chronicle rule took longer than the allowed execution time.

Action: Examine the event message to determine which of the rules timed out (the message will contain the rule text). By default, rules are allowed to execute for up to 30 minutes. If your application runs with very large volumes of data, or the rules perform very complex operations, they may well require longer than 30 minutes to run. In these cases, you can extend the timeout using the <ActionTimeout> element in the rule declaration. Refer to the SQL-NS Books Online for more information on the <ActionTimeout> element.

Caution

Carefully examine whether the rule execution time is reasonable before adjusting the timeout. Simply extending the rule timeout on a long-running rule might mask an underlying performance problem that causes the rule to take more execution time than it should.

The logic of a long-running rule might be expressed in an inefficient way, or the tables against which it operates may not be indexed properly. Also, the database system on which it runs may not be optimally configured. Refer to the "Indexes and Query Optimization" section (p. 425) in Chapter 12, "Performance Tuning," for information on rule optimization. The "Configuring a Database System for Deployment" section (p. 456) in Chapter 13, "Deploying a SQL-NS Instance," provides information on configuring a database system for best performance.

An Error Occurred During Rule Execution

Symptom: The Application Event Log on the generator machine contains an entry with event ID 4045 and an error message indicating that a runtime error occurred while executing the rule.

Cause: A runtime error occurred either in the generator framework that executes rules or in the rule itself.

Action: Examine the event message to determine which of the rules were involved in the error (the message will contain the rule text). The event description usually gives specifics about the type of error that occurred. When diagnosing the causes of rule errors, it can sometimes help to use the debugging stored procedures to run the rule manually and examine the application state before and after the rule execution. Chapter 11 provides information on how to use the debugging stored procedures. After you identify the problem with the rule, you will need to fix it in the ADF and update the instance.

The Event, Subscription, or Notification Throttle Was Exceeded

Symptom: Notifications are not generated, and the Application Event Log contains event messages indicating that one or more of the throttles were exceeded. Such event messages usually have event IDs 4120, 4121, or 64024.

Cause: One of the application-defined throttles was exceeded during the execution of the rule.

Action: Examine the event message to determine which throttle (event, subscription, or notification) was exceeded. The throttle values are declared in the ADF, in the <ApplicationExecutionSettings> element. If not declared, the throttle values default to 1000. You should either increase the throttle values if they are too low or examine your data and rule logic for problems if the number of events, subscriptions, or notifications being processed exceeds expected volumes. Throttles being exceeded might also be an indication of a security violation, so you should examine your system for evidence of suspicious activity. For more information about throttles, refer to the "Using Throttles" section (p. 474) in Chapter 13.