On Wed, Jan 26, 2000 at 03:02:46PM +0100, [EMAIL PROTECTED] wrote:
> > Inactivity watchers are similar to idle watchers. The difference is
> > that they judge idleness by whether there have been any events with
> > priority higher than the threshold level, where the threshold level is
> > a configurable attribute.
>
> Hm, so the difference is the configurable threshold level ... this is useful but in
>my
> current application the used idle watchers have to have the lowest priority, so I
>think
> there would be no difference, am I right?
Oh OK. Actually, I haven't heard of anyone using inactivity watchers.
Maybe they should watch a group of watchers instead of event
priorities...
> > It sounds like your events stay queued long enough that priority
> > matters. That's pretty strange.
>
> Hm, if priority doesn't matter, what is it for? ;-)
I think it is a good time to say, "On the other hand ..." :-)
> > Do you set the min & max attributes?
>
> Yes. Decreasing these attributes really helps until you start even more clients to
>stress
> the server ... so at a certain point, they cannot be decreased more and the load
>problem
> occurs again. I wish to construct a robust framework which can handle almost any
> reasonable frequency of client requests. (Surely my algorithm is not perfect yet ...)
Hm.
> > Have you watched the
> > event processing with NetServer::ProcessTop?
>
> Ah - I did not know this module. That's a pitty because it is really powerful.
>Great! I
> will immediately check my server.
>
> Just a few impressions of a first time user:
Wow! Lots of great suggestions--
> could the number of screen lines be controlled? As well as the length of
>descriptions displayed?
I wish I could auto-detect it. I spent some time trying to figure it
out but it seems impossible. At least I can add manual override.
> import() should be documented
> - I choosed to "use" the module and got two servers! (In fact, I did not because they
> picked up the same port by default and caused bind() to fail.)
Done.
> The regexp feature is
> really useful but does not work for "/." (tried to reset the default).
>"/interface|idle"
> is not accepted as well
It is restricted to alphanumerics. I don't want to allow fancy stuff
like (?{ ... }). Does anyone know what is reasonable to allow in a REx?
> ... The "t" control accepts only certain values (e.g. second value
> 100 becomes 120, 150 becomes 180, but 54 and 39 work ...).
Yah, that's just how the stats are collected.
> There are three load averages, each standing for ...?
15sec, 1min, 15min. I'll update the docs.
> The command line should be restored after a screen refresh for
> someone typing a longer command or regexp ...
That's a side effect of using telnet as the client. I don't know of a
work-around.
> Again, I think this cool extension will be a real help and is worth to be mentioned
>more
> detailed in Events documentation!
It is mentioned, but I will mention it more prominently.
> I suggest to include the stats and top modules into the Event package.
I'm still waiting for Graham Barr to forgive me for writing it in the
first place. ;-)
> > ASYNC 0 1 2 3 4 5 6 7 8 9 IDLE
> > HIGH NORM
>
> Hm, means IDLE a state for its own (like ASYNC, current doc: "-1 is the highest
>priority
> and 6 is the lowest")?
Oh, I just put IDLE there because it is lower than all other priorities.
The lowest priority is 9 (on the chart above).
> Nevertheless, these are about 10 levels so I think this should do. Honestly spoken,
>the
> idle split is not completed yet so I'm not absolutely sure. But I think it should
>work
> (for me (now)).
Hm. I don't want to change anything until you are sure you need it...
--
"Does `competition' have an abstract purpose?"
via, but not speaking for Deutsche Bank
