[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

6404.0. "Can't enable Collector sinks - Help!" by STKHLM::BERGGREN (Nils Berggren,DC Sweden 876-8287) Mon Nov 13 1995 10:21

Hi all

I'm having a problem with the DataCollector sinks, I can't enable them.

Environment:	VMS 6.1
		DECnet/OSI for OpenVMS Version V5.8-ECO2
		Namespace Selection = DECdns
		MCC Version = V1.3.0


MCC> ENABLE MCC 0 COLLECTION_AM SINK UDPIP

MCC 0 COLLECTION_AM SINK UDPIP
AT 13-NOV-1995 09:59:35

The requested operation cannot be completed
                  Entity Existence Info = Entity Existence Cannot Be Determined,
                      MCC Routine Error = %MCC-S-COMMON_EXCEPTIO, success with
                                          common exception reply



Same response when trying to enable the DECnet-sink.

I've re-enrolled the MCC_COLLECTION_AM  successfully, but that doesn't help.


Looking in the logfile at the end, I se the following:
-------------------------------------------------------------------------------
13-NOV-1995 09:20:51.36, Received COLLECTOR message over UDP/IP
>>Error sending event #3 to MCC event manager, INSEVTPOOLMEM, 13-NOV-1995 09:20:56.47
13-NOV-1995 09:21:37.53, Received COLLECTOR message over UDP/IP
>>Error sending event #3 to MCC event manager, INSEVTPOOLMEM, 13-NOV-1995 09:21:42.70
13-NOV-1995 09:22:23.74, Received COLLECTOR message over UDP/IP
>>Error sending event #3 to MCC event manager, INSEVTPOOLMEM, 13-NOV-1995 09:22:28.85
13-NOV-1995 09:30:50.53, Received COLLECTOR message over UDP/IP
>>Error sending event #3 to MCC event manager, INSEVTPOOLMEM, 13-NOV-1995 09:30:55.70
13-NOV-1995 09:31:36.72, Received COLLECTOR message over UDP/IP
>>Error sending event #3 to MCC event manager, INSEVTPOOLMEM, 13-NOV-1995 09:31:41.84
>> Error waiting for internal event, at step 5, status = 52877426, 13-NOV-1995 09:32:03.56
13-NOV-1995 09:32:03.59, Terminating sink management thread
13-NOV-1995 09:32:03.76, Terminating COLLECTOR sink management thread,status = 52877426
13-NOV-1995 09:32:03.91, Event process thread received MCC_S_ALERT_TERMREQ
13-NOV-1995 09:32:03.91, Terminating COLLECTOR event sink
%MCC-E-EVENT_LOST, events matching the request were lost
  SYSTEM       job terminated at 13-NOV-1995 09:32:07.26

  Accounting information:
  Buffered I/O count:          657891         Peak working set size:   31631
  Direct I/O count:            114609         Peak page file size:     80060
  Page faults:                  79211         Mounted volumes:             0
  Charged CPU time:           0 00:51:56.37   Elapsed time:    22 22:19:32.07
-------------------------------------------------------------------------------

It terminated today, but the 'INSEVTPOOLMEM'-message goes back several days...

I guess the INSEVTPOOLMEM is the acronym for 'INSufficient EVent POOL MEMory'?

What can I do about this?  Is there a way to 'free up' the event-pool?

How come I get this; I mean, the contents in the event-pool should be 
dynamic;  it's not normal to have a full event-pool for several days...?


	thanks,

	/Nils
T.RTitleUserPersonal
Name
DateLines
6404.1AZUR::DURIFMon Nov 13 1995 11:2723
Hi Nils,

> Is there a way to 'free up' the event-pool?
There is no way i know to free the event pool.
I mean this feature is not designed in MCC.

> it's not normal to have a full event-pool for several days...?
I agree with you.
Events stay in the event pool only if some GETEVENT request wait for the event.

If no getevent entity is pending the event pool may be empty.

>I guess the INSEVTPOOLMEM is the acronym for 'INSufficient EVent POOL MEMory'?
You are right.
I experienced this situation when burst of events were coming.
What happens in this case is that GETEVENTS are too slow to process events
so the event pool gets full.

If such a situation occured it may explain the death of the sink.

Hope this helps,

Benoit