Following are descriptions of the remote procedure call (RPC) and error
counters output by the loadstatus command.
This counter |
Counts |
Executed Steps
|
The number of steps completed.
|
External RPCs
|
The number of RPCs that come only from the client.
|
Internal RPCs
|
The number of RPCs that come only from another Process Engine.
|
Java RMI Requests
|
The number of Java API calls that have been processed.
|
Object
Service RPCs
|
The number of RPCs that come from Process Engines
and clients, and are used to read objects (such as work
classes, work
performer classes, or instruction
sheets) that are contained in BLOb format.
|
Work Object Inject RPCs
|
The number of calls to the work item inject (create) RPC.
|
Queue Query RPCs
|
The number of calls to the queue query RPCs.
|
Roster Query RPCs
|
The number of calls to the roster query RPCs.
|
Lock Work Object RPCs
|
The number of calls to the lock work item RPC.
|
Update Work Object RPCs
|
The number of calls to the update (or dispatch) Work Object RPCs.
|
This counter |
Counts |
Lock work object errors
|
The number of times an attempt has been made to lock a work item,
and that attempt has failed because the work item was already locked,
did not exist, or had been updated since the query was done.
If this counter increments excessively, try changing the work performers
so that they browse and lock in the same API call (use the "query
specifier" APIs), instead of reading the work item in one API
call and locking it in another. See the Help for Process Java API
for further information.
|
Email notification errors
|
The number of errors that have occurred while attempting to send
an email notification.
|
Move work objects duplicates errors
|
The number of times an attempt has been made to put a work item
into a queue on a different Process Engine,
but the work item already existed on that queue. This error occurs
occasionally during normal operation if a work item repeatedly moves
between two queues on different Process Engines.
This error occurs rapidly if:
-
the databases get out of sync because a database restore was
done on one or more Process Engines
without running the vwverify utility or
-
someone uses a low-level database tool such as Oracle SQL*Plus
or Microsoft SQL Server isql and modifies the database incorrectly.
Note that using a low-level database tool to remove the "system
locked" status of a work item causes this error.
If this error occurs excessively, run the vwverify
utility.
|
Move work object to new server errors
|
The number of times an attempt has been made to put a work item
into a queue on a different Process Engine,
but the Process Engine
or database was unavailable.
If this error occurs frequently, check that all Process Engines
are up and the Process Engine
software is running on all servers. Fix any errors reported in the
system error logs. See the for more information about event logs.
|
Transaction deadlock errors
|
The number of times a database transaction has been aborted and
retried due to a database deadlock error.
If this error occurs excessively, report this condition to FileNet
engineering. There is no field remedy for excessive occurrences
of this error.
|
Timer manager update errors
|
The number of times the timer software tried to time out a work
item, but was unable to do so because the work item was locked or
missing. This error occurs occasionally during normal operation
when the timer software and a user-defined work performer try to
access a work item at the same time.
If this error occurs excessively, try restructuring your workflow
so that work items do not time out as frequently while they are
locked.
|
Work objects skipped due to security errors
|
The number of times a work item was omitted from the results of
a query because the caller did not have read or write access. Excessive
numbers of these errors result in lower performance because the
Process Engine
is reading significantly more data than is being returned to the
user. This error occurs under the following circumstances:
-
A record is read from the event log, but the user does not
have read access as defined in the work class corresponding
to the event log.
-
A record is read from a queue, but the user does not have read
or write access as defined in the work class corresponding to
the work item.
-
A record is read from the roster, but the user does not have
read access as defined in the work class corresponding to the
roster record.
If this error happens excessively, try allowing more access to
work object data via the work class, and possibly restricting access
to the work item data via security on queues or rosters.
|