Though it was designed with Apache in mind, there are also subclasses for HTTP::Server::Simple and Net::Server, and it’s general enough to use with any server that has a pid file and listens on a port.

Features include:

• Checks server status via both pid file and port connect
• Detects and handles corrupt or out-of-date pid files
• Reports what is using a port when it is busy (via lsof)
• Tails the error log when server fails to start
• Supports sudo usage for restricted (< 1024) port
• Easy to customize for your environment with start/stop hooks, etc.

Coming soon: plugins for common tasks associated with starting and stopping servers, such as generating conf files from templates and auto-restarting a server on file change.

These are the solutions I know about:

1. Apache2::Reload / Module::Reload

These check whether modules have changed on each request, and if so, clear their symbols and reload them inside the process.

Problem: some modules fail to reload properly. Sometimes the failure is intermittent, depending on the order of module loading and other esoteric details. Moose and ORM modules seem particularly prone to reload failures. For me, this level of unpredictability makes *::Reload too frustrating to use.

2. Catalyst Auto-restart

Catalyst has an engine (Catalyst::Engine::HTTP::Prefork::Restarter) which forks off a “watcher” process that waits for your modules to change. When they change, it restarts the server. The usual effect is that, between the time you hit “save” in your editor and reload your page, the server has restarted or at least begun restarting.

Problems: Doesn’t work well if you make a few changes in a row; the restart only captures your first change. (EDIT: Dave Rolsky points out that this is fixed now under some OS’s.) Bad user experience if there’s an error in your module; you have to realize the server has died, find the error message in some shell or log, and manually start up the server again. Finally, you are still ultimately waiting for a full restart.

3. MaxRequestsPerChild=1

Perrin Harkins recently alerted me to the MaxRequestsPerChild=1 technique. That is, set MaxRequestsPerChild to 1, then load any potentially-changing modules in the child, not the parent (obviously only for development environments). Each request will hit a fresh child server, which will load all of your potentially-changing modules anew.

This is the nicest solution I’ve seen so far. The only problem I can see is its performance – each potentially-changing module has to be loaded on each request. **

4. My idea: The Pied Piper

As in 3, load any potentially-changing modules in the child. Leave MaxRequestsPerChild alone. As in 2, fork off a “watcher” process that waits for your modules to change. When they change, kill all the server’s children explicitly.

The end result is that you get reasonable performance when your modules don’t change (e.g. when you are only futzing with templates), but when modules do change, you should see the effects immediately.

This should be able to work with mod_perl, fastcgi, Net::Server, etc., as long as the parent server responds appropriately to the killing of all its children (by launching new ones). Apache, at least, seems to be ok with this.

Going to try to implement this as a plugin in Server::Control. Will see how it goes.

** – You can try to load things only on demand, but often mod_perl code is written without ‘use’ statements as it assumes everything is loaded in the parent. You can also try to minimize the number of potentially-changing modules, but then you run the risk of leaving something off and having to adjust it and restart.

This is an initial brainstorm. Refinement and details to follow, and feedback is very much encouraged.

Name

• HTML::Mason -> Mason. I believe we are finally entitled to a top-level name. This will help separate the new Mason from the old.
• MasonX:: for extensions? This is more problematic, as the MasonX:: namespace already has a number of modules that are specific to the current Mason. Regardless, it needs to be a short and convenient prefix.

Implementation

• Moose. We will use Moose for all classes. Moose represents a fundamentally different way of developing Perl, and it was the catalyst that started me thinking about a new Mason. Many of the remaining items in this list fall out of, or are enhanced by, Moosification.
• Components will be classes. Components started out as subroutines, then became objects. The logical next step is for each component to be its own Moose subclass. This will allow components to benefit from true OO techniques (methods, attributes, roles), instead of Mason’s current painful pseudo-OO.
• The entire component will be placed inside a MooseX::Declare class block, with a class name auto-generated from the component path.
• The main component body – the content and the inline Perl sections – will be placed into a main method.
• Calling a component (via <& &> or $m->comp) will mean creating a new instance of the component class, and calling its main method. Component call parameters will be passed to the constructor. Have to watch for performance impacts here.
• A $self variable is automatically available, assigned to the component instance.
• One of <%args> or <%attr> will be used to generate Moose attributes, rather than subroutine parameters. There will still be some syntactic sugar, but the section will have access to the full power of attributes. e.g.

     <%args>
     foo
     bar => (default => 5)
     baz => (default => 5, isa => 'Int')
     </%args>
  

  The advantage of attributes over parameters is that other methods in the component will have access to those values, something that is painful to deal with right now.

• Subcomponents will become methods. <%def> and <%method> are currently implemented as their own component objects inside the main component. There was never a particularly good reason to do this other than that it seemed like a neat idea, and over the years it has proved more frustrating than helpful – e.g. $m->current_comp and $m->caller sometimes defy expectation. Now that components will be classes, it makes sense for a subcomponent to be just another method alongside main.
• Autohandlers will be superclasses. Components will truly inherit from their autohandlers now. e.g. they’ll be able to call methods in the autohandler, a great way to share code within a hierarchy of components.
• Smaller core, more extensions. As with other modern Perl frameworks, we should move as much as we can from the core to extensions, where we can do so without overly sacrificing ease of use, performance, etc.

Syntax

• Same core syntax. The core syntax will be mostly the same – <% %> blocks, <%perl> and <%init> sections, %-lines. I do sometimes regret not going with the industry-standard <%= %> for expressions, so that <% %> could be used for non-expression Perl; but at this point <% $foo %> may be too deeply embedded in my brain to change it.
• <%once> becomes <%class>. The <%class> section will contain code to be placed in the class definition outside the main method: ‘use’ statements, pure-Perl methods, utility subroutines, pragmas etc.
• Automatic newline removal. Obvious newlines should be removed by default, so that components can be spaced neatly without adding gratuitous newlines to the output.
• Consolidated filter syntax. Mason has several kinds of content filters: <%filter> section, components with content, and escapes (e.g. |h). All of these filtering methods should be consolidated under a single implementation, if not a single syntax. In addition, we need a way to create new content filters with Perl methods and use them on blocks. Standard filters could be installed on the main component class, and more specific filters on individual components. Example:

   <%class>
   filter repeat ($times) {
       my ($self, $content) = @_;
       return $content x $times;
   }
   </%class>

   ...

   <% repeat (3) { %>
   blah blah
   <% } %>

New features

• More powerful controller mechanisms. Mason has controller mechanisms – dhandler, autohandler, and the resolver – that were innovative once but are now underpowered. I don’t believe (as some do) that Mason should get out of the controller business – I actually like having my “C” and “V” in the same place. Mason just needs to provide easy access to the same powerful routing techniques that are used in modern web frameworks, e.g. via Path::Dispatcher or Path::Router. For example, an autohandler or dhandler or other special file could indicate how paths under that directory should be routed – still have to work out the syntactic details. Of course, nothing will prevent people from using an MVC framework’s routing and treating Mason like a controller-less template language.
• Logging. Mason will log generously with different levels and categories via Log::Any. This was supposed to be put into Mason 1.x years ago but never made it…
• Output placeholders. Support the insertion of placeholders whose values can be supplied by code further along in the request. This is motivated by HTML head elements, like title, that you want to output in the top template but determine in a more specific page component.

New extensions

• MasonX::Tidy and MasonX::Critic. Tidying and criticizing specific to Mason components, analagous to what perltidy and perlcritic do for Perl.
• MasonX::Safe. Use static code analysis (PPI) to restrict the set of Perl operations that could be executed in a set of Mason components. In the spirit of, but less draconian and broken than, Safe. Useful for environments when non-Perl-programmers are modifying components, or to give the “don’t do too much in components” philosophy some teeth. Intended for friendly policy enforcement, not airtight security.

What can be deprecated/eliminated

• Web features. Mason has always ambiguously straddled the line between template language and web framework. This was out of necessity — when Mason was created, mod_perl was the only “web framework” in Perl. With the advent of web frameworks like Catalyst, Jifty and CGI::Application, and interfaces like PSGI/Plack, Mason no longer needs to occupy the web space. It should strive to simply be a great templating system that is easy to plug into various web frameworks. This means we can eliminate, among other things, the ApacheHandler and CGIHandler classes from the core.
• Plugin API. In 1.3 we added a custom Mason plugin API, but Moose method modifiers and roles are a far better and more industry-standard way of supporting plugins.
• <%cleanup> section. <%cleanup> has always been of dubious value because it is not guaranteed to run in case of an abnormal exit from the component. Now that components are classes, a DESTROY method in the <%class> section will be a more appropriate and functional way to perform cleanup.
• <%shared> section. Since the various methods in a component are now part of the same class and share attributes, there is no reason to have <%shared>.
• <%attr> or <%args> section. We only need to retain one of these to represent class attributes; the other can be eliminated.
• <%method> or <%def> section. Perl methods will now be easy to define in the <%class> section. It will still be useful to define methods that produce output, but we only need one of these sections.
• Non-CHI cache APIs. Eliminate the Cache::Cache and 1.0 APIs, and just support CHI.

What will be kept, begrudgingly

• Components returning values. There are some cleanliness arguments for eliminating the ability of components to return values – one should use methods instead, etc. But I think this feature is too frequently used to discard. This is something to discourage in the docs and for MasonX::Critic to complain about.

What do you think?

Mason developers, let me hear your feedback and ideas.

This is something I’ve been meaning to implement for nearly two years – talk about procrastination! What pushed me over the edge was that three of my distributions – Mason, CHI, and an upcoming Server::Control – all needed to log various things, and had no good generic way to do it.

As part of this effort, I surveyed the various general-purpose logging packages on CPAN to see which ones Log::Any should interface with. Log::Dispatch and Log::Log4perl were the heavyweights and obvious first choices, but I was unprepared for the sheer variety of other distributions. Logging, like templating systems, seems to be one of those things that everyone wants to try their hand at. Here’s a partial list of logging packages that all share roughly the same mission – dispatching logs to various outputs – along with the number of distributions that depend on each:

I particularly like that there are seven packages named with a variation of “Simple”, “Trivial”, etc. Trying to choose between these would be the opposite of simple.

To be fair, Log::Dispatch, presumably the easier of the two main logging packages to configure, requires this just to log normally to a file:

   my $dispatcher = Log::Dispatch->new();
   $dispatcher->add(
       Log::Dispatch::File->new(
           name      => 'foo',
           min_level => 'info',
           filename  => "$dir/test.log",
           mode      => 'append',
           callbacks => sub { my %params = @_; "$params{message}\n" },
       )
   );
   $dispatcher->info('this is a message');

It’s no wonder people tried this and yearned for a simpler alternative. (I’ve gotten permission from Dave to simplify a few of these things with a maintenance release.)

Here are some cool things I learned about:

• distroprefs – A way to improve the automatability of CPAN installs; namely, dealing with those pesky distributions that insist on asking you questions. We spent a bunch of time at Hearst writing expect scripts to deal with these so that we could automatically install our large CPAN base on different servers. Wish I’d known about distroprefs!
• Dist::Zilla – I’ve always been vaguely bothered by the amount of boilerplate in my CPAN distributions (copyright, author, version, etc.) but Dist::Zilla has finally provided the means and motivation to do something about it.
• KiokuDB – Stevan Little’s talk on KiokuDB got me excited about leaving behind RDBMSs and the Impedence Mismatch on my next web project. Just store Moose objects! Of course people have been getting excited about object databases since the 80s, and there’s probably a reason that Oracle is still around. But allow me to enjoy my dream before it smashes into reality.
• Memory persistence – As Steven Lembark gleefully hammered home, Perl never shrinks a variable. Once $foo has had a million bytes or @foo has a million entries, it’ll reserve that space forever, even if you empty it. Makes me want to look real close at any globals in persistent web environments.
• CGI::Inspect – Brock Wilcox wins the award for most satisfying feature demo. Insert CGI::Inspect’s inspect() somewhere in a web template. When it runs, a dashboard launches in a new browser window, with a stack trace and the ability to inspect and change lexical state before the page resumes its render. Of course, other environments like JSP/Eclipse have had live debugging of web pages for years, but in Perl this still seems groundbreaking , and the possibilities for extending it are intriguing.

Here are the pages for the talks referenced above:

When I first heard about this feature I instinctively dismissed it because it sounded inefficient, as if each instance were individually marked with a list of roles. In fact, the implementation is perfectly efficient. When you apply a role to an instance, Moose simply applies the role to the instance’s class to create a new anonymous class, then reblesses the instance into it. This is cached, so the next time you apply the same role to the same kind of object, the cached class can be used.

Now I’ve eliminated my custom code and have several roles working in CHI, each of which is activated by certain constructor parameters:

• IsSizeAware – activated if is_size_aware or max_size is specified
• HasSubcaches – activated if l1_cache or mirror_cache is specified
• IsSubcache – activated for subcaches themselves

Moving these features out into separate roles has cleaned up the main driver code considerably. It also speeds up the common case, since we don’t have to check for these things on each call.

This does mean that CHI now depends irrevocably on Moose. For a short time we tried to compromise with Mouse as a way to minimize dependencies and application startup cost, but the role support just isn’t there, and even the authors of Mouse are now publicly discouraging its use. Given the intelligence and drive of those working on Moose, I feel confident that it will continue to get faster and make its way into ever more Perl installations.

CHI drivers implement methods like remove() and clear(). If you call $cache->remove(), it goes directly to the driver subclass.

The problem is that there are now legitimate reasons to “wrap” these methods at the CHI/Driver.pm superclass level (meaning, do something before and/or after the method). For example, I want to add an optional generic size-awareness feature (the cache can keep track of its own size), which means that we have to adjust size whenever remove() and clear() are called. And I want to log remove() calls the way we currently log get() and set().

So one solution is to define remove() and clear() in CHI/Driver.pm, and have them call _remove() and _clear() in the driver subclasses. But this kind of change makes me uneasy for several reasons:

• It changes the driver API, i.e. all existing drivers out there have to modified. And we might have to change it again as we identify new methods to wrap.
• The list of ‘normal’ versus ‘underscore’ methods becomes rather arbitrary – it’s “whatever we’ve needed to wrap so far”.

I thought about using regular wrapping modules, like Sub::Prepend or Hook::LexWrap. But this fails when you have subclasses more than one level deep. e.g.:

   CHI::Driver -> CHI::Driver::Foo -> CHI::Driver::Foo::Bar

Now if you call CHI::Driver::Foo::Bar::remove(), the wrapping code will get called twice, once for each subclass. I only want it to be called once regardless of how deep the subclass is.

Here’s how I solved this in CHI-0.2. When each CHI driver is used for the first time, e.g. CHI::Driver::Memory:

   my $cache = CHI->new('Memory');

CHI autogenerates a new class called CHI::Wrapped::CHI::Driver::Memory, which inherits from

   ('CHI::Driver::Wrapper', 'CHI::Driver::Memory')

then blesses the actual cache object (and future cache objects of this driver) as CHI::Wrapped::CHI::Driver::Memory.

Now, when someone calls a method like $cache->get() or $cache->remove(), CHI::Driver::Wrapper has an opportunity to handle it first, and then pass control to CHI::Driver::Memory. If not, it goes directly to CHI::Driver::Memory.

I was unable to find this solution on CPAN, even though I feel like I must be reinventing the wheel. If someone knows of a distribution that encapsulates this technique, please let me know.

Here’s the code from CHI::Driver::Wrapper that creates the wrapper class:

   sub create_wrapped_driver_class {
       my ( $proto, $driver_class ) = @_;
       carp "internal class method" if ref($proto);

       if ( !$wrapped_driver_classes{$driver_class} ) {
           my $wrapped_driver_class      = "CHI::Wrapped::$driver_class";
           my $wrapped_driver_class_decl = join( "\n",
               "package $wrapped_driver_class;",
               "use strict;",
               "use warnings;",
               "use base qw(CHI::Driver::Wrapper $driver_class);",
               "sub driver_class { '$driver_class' }",
               "1;" );
           eval($wrapped_driver_class_decl);    ## no critic ProhibitStringyEval
           die $@ if $@;                        ## no critic RequireCarping
           $wrapped_driver_classes{$driver_class} = $wrapped_driver_class;
       }
       return $wrapped_driver_classes{$driver_class};
   }

And here’s the first application of auto-wrapping: when certain methods are called on a cache, automatically call them on the subcaches, if any.

   # Call these methods first on the main cache, then on any subcaches.
   #
   foreach my $method (qw(remove expire expire_if clear purge)) {
       no strict 'refs';
       *{ __PACKAGE__ . "::$method" } = sub {
           my $self = shift;
           my $retval = $self->call_native_driver( $method, @_ );
           $self->call_method_on_subcaches( $method, @_ );
           return $retval;
       };
   }

   # Call the specified $method on the native driver class, e.g. CHI::Driver::Memory.  SUPER
   # cannot be used because it refers to the superclass(es) of the current package and not to
   # the superclass(es) of the object - see perlobj.
   #
   sub call_native_driver {
       my $self                 = shift;
       my $method               = shift;
       my $native_driver_method = join( "::", $self->driver_class, $method );
       $self->$native_driver_method(@_);
   }

(See original use.perl posting)

There are two kinds of multi-level relationships that I wanted to be able to express easily with CHI:

• L1 (level 1) cache: Sits in front of the primary cache in order faster access for commonly accessed cache entries. i.e. a cache for your cache.

Mirror cache: Sits behind the primary cache and, over time, mirrors its contents. Useful for migrating from one cache to another without a sudden performance hit.

Initially CHI had a Multilevel driver that would let you place two or more caches inside a container cache object. The problem was that adding an L1 to an existing cache required changing it to a Multilevel cache, causing existing driver-specific calls to fail. (e.g. If I change a File cache to a Multilevel cache, File-specific methods will no longer get handled right.)

In 0.2 I switched to a primary cache / subcache model, which seems more appropriate. Now the File cache has an L1 subcache, and File-specific methods (as well as many ancillary methods on which the L1 relationship has no clear meaning) simply go to the primary cache.

The usage is also simpler. Here we place an in-process Memory cache in front a Memcached cache:

    my $cache = CHI->new(
        driver   => 'Memcached',
        servers  => [ "10.0.0.15:11211", "10.0.0.15:11212" ],
        l1_cache => { driver => 'Memory' }
    );

Note that there isn’t a way yet to specify a size limit for the memory cache, which would make this a lot more self-maintaining. That’s coming soon. In the meantime, I’m planning to use this for an unlimited request-based cache, clearing it manually at the end of each web request:

    $cache->l1_cache->clear();

Here we prepare to migrate from an old to a new cache directory:

    my $cache = CHI->new(
        driver          => 'File',
        root_dir        => '/old/cache/root',
        mirror_cache => { driver => 'File', root_dir => '/new/cache/root' },
    );

We leave this running for a few hours (or as needed), then replace it with

    my $cache = CHI->new(
        driver   => 'File',
        root_dir => '/new/cache/root'
    );

More details in the Subcaches section of the CHI 0.2 documentation.

(See original use.perl posting)

   # Try to get the value from the cache
   my $result = $cache->get('key');

   # If it isn't there, compute and set in the cache
   if (!defined($result)) {
      my $result = do_something_to_compute_result();
      $cache->set('key', $result, $expiration_time);
   }

This pattern is popular because it is easy to wrap around existing code, and easy to understand.

Unfortunately, it suffers from two problems:

• Miss Stampedes: When a cache item expires at the specified time, any processes trying to get it will start to recompute it. If it is a popular cache item and if recomputation is expensive, you may get many recomputations for the same item, which is at best wasteful and at worst can bog down a server.

  I originally recognized this problem while working on Mason’s busy locking, but am obviously not alone in experiencing it. The term “miss stampede” comes from this memcached list discussion – definitely worth a read.

• Recomputation Latency: When a cache item is recomputed, the client (whether that be a browser, command-line, whatever) has to wait for the computation to complete. Since caching keeps average latencies down, there is a tendency to ignore the unfortunate customer that gets stuck with one or more cache misses.

Here are some ways of tweaking the usage pattern above to address one or both of these problems. I’ve added the initials of the problems that each one addresses, and mentioned relevant features from CHI, if any.

• Probabilistic expiration (MS)

  Instead of specifying a single expiration time, specify a range of time during which expiration might occur. Then each cache get makes an independent probabilistic decision as to whether the item has expired. The probability starts out low at the beginning of the range and increases to 1.0 at the end of the range. What this means for popular cache items is that only one or a handful of gets will most likely expire at the same time.

  CHI supports this with the expires_variance parameter. It may be passed to individual set commands or as a default for all sets. Personally, I plan to default it to 0.2 or so in almost all my caches.

  Drawbacks: Since this is probabilistic, you get no guarantee of how well stampedes will be avoided (if at all), and you have to try to guess the right variance to use.

• Busy locks (MS)

  When a cache item expires, flag the item for a short time, either by upping its expiration time or by setting an associated value in the cache. Subsequent misses will see the flag and return the old value instead of duplicating the recompute effort.

  CHI supports this with the busy_lock parameter, stolen from Mason. It works by temporarily setting the expiration time forward by the specified amount of time.

  Drawbacks: Setting a busy lock involves a separate write. If you use this feature liberally, you’ll double the number of write operations you do. Some backends will suffer from a race condition, a small window of time in which many processes may decide to recompute, before the first lock has been successfully set.

• Background recomputation (RL)

  When a cache item expires, return the old value immediately, then kick off a recomputation in the background. This spares the client from the cost of the recompute.

  This requires a non-traditional usage pattern, since the get and set are effectively happening as part of one operation. In CHI it will look like this:

      my $result =
        $cache->compute( 'key', sub { do_something_to_compute_result() },
          $expiration_time );
  

  CHI already has a working compute API, but doesn’t yet know how to run things in the background. Coming soon.

  Drawbacks: Requires a non-traditional and somewhat ugly code pattern; background processes are harder to track and debug.

• External recomputation (MS + RL)

  Recompute cache items entirely from an external process, either when change events occur or when items approach their expiration time. Items never actually expire as the result of a client request. This is the most efficient and client-friendly solution, if you can manage it.

  Drawbacks: Requires extra external processes (more moving parts). Code to recompute caches must be available from the external process, which can result in some unwanted code separation, API contortions, or repetition. It is also difficult to know which items to keep repopulating, and when exactly to recompute them.

• Externally initiated recomputation (MS + RL)

  Use a periodic external process to trigger events that will naturally utilize your caches (e.g. write a cron job that hits common pages on your website), but pass a special flag making items more likely to expire. This makes it less likely that expiration will occur during a real client request.

  This is not yet supported in CHI, but the idea would be to add some kind of easily-accessible lever to temporarily view all expiration times as reduced. e.g.

      # Reduction ends when $lex goes out of scope
      my $lex = CHI->reduced_expirations(0.5);
  

  Drawbacks: Requires extra external processes (more moving parts). Triggers and their run frequencies must be carefully chosen.

What other techniques have you used, and what success/failures have you had with them?

(See original use.perl posting)

   file: $CPAN/authors/id/J/JS/JSWARTZ/CHI-0.03.tar.gz
   size: 62313 bytes
    md5: ec828f2466ba266e11cd6d1dd5ca2913

CHI provides a unified caching API, designed to assist a developer in persisting data for a specified period of time. It is intended as an evolution of DeWitt Clinton’s Cache::Cache package, adhering to the basic Cache API but adding new features and addressing limitations in the Cache::Cache implementation.

You might think of it as a fledgling “DBI for caching”.

Driver classes already exist for in-process memory, plain files, memory mapped files and memcached. Other drivers such as BerkeleyDB and DBI will be coming soon. Fortunately, implementing drivers is fairly easy, on the order of creating a TIE interface to your data store.

Special thanks to the Hearst Digital Media group, where CHI was first designed and developed, for blessing the open source release of this code.

There’s lots more in store for this module, so stay tuned! Feedback welcome here or on the Perl cache mailing list.

(See original use.perl posting with comments)