Time taken by secondary TMUSREVT to remove dead entries

Question

Background -
We used to have a huge number of dead entries in our TMUSREVT.DAT (Tuxedo Version: 8.1.362), which were caused by timeouts on the WSL. These were never getting cleaned out and the file size kept growing.
Based on the response to this tmusrevt.dat - dead entries do not seem to be removed. we started a secondary TMUSREVT (with the -S option) and we have a working solution.
Problem -
However, the amount of time it takes before deleting the dead entries varies a lot - sometimes 20 minutes and sometimes 2+ hours.
Is there any documentation that says when the secondary TMUSREVT will remove the dead entries? I was hoping it would be the -p option in the CLOPT of the TMUSREVT, but that did not seem to have any effect on the time taken to clean out dead entries.
So, the question is - When will the secondary TMUSREVT remove the dead entries? Is the time taken inversely proportional to how busy the environment is?
Edited by: Arvind Ramanan on Feb 11, 2011 11:38 AM
Edited by: Arvind Ramanan on Feb 11, 2011 2:07 PM

Answer 1

From Oracle Doc ID 1057214.1
The -p option is configured differently for primary and secondary servers.
For primary TMUSREVT, -p means polling interval for garbage collection of unnecessary entries.
For secondary TMUSREVT, -p means polling interval when the secondary server polls the primary server for changes to tmusrevt.dat and updates its local control file if necessary. At -p inverval, the secondary server will do a tpcall() to get new data from the primary server.
So if -p of secondary TMUSEREVT is big, a subscriber can't get the post message if it sees old data in the control file and it subscribes before the polling interval.
The polling time (-p option) for secondary TMUSREVT depends on your application requirement.
1)client calls tpsubsribe("event1",...);
2)TMUSREVT(primary) adds event in tmusrevt.dat
3)TMUSREVT(secondary) gets latest tmusrevt.dat "-p" interval.
When any process calls tppost() for "event1", if it calls the secondary TMUSREVT (usually after the primary is booted) between steps in 2) and 3), the client in 1) can't get post message because the event database (tmusrevt.dat) of secondary TMUSREVT is old.
So, consider the above scenario when setting the -p option of the secondary TMUSREVT.
The recommendation is to set a small value for the -p option in the secondary TMUSREVT if it uses the secondary TMUSREVT.
The other thing you need to be cautious about is the size of tmusrevt.dat. If tmusrevt.dat is very big, it affects both system resources and performance.
For example, if the client calls tpsubscribe() and if it does not call() tpunsubcribe before the process exits, it will increase the size of tmusrevt.dat because garbage collection of primary servers can delete only two entries at one interval. If many clients call tpsubscribe() and do not call tpunsubscribe() before exiting, many garbled entries will remain in tmusrevt.dat. Also, use of TPEVPERSIST causes entries to remain in the tmusrevt.dat file.
To keep the tmusrevt.dat file small, call tpunsubscribe() when the event is not necessary. If the size is large then it causes TMUSREVT to consume many CPU cycles .
A size of 100K should be okay for tmusrevt.dat.
Hope this answers your question.
-Venkat