infrastructure

Thanks to a bit of copy-paste from SpringSource Tool Suite and an answer on Stack Overflow, I was able to bash together a little plugin to filter Spring Roo ITD files from Eclipse's Package Explorer and Project Explorer. It's free to use for any purpose as far as I'm concerned, especially because I didn't write any of it. To use it, take the file attached to this story and drop it into eclipse/plugins.

(I probably could have taken the plugin from STS and dropped it into the standard Eclipse but it also has other features that I don't need.)

As of Gradle 0.9, the jst.web facet version in the eclipse plugin is hard-coded to 2.4. Here's a workaround:

eclipseWtp.whenConfigured { config ->
    config.facets.each {
        if (it.name == 'jst.web') {
            it.version =
                configurations.providedCompile.getAllDependencies().find{
                    it.group == 'javax.servlet' && it.name == 'servlet-api'
                }.version
        }
    }
    config.facets.unique()
}

Note that you'd better declare a providedCompile configuration dependency on javax.servlet:servlet-api or this is going to break. But you'd better do that anyway or your project isn't going to build.

Let me know if you know of a better way to do this.

I set out this afternoon to set up a trial production-style install of a Mojolicious application.

There were several constraints due to the local environment. This being a primarily UNIX shop, this trial installation was performed on a Linux machine; actually, on my desktop, but it's similar enough to a production Solaris server for this purpose. To avoid introducing too many unfamiliar pieces of software to the organization (which historically has lead to confusion and push-back) the well-known Apache httpd 2.2 was selected as the user-facing web server. As the maximum simultaneous number of user sessions for this application is not expected to be high, say fewer than 50, no additional load balancer was placed in front of the single httpd. FastCGI was used to connect the httpd to the Mojolicious application server instances as recommended by Mojolicious documentation. The application server instances are being managed by the httpd in order to reduce the number of steps that the operations team will need to take to perform a restart. To facilitate installation on a non-dedicated host, dedicated installations of perl and Apache httpd are being used for this application.

The first step was to install httpd (2.2.13) and perl (5.8.9) under a directory that will be the application instance's home, say /srv/mojo-test. According to local custom, prefix paths were set to /srv/mojo-test/perl/20090811-5.8.9 and /srv/mojo-test/httpd/20090811-2.2.13, with symlinks from /srv/mojo-test/perl/active and /srv/mojo-test/httpd/active, to allow for pre-production testing and an easy controlled release when the time comes to upgrade these components. Then mod_fcgid (2.2) was built and installed in the httpd, and Mojo pre-0.991247 (git commit 99e342b5a995065cab01bc56d438293d71784e0b) was installed in this perl instance.

Since the goal was only to determine how a production installation of a hypothetical Mojolicious application could be set up, a fresh application was generated by executing /srv/mojo-test/perl/active/bin/perl /srv/mojo-test/perl/active/bin/mojolicious generate app MojoTestApp in /srv/mojo-test. (Note that the perl had to be specified; the mojolicious script uses env in the shebang line, ignoring knowledge of which perl instance Mojo was installed in.) This created /srv/mojo-test/mojo_test_app.

Following instructions given on the Mojo mailing list, I created /srv/mojo-test/mojo.fcgi with the following contents:

#!/srv/mojo-test/perl/active/bin/perl

use FindBin;
use lib "$FindBin::Bin/lib";

$ENV{MOJO_APP} = 'MojoTestApp';

use Mojo::Server::FastCGI;
Mojo::Server::FastCGI->new->run;

Then, after quite a bit of trial and error, and reading instructions on how to set up Rails for FastCGI — unfortunate, as they were a bit misleading in this case — I ended up with the following Apache httpd configuration block:

<IfModule !mod_fcgid.c>
    LoadModule fcgid_module modules/mod_fcgid.so
</IfModule>

<IfModule !mod_rewrite.c>
    LoadModule rewrite_module modules/mod_rewrite.so
</IfModule>

Listen 127.0.0.1:3001

<VirtualHost 127.0.0.1:3001>
    ServerName 127.0.0.1:3001
    DocumentRoot /srv/mojo-test/mojo_test_app
    ErrorLog logs/mojo_test_app.error.log
    TransferLog logs/mojo_test_app.access.log

    SocketPath fcgid_socket
    SharememPath fcgid_shm
    AddHandler fcgid-script .fcgi

    RewriteEngine On
    RewriteRule . /srv/mojo-test/mojo_test_app/mojo.fcgi [QSA,L]

    <Directory />
        Deny from all
    </Directory>

    <Directory /srv/mojo-test/mojo_test_app>
        <Files mojo.fcgi>
            Options +ExecCGI
            Allow from all
        </Files>
    </Directory>

</VirtualHost>

This appears to work well enough to proceed with further tests.

Note that I have yet to check whether this is an appropriate production setup; that comes next. I have not even determined what happens for multiple simultaneous requests. It does look pretty promising, though.

The current generation of web frameworks tend to process one request at a time, and depend on multiple instances running in order to handle multiple simultaneous requests. This is certainly convenient as it allows the programmer to ignore a great deal of concurrency concerns. Of course, this also means that a slow-running request can cause a backlog, even while other instances are sitting idle. Check out this screencast about HAproxy showing one solution to this problem.