Question
Mphasis
US
Last activity: 3 Dec 2015 11:06 EST
Thread Dump Starts for reportProcessHandles - What Does This LOG Entry Imply?
Hi,
In our PEGARules.LOG, we are seeing a random entry stating with the one mentioned in subject line, numerous times and not sure what exactly the source is (A detailed LOG is attached along with). Please note that we have numerous CTI Link Engines in our application and some of these name are mentioned in LOG entries such as
Thread id 145389:CTI-CISCO_XXXXX-ACD-SocketHandler ***
XXXXX Representing the CTI Link Engine Name.
Is there a settings change required for eliminating these entries as otherwise these are taking up huge disk space. We are using PPRC 7.1.8 with PegaCALL Proprietary information hidden for our application.
Thanks.
-
Like (0)
-
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Accepted Solution
Mphasis
US
The SystemCleaner agent was not running, thereby causing the issue. It is fixed now. We had to restart the SystemCleaner Agent and make it run a minute after midnight everyday. If you run it on midnight, it will fail and that's what was happening in this case.
Pegasystems Inc.
US
The logs you mentioned appears to be triggered by an earlier FileNotFoundException:
15-10-13 12:02:48,468 [.PRPCWorkManager : 7] [ STANDARD] [ ] [ PegaRULES:07.10] ( fs.direct.FilesystemStorage) WARN - FileNotFoundException, calling reportProcessHandles
java.io.FileNotFoundException: /websoft/IBMWebAS/profiles/profileServer/temp/xwasasdm1p/cl_app090_prod_xwasasdm1p/prpc_j2ee14_ws_prod/prweb.war/PassivationData/6/HF8B1B4DA298DC5DF3646C1D77F556E66/metadata.ser (No such file or directory)
at java.io.FileOutputStream.open(Native Method)
at java.io.FileOutputStream.<init>(FileOutputStream.java:233)
at java.io.FileOutputStream.<init>(FileOutputStream.java:183)
at com.pega.pegarules.storage.fs.direct.FilesystemStorage._getOutputStream_privact(FilesystemStorage.java:363)
This can happen when someone accidentally deletes the PassivationData directory. I do not see any switch that the mentioned logs can be turned off. So I would suggest fix the FileNotFoundException first.
Mphasis
US
Thanks, I will check that and get back to you.
Mphasis
US
Hi Kevin,
I have a few questions, what does this "HF8B1B4DA298DC5DF3646C1D77F556E66" denote? It seems that this folder name is not same across all PEGA installations as this folder doesn't exist in QA and it never throws this error. It is not present in PROD either, however, it is still searching for HF8B1B4DA298DC5DF3646C1D77F556E66, can this be configured? I am currently trying to check where metadata.ser file is located.
Pegasystems Inc.
US
that is a browser requestor id. Use SMA to see if that is there.
Mphasis
US
Thanks, but, I am not sure exactly where to look in SMA.
Updated: 14 Oct 2015 13:24 EDT
Pegasystems Inc.
US
Mphasis
US
I think I knew this, but, probably didn't understand.
All right, so I verified and it seems PassivationData folder is present where it should be. However, these requestor IDs are not present in the sub folders A, B, C, 0 etc. What can cause this? Nothing changed in PRPC, code wise, even if it did, I don't think code change can cause this problem. What do you think?
Pegasystems Inc.
US
You mean the directory does exist /websoft/IBMWebAS/profiles/profileServer/temp/xwasasdm1p/cl_app090_prod_xwasasdm1p/prpc_j2ee14_ws_prod/prweb.war/PassivationData/6/HF8B1B4DA298DC5DF3646C1D
And yet the requestor is not found from SMA?
Mphasis
US
Hi Kevin,
It's actually the other way round. Say requester "XXXXX" is present in SMA, however, that is not present here: /websoft/IBMWebAS/profiles/profileServer/temp/xwasasdm1p/cl_app090_prod_xwasasdm1p/prpc_j2ee14_ws_prod/prweb.war/PassivationData/6 or any other sub folder of PassivationData such as 0,1,2,3,D,E etc.
Thanks.
Pegasystems Inc.
US
that is strange, is this happening for all requestors or just sporadically? check the file permission for the directory regarding the user starting prpc. Maybe somehow the system admin starts the prpc instance in a OS user that does not have the permission to write out files under the directory.
Mphasis
US
It's unlikely to happen as it worked earlier, but I will still check to see if anything related to write permission changed for that folder.
Mphasis
US
Hi Kevin,
Nothing changed related to permission. Is that possible that something was changed within PRPC, some access role or system settings?
Pegasystems Inc.
US
Not aware of such things. Is this always happening or just sporadically? When it happens is it for many requestors?
Mphasis
US
For some, actually. For example, when I log in, I can see entries related to my operator ID.
Accepted Solution
Mphasis
US
The SystemCleaner agent was not running, thereby causing the issue. It is fixed now. We had to restart the SystemCleaner Agent and make it run a minute after midnight everyday. If you run it on midnight, it will fail and that's what was happening in this case.