Troubleshooting
Problem
Symptom
Cause
This is how getJobs in an agent works - Agent is triggered (manually through triggeragent.sh or automatically)
•getJobs (trigger) message is posted to JMS queue by agent trigger
•getJobs() method reads the above message
•Within getJobs() method, agent tries to acquire lock on YFS_OBJECT_LOCK table for agent Criteria ID
•If lock is not available then getJobs() method exits and does nothing.
•If lock is available then getJobs() method fetches records which needs to be processed.
•Above records are posted as execute message to JMS queue
•After the execute messages, one getJobs message is also posted with last record key.
•execute method picks execute message one by one and processes them.
•After all the execute messages are consumed then only getJobs message is left in queue
•getJobs() method picks up the getJobs message left in the queue.
When a getJobs returns 0 messages, the next batch of getJobs fires the query with NOWAIT , since the agent was idle and would indeed need the row lock on yfs_object_lock table to gather records for processing. As long as getJobs retreives a set of messages, the for update query is fired without NOWAIT , so that the agent does not go idle.
Diagnosing The Problem
Consider multiple instances of an agent being run - says two instances with 5 threads each.
(Thread 1-5 in Instance 1 and thread 6-10 in Instance 2)
Lets say that the buffer size is 100 and there are 600 jobs to be obtained
When the agents start, both the instances have getJobs fired with NOWAIT, one of the threads gets the lock and the rest of the threads process the messages. It is imperative that getJobs is fired with NOWAIT here so that only one thread is engaged in getJobs while the rest of the threads process. In the first run 100 messages are obtained
When one of the threads reaches the last record key, it fires getJobs without NO WAIT
The getJobs is fired only when a lock is obtained. This is done to ensure that getJobs is run as soon as a lock is obtained.
Lets say thread 1 processes the last record key and fires the object lock query with wait, it gets the lock and immediately starts putting in messages.
The rest of the threads process these messages. But the processing rate is fast, lets say thread 2 now encounters the last record key but thread 1 has just about completed the getJobs and still not given up the lock from the getJobs. Here thread 2 has no work to do, hence it waits to get the lock so that it can commence the getJobs as soon as it gets the lock. If it were fired with NOWAIT, the agent will need to wait until the next getJobs to get messages that can be processed currently.This continues until the getJobs returns 0 jobs.This is necessary to ensure that the agent does not go idle when it has messages to be processed.
After this the agent goes idle. The next job commences when the trigger interval is reached or it is auto triggered. Here getting lock on the object_lock table is fired with no lock so that the other threads so not wait for the lock and start consuming the messages.
Resolving The Problem
Related Information
Document Location
Worldwide
Was this topic helpful?
Document Information
Modified date:
01 November 2021
UID
ibm11086789