[Dancer-users] using Starman for powering dancer apps

Naveed Massjouni naveedm9 at gmail.com
Mon Jul 4 10:07:00 CEST 2011

On Mon, Jul 4, 2011 at 3:55 AM, Pedro Melo <melo at simplicidade.org> wrote:
> Hi,
> On Sun, Jul 3, 2011 at 11:59 PM, Mr. Puneet Kishor <punk.kish at gmail.com> wrote:
>> Ok, then I added another app "bar" under ~/Documents/www (sibling to "foo"). Now, I am trying to run multiple apps as per the instructions at [http://search.cpan.org/~sukria/Dancer-1.3060/lib/Dancer/Deployment.pod] under the heading "Running multiple apps with Plack::Builder".
> There was a thread one or two weeks back discussing this point. I
> didn't pay much attention to it, but I think the result was that the
> current instructions are wrong and a new version was committed to the
> git repo for the next release. Check the ML archives.
>> I created the following web.psgi file in ~/bin
>> ----
> [...]
>> builder {
>>        mount "/foo" => builder {$app1};
>>        mount "/bar" => builder {$app2};
>> };
>> ----
> <aside>
> Running multiple Dancer apps in the same process can be done, but I've
> always found it to be awkward.
> Its a design thing. Dancer uses a lot of global variables to do its
> magic so you need to keep switching the global context, including the
> configuration, per request. Its a tradeoff: you get a very cool and
> simple DSL to manipulate your request and response, but this requires
> a global context.
> For the same reason, its practically impossible to use Dancer with
> Twiggy and do long polling, where each perl interpreter will have
> multiple requests going at the same time.
> I don't see this as bugs or limitations, on the contrary. They are
> design tradeoffs, where you get a very very practical DSL but loose
> the possibility to do some things. I like that Dancer is willing to
> loose some features in order to be excellent at the rest. Not many
> frameworks are willing to do that, and the Dancer developers should be
> commended by this.
> </aside>
> If you are using a frontend reverse proxy (apache in your case), then
> my suggestion is that you start two starman instances with plackup,
> one for foo app and another for bar app, on different ports, and
> configure apache to do the proper url mapping to each one.
> Its simpler, IMHO more robust, and you can start/stop/restart each app
> separately, and tune the number of workers per app.
> I reverse setting up multiple apps in the same perl interpreter for
> very extreme cases, and I don't recommend it as a general solution.
>> Two, are both "foo" and "bar" going to be accessible at Do I just add the following lines to my httpd.conf
>> ----
>> ProxyPass        /foo
>> ProxyPassReverse /foo
>> ProxyPass        /bar
>> ProxyPassReverse /bar
>> ----
> If you follow my suggestion above, tweek the second pair of lines to use 5002.
>> Three, how do I run plackup in the background? I want to run it, but be able to close the shell, and even logout and have it running.
> nohup plackup_cmd_line &
> is the usual way to do this, but plackup has a better way:
>    -D, --daemonize
>        Makes the process go background. It's up to the backend
>        server/handler implementation whether this option is respected or
>        not.
>> Four, if I have a single web.psgi as above, one disadvantage is that if I tinker with any one app, and have to turn off or restart Starman, it will affect all the apps powered by Starman. Perhaps a better situation would be to have a separate Starman process for each app. What is the best practice here?
> One plackup per app is my recommended approach as I wrote above. My
> modesty prevents me from calling this a "best practice" :)
> Bye,
> --
> Pedro Melo

Pedro, I think your explanation was excellent about the tradeoff that
Dancer makes. After reading this, I believe that the section in
Dancer::Deployment pod on deploying multiple apps should contain a
caveat. Something to the effect of, "Here is how you can deploy
multiple apps, but this is not the way Dancer is meant to be used.
Instead, consider multiple plackup processes."


More information about the Dancer-users mailing list