Hello,
> 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?
> 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 always thought of priority as a
> subtle way to fine-tune the system. I can't help but wonder if there is
> a more effective way to do what you want.
This would be fine, I agree.
> Are the idle watchers repeating?
Yes.
> 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 ...)
> Have you watched the
> event processing with NetServer::ProcessTop?
Ah - I did not know this module. That's a pitty because it is really powerfull. Great!
I
will immediately check my server.
Just a few impressions of a first time user: could the number of screen lines be
controlled? As well as the length of descriptions displayed? 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.) The regexp feature is
really useful but does not work for "/." (tried to reset the default).
"/interface|idle"
is not accepted as well ... The "t" control accepts only certain values (e.g. second
value
100 becomes 120, 150 becomes 180, but 54 and 39 work ...). There are three load
averages,
each standing for ...? The command line should be restored after a screen refresh for
someone typing a longer command or regexp ...
Again, I think this cool extension will be a real help and is worth to be mentioned
more
detailed in Events documentation!
I suggest to include the stats and top modules into the Event package.
> > To find a compromise - I think a number between 10 and 15 would be ok for now. It
> > may be increased again if necessary.
>
> Like this?
>
> 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")?
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)).
> > how about making this an installation parameter?
>
> That would cause trouble because many different unrelated modules need
> to be able to offer reasonable default priorities to their events.
> Changing the number of levels is akin to a major API change.
I see. Of course.
Jochen
