[RT] Intelligently Managed Systems

[Berin Loritsch <bl...@apache.org>]

Before I get into detail about this Random Thought, I do want put out a
disclaimer about the _type_ of management I am referring to.  I am not
referring to JMX type management, but more resource management.

In playing with a new "ManagedPool" structure, I started expanding my ideas
to all the different "Managers" we have in Excalibur.  Currently this includes
RoleManager, ComponentManager (and Selector), LogManager, PoolManager (still
in construction), ThreadManager (aka ThreadPool), and one I haven't written
yet to manage asynchronous commands.

There seems to be some similarities between them, and some key distinctions.
On my first pass, I observed that some "Managers" are Passive (like LogManager),
and some are Active (like ThreadManager will be).  However, this initial
distinction was superficial.  All the passive managers only manage relationships.
All the active managers manage resources.  This is an important distinction
to be made, as they address different needs.

The concept of a Relationship Manager is realized in its simplest form as a
java.util.Map.  We use these well in ExcaliburComponentManager to manage the
relationship of a shorthand name to a component instance.

The concept of a Resource Manager has yet to be realized, but has its beginnings
with the PoolController.  In order for a Resource Manager to do it's job
effectively, it must be able to operate asynchronously with the objects that
it is managing.  That way, it can poll the resources and implement a level of
intelligence to the system.

In fact, both the Resource Manager and Relationship Manager can use a bit of
intelligence to make the system easier to maintain.  Perhaps this has to do with
the fact that I have been studying up on intelligent systems, but I think it
applies here.  For instance, if a System has many pools, the same logic can
apply to all the pools.  The PoolManager would be able to understand the pools
state with it's "sensors" (i.e. pool size, frequency of use, etc.) and cause
changes with it's "affectors" (i.e. grow, shrink).

An intelligent PoolManager will be able to ascertain the cost of creating a
resource to place in the pool so that it can determine the optimal maximum grow
size for that pool.  Furthermore, it can determine the cost of destroying a
resource to remove from the pool so that it can determine the optimal maximum
shrink size for that pool.  In this manner, the interruptions caused by resource
creation or destruction do not interfere with the pool's normal use.  When you
add state to the PoolManager so that it can observe the pool's use over time,
it can go so far as to predict the necessary pool size for the time of day.
That way the number of pool hits increases, and pool misses decrease.

It is important to note as well that such an intelligent system would be
to costly to run in-line as the current PoolControllers do.  The logic for
the "agents" used to control resources are comparitively simple and finite.
You have three actions available to you ("grow", "shrink", and "do-nothing").
You have one sensor available ("size").  If more are required, then the
agent needs to be a "Profiler" and gain information about it's world through
the ProfilePoints.

In fact, in almost all actively managed or ResourceManager implementations,
the same logic can apply.  This makes the system much more interesting.  In
essence, we can have one autonomous agent able to manage all of the systems
resources.  The affects of the "grow" and "shrink" operations vary depending
on the resource being managed.  This will work for the PoolManager, the
ThreadManager, and a CacheManager.  These are three of the heaviest resource
consumers in a system.

Some managed systems don't quite work as well with that approach, such as
a CommandManager (In SEDA parlance, a Command Stage with a Command Queue)
operate by issuing asynchronous callback commands in a system.  Since those
commands are deposited by other Managers, this would be the backbone of the
system.  The CommandManager would _use_ a ThreadManager, so in essence the
"grow" command on a CommandManager would cause a "grow" command on the
ThreadManager.

Any system that is a RelationshipManager will periodically have to check if
it's relationships are still valid.  This means that a CongigurationManager
(one that monitors configuration files and converts to Configuration objects)
would be able to issue Commands to the CommandManager so that these relationship
managers can determine again if its relationships are still valid.

There can be a danger in exposing simple APIs like "grow" and "shrink" so that
any object can call it.  To that end, we have to determine how to safeguard
these contracts.  There are multiple ways: Java Security API and have a
SecurityManager installed, using System Unique Id's as keys, or blind
faith.  I don't admire blind faith at all.  This leaves two options left.
Unfortunately both require a little code in the managed object to determine
if the caller is allowed to excercise the method.  Java Security would have
a checkPermission() call.  The key method would have the managed object compare
the key passed in the method with the key given in the objects constructor.
The key approach is simple, quick, and not resource intensive at all.  It does
muddy the API a little, but the cost is small in that the Manager is the only
one who cares about the key anyway.  The Java Security approach is probably
more correct, but arguably more resource intensive.  We are talking about
calls that may be made on a continuous basis.

That last argument may be a moot point when you factor in the CommandManager.
The CommandManager can basically limit the number of times per period that
any command is called.  To this end, the SecurityManager approach would work
well (supposing it is installed).

-- 

"They that give up essential liberty to obtain a little temporary safety
  deserve neither liberty nor safety."
                 - Benjamin Franklin


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>