Troubleshooting
Problem
Work objects in a queue are being locked unexpectedly, or work objects are locked in a queue and cannot be processed by the user or code that normally processes the queue, or work objects are stuck in a Queue or Component Queue.
Symptom
Work objects in a queue are locked by an unexpected user.
Work objects enter a component queue and get locked by some user other than bootstrap user. The Component Manager is unable to process the work objects normally. The Component Manager is unable to recover and send the work objects to Conductor queue for possible retry.
Cause
The work objects may have been locked by a custom application. The PE Java API allows users to override locks held by other users. Overriding locks should be done sparingly, only in very special and limited circumstances, for example when the work cannot be unlocked by the original holder of the lock.
Below are the PE Java API methods that are issued from the client side and can override a lock
VWStepElement
VWWorkObject fetchWorkObject( boolean lock, boolean overrideLock )
public void doLock( boolean overrideLock ) throws VWException
public void doRefresh(boolean lock, boolean overrideLock )
VWWorkObject
public void refresh(boolean lock, boolean overrideLock )
public void doRefresh(boolean lock, boolean overrideLock )
public static VWException[] lockMany( VWWorkObject[] wobjs,boolean overrideLock)
public static VWException[] doLockMany( VWWorkObject[] wobjs,boolean overrideLock)
public void lock( boolean overrideLock ) throws VWException
public void doLock( boolean overrideLock ) throws VWException
public static VWException[] doDeleteMany( VWWorkObject[] elements, boolean overrideLock, boolean force)
public void doDelete(boolean overrideLock, boolean force) throws VWException
VWRosterElement
public VWWorkObject fetchWorkObject(boolean lock, boolean overrideLock )
public VWStepElement fetchStepElement(boolean lock, boolean overrideLock ) throws VWException
VWQueueElement
public VWWorkObject fetchWorkObject(boolean lock, boolean overrideLock )
public VWStepElement fetchStepElement(boolean lock, boolean overrideLock ) throws VWException
The above API calls can cause the following RPCs to be sent to the server and cause the server to override a lock
FileNet_PERPC::WorkObjectIdOrVWExeptionArray* orbRPC::orb_rpc_unlockSaveAndRedirect(
CORBA::Long orb_in_ViewId,
CORBA::Long orb_in_queryType,
CORBA::Long orb_in_saveType,
const FileNet_PERPC::WorkElementArray& orb_in_WorkElementArray,
const char* orb_in_mapName,
const char* orb_in_queueName,
const char* orb_in_exceptionDescription,
CORBA::Boolean orb_in_isExceptionMap,
CORBA::Boolean orb_in_unlockAll,
CORBA::Boolean orb_in_dispatchAll,
CORBA::Boolean orb_in_userBoundQuery,
const char* orb_in_domainName,
const char* orb_in_participantName,
FileNet_PERPC::RedirectType orb_in_doType)
Orb_rpc_getWorkElementFields rpc will lock and/or override the lock
FileNet_PERPC::WorkElementUnionArray* orbRPC::orb_rpc_getWorkElementFields(
CORBA::Long orb_in_ViewId,
FileNet_PERPC::TableType orb_in_queryType,
const FileNet_PERPC::WorkObjectIdArray& orb_in_WorkObjectId,
CORBA::Long orb_in_ResultType,
const char* orb_in_Msg,
CORBA::Boolean orb_in_Lock,
CORBA::Boolean orb_in_OverrideLock,
CORBA::Boolean orb_in_userBoundQuery,
CORBA::Long orb_in_queryFlag,
CORBA::Long orb_in_theCommand)
orbRPC::orb_rpc_deleteWorkObject will lock and/or override for a delete or terminate.
FileNet_PERPC::boolOrVWExeptionArray* orbRPC::orb_rpc_deleteWorkObject(
const FileNet_PERPC::WorkObjectIdArray& orb_in_WorkObjectIdArray,
CORBA::Long orb_in_viewId,
CORBA::Long orb_in_queryType,
CORBA::Boolean orb_in_terminateWob,
CORBA::Boolean orb_in_overrideLock,
CORBA::Boolean orb_in_throwException,
CORBA::Boolean orb_in_boundUserQuery)
Be aware that some applications automatically lock the work objects once they grab the work objects from the queue (for instance Navigator and BPF).
Diagnosing The Problem
Start with events in the VWLog table. Query all events belonging to the monitored work object with order by F_SeqNumber. Event 352 (WPWorkObjectQueued) is generated when the work object entered the queue. Event 350 (WPBeginService) is when work object gets locked. Two consecutive 350 events might suggest some user override the lock. F_TimeStamp will tell the time when work object got locked by F_LockUser.
There is a known problem with event 350 and the WSRequest component queue. Event 350 may not being generated correctly. Users are unable to rely on 350 event type to troubleshoot the lock override. This behavior is fixed, and event 350 should be recorded in the Event Log Table in 5.2.1.7 and later.
In order to find out who stole the lock, the PE trace with ISI, Component Manager, RPC options combined with vwtool/wobquery should be used. The RPC trace shows the lock user (who), the time (when), the client IP address issuing the RPC (where) and from what RPC (what). Users might need assistance with interpreting the traces, involve L2/L3 support if such assistance is needed.
Resolving The Problem
Normally custom applications should avoid overriding locks. Overriding locks can cause problems because the original holder of the lock is forced to handle the unexpected situation arising from the lock being stolen. As a common practice, only PE or P8 Admin should override locks and in that case the administrator should be aware of the consequences. Lock override should be used rarely, and in special circumstances, for example an employee leaves a company or goes on vacation and some work has been left locked but it cannot be unlocked by the original owner of the lock. Overriding lock should not be used as a normal programming practice.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg22001429