avalon-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From blorit...@apache.org
Subject cvs commit: jakarta-avalon-excalibur/event/src/xdocs mpool.xml menu.xml
Date Wed, 25 Sep 2002 21:20:38 GMT
bloritsch    2002/09/25 14:20:38

  Modified:    event/src/xdocs menu.xml
  Added:       event/src/xdocs mpool.xml
  Add docs for MPool
  Revision  Changes    Path
  1.4       +2 -2      jakarta-avalon-excalibur/event/src/xdocs/menu.xml
  Index: menu.xml
  RCS file: /home/cvs/jakarta-avalon-excalibur/event/src/xdocs/menu.xml,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- menu.xml	25 Sep 2002 20:03:56 -0000	1.3
  +++ menu.xml	25 Sep 2002 21:20:38 -0000	1.4
  @@ -13,8 +13,8 @@
       <menu name="Overview">
         <item href="event.html" name="Event"/>
         <item href="command.html" name="Command"/>
  - <!--     <item href="mpool.html" name="MPool"/>
  -      <item href="thread.html" name="Thread"/>
  +      <item href="mpool.html" name="MPool"/>
  + <!--     <item href="thread.html" name="Thread"/>
         <item href="util.html" name="Util"/>    -->
  1.1                  jakarta-avalon-excalibur/event/src/xdocs/mpool.xml
  Index: mpool.xml
  <?xml version="1.0"?>
      <title>Excalibur Event - MPool (Managed Pool)</title>
        <person name="Berin Loritsch" email="bloritsch@apache.org"/>
      <s1 title="Why MPool Was Created">
          MPool (Managed Pool) was created as an experiment in dynamic
          pool management.  The theory is that by determining whether to
          shrink or grow a pool can be a costly endeavor.  That is
          especially true when you want to play with "intelligent" pools.
          What we observed after we used MPool in practice is that under
          load, pool sizing algorithms begin to choke the efficiency of
          the pool.  In fact, it can get so bad that it would be better
          not to have a pool at all.  An unbounded pool (one that does
          not shrink) is a resource hog, especially during inactive times.
          By moving the pool sizing logic into an asyncronous Command,
          we were able to achieve the efficiency of an unbounded pool
          while keeping an eye on pool size.  During times of inactivity
          we destroy pooled objects that we don't need.  During times of
          stress, we create a new object immediately and in a background
          process we add new objects.
      <s1 title="When To Use MPool">
          Use MPool any time you need a pool without hard limits, and you
          expect heavy loads.  The pool size is checked periodically, so
          we don't incur extra overhead of having to check that while the
          pool size grows and shrinks.
      <s1 title="Core Concepts">
          MPool has two pool types: fixed size and variable size.  A fixed
          size pool is not managed externally.  There is a fixed limit to
          the number of resources it can manage so we don't have to manage
          it.  A variable sized pool is a managed pool.  A managed pool will
          be created by the PoolManager, and that manager will manage all
          of its pool sizes in the background.
        <s2 title="Object Factory">
            An Object Factory is what the pools use to create new objects
            or destroy old ones.  They are particularly helpful when there
            is a complex creation/destruction policy.  They are also essential
            for ManagablePools.
        <s2 title="Pool">
            The base Pool interface is how the client code interacts with
            the pool.  You acquire and release pooled objects from the
        <s2 title="Managable Pool">
            A Managable Pool is a special interface that allows a PoolManager
            to register itself with a "magic key" so that the managed pool
            only responds to the PoolManager responsible for it.
        <s2 title="Pool Manager">
            The Pool Manager is how you obtain a Managable Pool.  It also
            takes care of the management functions for that pool.
        Copyright (c) @year@ The Jakarta Apache Project All rights reserved.
        $Revision: 1.1 $ $Date: 2002/09/25 21:20:38 $

To unsubscribe, e-mail:   <mailto:avalon-cvs-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-cvs-help@jakarta.apache.org>

View raw message