|
Let's numerate your problems:
- #1 - "the last successful poll was a few hour or a day before no
fails poll since";
- #2 - "from time to time we get fails pool with SCHEDULE TIME PASSED".
Problem #2 happens when the system is busy and there is
no time to start the polling operation in time (the "in time" window is
about 5 seconds). It can be if at the time of the current poll your
system is doing other MCC actions, for example, a lot of alarms or
exportings. Or it can be because of other activities in your system.
Or it can be because the background restart procedure forces many
recordings to start simultaneously ( see details about restart procedure
at the and of this reply).
The problem #2 is more difficult to understand and I need your
answers on the following questions:
1. How many recordings do you have for each domain?
2. Does situation #1 happen in all domains or only
in one of them? How many recordings are in this domain(s)?
3. Do you have at least one successful pool (close to the current time)
for any other recording in the domain with problem #1?
4. Did you restart the background process for the domain(s) with
problem #1? If you did, did you specify a second argument to
the background?
5. What other MCC activities do you have? Alarms,exportings (how many?).
6. Is it possible to send me (took::shmuylovich) the result of
show recording for the domain with the problem #1? Please, send me
the result for as many recorded entities as you can. It may give
an idea what is going on.
Before I receive your answers I can see the only explanation for
the problem #1. This is the background procedure restart without
second argument and a big number of active recordings.
The second argument to the background procedure is a delay (in seconds)
between restarting of a recordings. If for example, the delay is 10 sec
the first recording restarts (makes a poll) immediately , the second
recording in 10 seconds and so on. If the delay argument is not
specified the default ( 30 seconds) is used. Please note that if you
have 100 recordings and you are using a default delay the last recording
starts in about 50 minutes after the background procedure starts! If you
do Show Recording during this 50 min it shows "last successful poll"
from previous session of the background.
Is it possible that this is your situation?
If yes and a default delay is not acceptable for you, try to specify
smaller delay.
Why in V1.2 we introduced the delay argument? This is done to prevent
the system overload when all recordings start immediately (of course,
you can specify delay = 0).
Hope this helps,
Sam Shmuylovich
|