The Client Request (CR) threads handle actions on the client that need to get or put data to or from the RmiServer. Some of the threads are for refresh while others get job data when editing a job or any other action submitted by the client. On some systems where a high volume of jobs are being submitted at one time, lots of users are logged in and doing things such as history filter queries, the client can become very slow to respond.
Troubleshooting
1) Enable RmiServer debugging and search for "elapsed ms" in the log.
2) Then search for the CR thread " CR".
3) If you find entries in the log for the Client Request thread (CR#) with a high elapsed time (anything over 30 seconds), this may indicate why the system is slow and you can take a look at what may be adding to the slowness by looking at what the CR threads are doing, see the example below.
Example
In an RmiServer debug log where a client thread was being used to process History Filter Queries that AM users are submitting from the so_job_history table that contained more than a million rows of data and where they were dumping a couple of thousand jobs into the backlog at the same time we saw that the Client Request thread was very slow (over 7 minutes (446226 ms) for one transaction). Here are some examples of the lines from the RmiServer debug logs:
In this particular case, our recommendation was to create Reports in Applications Manager to query the so_job_history table instead of doing History Filter Queries which because of other things they were doing at the same time caused their GUI to be extremely slow.