Understanding Asynchronous Service Operations Statuses
This section provides an overview of how to:
Processing statuses for asynchronous service operations.
Processing errors.
Blocked queues and processing statuses.
Stalled queues and processing statuses.
For asynchronous service operations, the Service Operations Monitor displays different statuses as service operations progress through the system.
The typical status progression for asynchronous service operations is:
New.
Started.
Working.
Done.
However, the Service Operations Monitor can display any of the statuses listed in the following table.
|
Status |
Description |
|---|---|
|
Canceled. |
The item has been canceled. The system cannot process the item until you resubmit it. |
|
Done. |
This status indicates different outcomes, depending on the type of process that you are monitoring. For operation instances this status indicates that the operation instance has completed processing and that the publication or subscription contracts have been created. For publication contracts this status indicates that publication contract was successfully sent to the external system. This can include publications sent using guaranteed or best effort delivery. For subscription contracts the status indicates that the subscription notification processed successfully. |
|
Done NoAck. |
This status appears for publication contracts sent in Best Effort delivery mode and indicates that the publication contact was successfully sent, but no acknowledgement was received. |
|
Edited. |
The publication data for the item has been edited. Processing does not resume until you resubmit the item. |
|
Error. |
An error occurred during processing. Manual intervention is required. |
|
Hold. |
This field is used in conjunction with message segmentation and future-dated publications. The status of a segmented message is Hold while the system is processing the segments in the message. The status of a future-dated publication is Hold until the date and time specified to process the publication is reached. |
|
New. |
Either the item has been written to the database but has not been dispatched yet, or the item has just been resubmitted. |
|
Retry. |
The system encountered an intermittent error during processing. The system retries service operations with this status automatically. |
|
Started. |
The dispatcher is in the process of passing the item to a handler, but the handler has not received it yet. |
|
Submit. |
This status indicates that a process schedule instance has been created for the transaction. |
|
Timeout. |
The system has reached the maximum retry count to send a service operation. |
|
Working. |
The handler has accepted the item and is currently processing it. |
The status for a service operation typically displays Error in the Service Operations Monitor when the system cannot create a publication or subscription contract or if there is some other framework error (for example a SQL error).
However, there are situations when the system displays a status of Done for an operation instance, publication contract, or subscription contract, yet also displays an Error link indicating that it encountered a problem during processing.
This can occur when:
Attempting to publish a service operation that contains segmented messages to a node that is not segment aware.
The routing on a publication contract is inactive.
There is no service operation handler for a subscription contract.
And so on.
The system sets the status for an operation instance, publication contract, or subscription contract to Done when it has successfully created the instance or contract. In each of the cases described in the list, the system encounters an error after it has evaluated the transaction and has successfully created the operation instance or contract. The system therefore displays an Error link that you can use to access the corresponding error message. The system does not send the service operation until the error is corrected.
The following table lists the pages where you can access an Error link should any of these situations occur:
|
Type |
Error Link Location |
|---|---|
|
Operation instance |
Asynchronous Services – Operation Instances page. ( and click the Operation Instances tab.) |
|
Publication contract |
Asynchronous Details page. (.) |
|
Subscription contract |
Asynchronous Details page. (.) |
Queues preserve the order in which service operations are processed.
The pub/sub system guarantees that items are processed in the order they are sent. If a service operation has a status of Error, Timeout, or Edited, the service operation queue becomes blocked and no processing occurs until you resolve the problem with the service operation.
For publications, queues are partitioned in queues by sub queues.
For publication contracts, queues are further partitioned into queues by sub queue and target node. If a queue is ordered, items in that queue and in the same queue are processed in the order sent. The dispatcher does not begin processing an item until all items ahead of it in the queue have the status Done or Cancelled. An item with a status of Error, Timeout, or Edited blocks all items behind it in the same queue. If the remote node is unavailable, the dispatcher does not attempt to process the contract and the queue is blocked until the remote node becomes available. That is why publication contracts are partitioned by target node.
If a queue is unordered, an item (such as the publication, publication contract, or subscription contract) never blocks another item. All items are processed in parallel.
Stalls do not occur by design. They are caused by gaps in functionality, user errors, defects, and so forth.
For example, a queue can become stalled when:
Multiple domains access the same database and one of the domains is shut down abnormally.
Items may be stalled in the Started or Working status.
Note: You can use the Domain Status page to correct the problem.
A change occurs to the pub/sub runtime tables through direct SQL.
The copies of the database tables that dispatchers have in memory are not updated. In this situation, you must reboot the dispatchers.