Troubleshooting the failed event manager

This topic discusses problems that you can encounter while using the failed event manager.

Note: This topic does not discuss how to use the failed event manager to find, modify, resubmit, or delete failed events on the system. For information about managing failed events, see Working with failed events in IBM Business Automation Workflow. Additional information is found in the topic Collect troubleshooting data for the failed-event resolution problems in WebSphere Process Server.

Select the problem you are experiencing from the following table:

Problem	Refer to the following
I am having trouble entering values in the Search page's By Date tab	Values in the By Date and From Date field automatically change to default if entered incorrectly
I am having trouble deleting expired events	Using the Delete Expired Events function appears to suspend the failed event manager
I am having trouble with failed events not being created	Failed events are not being created
I am having trouble retrieving or deleting large numbers of failed events	The server fails when retrieving or deleting large numbers of failed events
I am having trouble clearing a large number of failed events	The server fails when clearing a large number of failed events
I am having trouble deleting failed events after the associated application was uninstalled	Deletion of failed events after uninstalling the associated application

Values in the By Date and From Date field automatically change to default if entered incorrectly

The Search page's From Date and To Date fields require correctly formatted locale-dependent values. Any inconsistency in the value's format (for example, including four digits in the year instead of 2, or omitting the time) will cause the failed event manager to issue the following warning and substitute a default value in the field:

CWMAN0017E: The date entered could not be parsed correctly: your_incorrectly_formatted_date. Date: default_date is being used.

The default value of the From Date field is defined as January 1, 1970, 00:00:00 GMT.

Important: The actual default value shown in your failed event manager implementation will vary depending on your locale and time zone. For example, the From Date field defaults to 12/31/69 7:00 PM for a workstation with an en_US locale in the Eastern Standard Time (EST) time zone.

The default value for the To Date field is always the current date and time, formatted for your locale and time zone.

To avoid this problem, always enter your dates and times carefully, following the example provided with each field.

Using the Delete Expired Events function appears to suspend the failed event manager

If you use the Delete Expired Events button in situations where there are many failed events in the current search results, or where those events contain a large amount of business data, the failed event manager can appear to be suspended indefinitely.

In this situation, the failed event manager is not suspended: it is working through the large data set, and will refresh the results set as soon as the command completes.

Failed events are not being created

If the Recovery subsystem is not creating failed events, go through the following checklist of potential causes:

Ensure that the wpsFEMgr application is running. If necessary, restart it.
Ensure that the failed event manager's database has been created, and that the connection has been tested.
Ensure that the necessary failed event destination has been created on the SCA system bus. There should be one failed event destination for each deployment target.
Ensure that the Quality of Service (QoS) Reliability qualifier has been set to Assured for any Service Component Architecture (SCA) implementation, interface, or partner reference that participates in events you want the Recovery service to handle.

The server fails when retrieving or deleting large numbers of failed events

The server can fail if you use the failed event manager to retrieve or delete a large number of failed events at once. To prevent this problem, be sure to check the total failed event count on the main page of the failed event manager before performing search or delete actions. If you have a large number of events, do not try to retrieve or delete all of them at once. Instead, use the Search failed events option to return a subset of failed events that match specific criteria. You can then delete all of the events in the filtered result set without causing a server failure.

Note: There are several factors in your environment that can affect the number of failed events the server can return or delete in a single request, including other processes running on the same machine as the server and the amount of available memory.

The server fails when clearing a large number of failed events

The server can fail if you try to clear a large number of failed events using the Clear All option. To prevent this from happening, set a limit for the number of failed events that can be cleared using the JVM property failedEventLimit. If the failed event count is higher than that limit, the Clear All option returns an error, and you must delete the failed events (up to the limit specified) one at a time.

Deletion of failed events after uninstalling the associated application

After the application that is associated with a number of failed events is uninstalled, you can no longer delete the failed events by using the failed event manager. The failed event manager is unable to load the failed event details because it cannot find the application definition, related queue, and the message-related data objects. In this case, you can use the following tables in the common database to identify and manually remove the failed events:

FAILEDEVENTBOTYPES
FAILEDEVENTDETAIL
FAILEDEVENTMESSAGE
FAILEDEVENTS

Identify the failed event messages to be deleted in the APPLICATIONNAME column of the FAILEDEVENTDETAIL table. Use the MSGID value to correlate the identified messages in all the tables, and then delete all the related records from all the specified tables.