Guest

Cisco Unified MeetingPlace

Field Notice: FA00142 - Conference Allocation Leak


May 26, 2004


Products Affected

Product

Comments

MeetingPlace Server

Earlier than 4.3.0m

Problem Description

Note: This Field Notice is a legacy Latitude Field Notice that has been converted to the Cisco format so the information would remain available to their customers.

After a meeting has ended, if parameters for that meeting are modified through MeetingTime client on two separate occasions, a major alarm will be generated.

08/14 13:35:28 MAJ 0x20078 The CS is behind 826578 seconds. Conf 8991, Next Event 21, Time 996994740

Explanations:

The alarm is generated for a conference with ID of 8991. This is not the regular meeting ID that you think of; this is an MP server internal unique meeting ID. It is in decimal format, so its hex equivalent = 0x231f.

mtgplace:csc$ cptrace -C -c 0x231f

08/14 13:35:29.71 C 231f Purged : Result 0
08/14 13:35:26.40 C 231f New Purge: Result 0, Date 08/04 23:59:00
08/14 13:35:11.14 C 231f New Purge: Result 0, Date 01/01 09:39:00
08/14 13:34:47.37 C 231f Purged : Result 0
08/14 13:34:37.24 C 231f New Purge: Result 0, Date 08/04 23:59:00
08/14 13:34:28.66 C 231f New Purge: Result 0, Date 01/01 09:39:00
08/14 13:31:03.64 C 231f Purged : Result 0
08/14 13:30:55.98 C 231f New Purge: Result 0, Date 08/04 23:59:00
08/14 13:30:35.92 C 231f New Purge: Result 0, Date 01/01 09:39:00

08/04 11:17:33.87 C 231f Purged : Result 0

07/05 10:02:37.54 C 231f Stop Recording: Port 255, Result 0
[deleted for brevity]
07/05 08:58:50.20 C 231f Start Recording: Port 255, Result 0
07/05 08:58:50.19 C 231f ADD Part Part 1 User 3 Ability 27 Result 0

The meeting ended 7/5, and the recording was purged on 8/4. This is based on your "# of days to retain" parameter in MeetingTime. So MeetingNotes are kept for about 30 days after meeting is over.

Then on 8/14, someone, using MeetingTime, changed some of the parameter of this meeting. You can do so from Review button, and change those parameters that are not italicized.

The first time you change it, it will set a new purge date based on the formula: end date of meeting + days until meeting stats are purged.

Then when you change some parameter again, the purge date gets changed to the date of: end date of meeting + # of days to retain.

But remember, end date of meeting + # of days to retain = 8/4, but today is already 8/14 at the time of someone changing the parameters in MeetingTime.

So on 8/14, when MP server gets a new purge date because of someone making repeated changes to meeting parameters in the Review tab about its needing to purge meeting conf 8991, it cannot do so because the purge date is 8/4, way past. That's why it generated the alarm, saying server is how many seconds behind some operation that it is told to perform.

If you convert the time 996994740 in the alarm, it represents August 4.

This particular alarm can also occur if MeetingPlace Conference Server is down, and during this period of down time, purge events are scheduled to occur for some meetings. When the Conference Server is brought back online and the server tries to execute those scheduled events, it will complain that CS is behind xxx seconds. Under this scenario, the generation of these alarms is normal and software is functioning as designed.

Problem Symptoms

This defect does not interfere with normal system operation.

Workaround/Solution

Defect fixed in MeetingPlace Server version 4.3.0m and higher

For More Information

If you require further assistance, or if you have any further questions regarding this field notice, please contact the Cisco Systems Technical Assistance Center (TAC) by one of the following methods:

Receive Email Notification For New Field Notices

Product Alert Tool - Set up a profile to receive email updates about reliability, safety, network security, and end-of-sale issues for the Cisco products you specify.