About dakkar

Gianni is a Perl Architect at NAP. His code from previous lives runs in universities administration software, inside ask.com news system, and even in Antarctica. He's currently busy writing libraries to make "the right thing" be "the easy thing".

NAP::Messaging – glue and policies for interacting with ActiveMQ

As part of our service oriented architecture, our Perl applications send messages over ActiveMQ; a few of them also consume those messages and act on them.

All these consumer applications are based on Catalyst. Initially, we used Catalyst::Engine::Stomp and a rather complicated set of in-house libraries to wrap it.

Those in-house libraries have, in time, grown to incorporate more and more responsibilities, including testing, logging, message serialisation, plugin loading… it was time to break them apart and write something cleaner.

Continue reading

Open Source

Asynchronous web services with PSGI and IO::Async

Some of our internal web applications are low-traffic enough that a
preforking server can handle them without difficulty. Some others, on
the other hand, can really benefit from a non-blocking implementation,
so that each server process can serve multiple requests “at the same
time”, by working on a request while waiting for other services to
return data for other requests.

Up to now all our non-blocking web services were written for the JVM,
usually with the Akka framework, but I wanted to see how hard would it
be to build something similar in Perl.

Turns out, it’s not very hard at all, if you use the right libraries
and pay attention at a few tricks.

Continue reading


NAP::policy: an introduction

What is NAP::policy?

It’s a pragma, or a “policy” module, to help people at NAP write more
uniform code.

The module itself is equivalent to a series of use statements,
that are considered “a good idea” for our needs.

The distribution also contains a few more “good idea” modules, that
are not tied to any particular application, but can help developers.

Continue reading


Catalyst::Engine::Stomp after 0.16

We use Catalyst::Engine::Stomp for all our ActiveMQ consumers. It works rather well, and (especially with the addition of our Net::ActiveMQ) makes working with queues mostly painless.

But there is always room for improvement. There were two main missing pieces:

  1. generalisation of the subscriptions and inputs, from “a queue per
    controller” to “one subscription per controller”
  2. dispatching to an action based on the JMSType header, instead
    of the ad-hoc @type body attribute we have been employing

This is the story of how I implemented both.

Continue reading