| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 4676.1 | Increase retries | CUJO::HILL | Dan Hill-Net.Mgt.-Customer Resident | Thu Mar 11 1993 14:50 | 11 |
| MCC> SHOW MCC 0 TCPIP_AM SINK ALL ATTRIB
Select the "<i_forgot_the_name_of_this> RETRIES" from 2 to 10. I think
there are two retry attributes. Be sure they are both 10.
If your system is very busy, the sink will timeout before it can get
its job done.
Let me know if this works for you.
-Dan
|
| 4676.2 | I think the retries aren't mattering | MUNICH::FERSTL | | Fri Mar 12 1993 02:58 | 29 |
| I've tested it with a value of "Sink Start Retries" = 10.
It had no effect.
But I think the retries aren't mattering.
The sink gets started properly (sink state is "running", and the
process "MCC_TCPIP_SINK" is there), so why should there be retries to
start it.
But after the unsuccessful enable of the notifications, I see that the
sink is running, but the client count is 0. According to the help
the clients are the getevent processes.
That means there is no getevent outstanding.
And this is what the error message says "events sink was started
successfully but is not currently communicating".
I think that the "enable notifications" has to set up internally
getevent requests. When there's no sink process running already,
it takes too long till it's activated and I think therefore the "enable
notifications" somehow times out and gets the error.
I also changed the "Sink Start Wait Timer", but without any success.
I analyzed the "MCC_TCPIP_SINK" process and saw a base priority of 0.
Could it be that the base priority is to low and the sink-process
therefore starts to slow?
Thanks Birgit
enabled properly.
|
| 4676.3 | | MOLAR::PERRY | | Tue Mar 16 1993 15:06 | 28 |
| Birgit,
The error message : "event sink was started successfully but is not
currently communicating" means that the SNMP AM successfully
created the SNMP AM event sink process, but that the AM couldn't
send the event sink a message through the event pool. This usually
occurs when either the event pool is corrupt or when there is a
timing problem between the SNMP AM and it's event sink.
This one sounds like a timing problem to me. Since you're able to issue a
show sink status command to the event sink and you get a successful
response (sink up, client count = 0), the problem isn't the event pool.
All sink management commands use the event pool and so these commands
would fail if you had an event pool problem.
If both the "Sink Start Wait Timer" and the "Sink Start Retries" are
set to 10, then the getevent requests will wait up to 100 seconds ( 10
retries times 10 seconds between these retries) to communicate with the
event sink before giving up. Normally, this should be plenty of time
for the SNMP event sink to initialize itself. Could something be
chewing-up all the CPU time on your system such that the event sink
isn't given adequate CPU time? Can you monitor the CPU utilization
(monitor/system) when you start your notification requests to see how
busy it is? I've only seen this problem on very busy systems and I am
wondering if this is the case.
Jim
|
| 4676.4 | Another case | HADRES::KRAUSE | European NewProductEngineer for MCC | Wed Mar 17 1993 06:00 | 12 |
| I got the same problem here on my CeBIT Demo System, a
VAXstation 4000-90 with 80MB memory, VMS 5.5-2, MCC T1.3.1. When
I start the Iconic Map SNMP Notification comes up ok (from the
init file). But when I select the SNMP notification request and
then do a disable and enable, it *always* fails. The workaround
is to post a getevent from the command line, then do the
disable/enable and then cancel the getevent. This keeps the sink
process running.
BTW: THere is plenty of CPU power left during the whole process.
*Robert
|