Mysterious restarts of development server
Hello everybody, I have a problem with the builtin web server of Dancer1. I use it for development and testing purposes. Sometimes - I haven't figured out what triggers this behaviour, but it happens sometimes rather quickly, sometimes after running for hours or even days - the server mysteriously switches to the development environment and port 3000. I usually start the server like this (omitting some nohup and bash redirection stuff): perl bin/app.pl --port 7000 --environment production In the output I see this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:7000 Dancer::Plugin::Database::Core (0.06) Dancer::Plugin::Lexicon (0.05) Dancer::Plugin::Database::Core::Handle (0.02) Dancer::Plugin::Database (2.09) Dancer::Plugin::Auth::Basic (0.030) Dancer::Plugin::EscapeHTML (0.22) Dancer::Plugin::Ajax (1.00) == Entering the production dance floor ... [13413] core @0.000008> Dancer::Session::Storable using session_dir : sessions in /data/perl5/biodatabase/lib/perl5/Dancer/Session/Storable.pm l. 35 [13413] core @0.013884> loading Dancer::Handler::Standalone handler in /data/perl5/biodatabase/lib/perl5/Dancer/Handler.pm l. 45 [13413] core @0.014051> loading handler 'Dancer::Handler::Standalone' in /data/perl5/biodatabase/lib/perl5/Dancer.pm l. 483
So far, so good, but then - after variable amounts of time as sketched above, this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:3000
The problem is that obviously, from now on the server is not reachable under port 7000 any more, and eventually, my testers complain and I have to restart the server. As you can see, the process ID does not change. Does the server exec itself forgetting the command line parameters? Or what else happens? I hope someone can help me avoid this behaviour. Thanks a lot, Lutz
On 09/26/2014 04:06 PM, Lutz Gehlen wrote:
Hello everybody, I have a problem with the builtin web server of Dancer1. I use it for development and testing purposes. Sometimes - I haven't figured out what triggers this behaviour, but it happens sometimes rather quickly, sometimes after running for hours or even days - the server mysteriously switches to the development environment and port 3000.
I usually start the server like this (omitting some nohup and bash redirection stuff): perl bin/app.pl --port 7000 --environment production
In the output I see this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:7000 Dancer::Plugin::Database::Core (0.06) Dancer::Plugin::Lexicon (0.05) Dancer::Plugin::Database::Core::Handle (0.02) Dancer::Plugin::Database (2.09) Dancer::Plugin::Auth::Basic (0.030) Dancer::Plugin::EscapeHTML (0.22) Dancer::Plugin::Ajax (1.00) == Entering the production dance floor ... [13413] core @0.000008> Dancer::Session::Storable using session_dir : sessions in /data/perl5/biodatabase/lib/perl5/Dancer/Session/Storable.pm l. 35 [13413] core @0.013884> loading Dancer::Handler::Standalone handler in /data/perl5/biodatabase/lib/perl5/Dancer/Handler.pm l. 45 [13413] core @0.014051> loading handler 'Dancer::Handler::Standalone' in /data/perl5/biodatabase/lib/perl5/Dancer.pm l. 483
So far, so good, but then - after variable amounts of time as sketched above, this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:3000
The problem is that obviously, from now on the server is not reachable under port 7000 any more, and eventually, my testers complain and I have to restart the server.
As you can see, the process ID does not change. Does the server exec itself forgetting the command line parameters? Or what else happens? I hope someone can help me avoid this behaviour.
My recommendation is not to use the builtin web server at all. You could use same deployment for live and development, just with a different Dancer environment. Which is usually quite simple with plackup and an init script. Regards Racke -- Perl and Dancer Development Visit our Perl::Dancer conference 2014: http://act.perl.dance/
On 9/26/2014 08:20, Stefan Hornburg (Racke) wrote:
My recommendation is not to use the builtin web server at all.
Why? I realize that some Plack-aware Perl web servers are faster than the one built into Dancer, but isn't offloading static content generation to a reverse proxy (e.g. nginx) a bigger overall win for a typical web app than adding complexity at the Dancer layer? You imply that there may be a stability problem with the built-in Dancer web server. I haven't had any problems with it yet.
Hello Stephan I use build in server on port 80 ./bin/app.pl --port=80 and I send debug on my console ( via ssh ) it is quick to start and easy to develop with it The only one limitation I found is on ajax query ( it doesn't work correctly) and if I lost my console - server continue to work, but no really... you need to kill it in fact this is only for testing not for production - use ngnix or apache bye Hugues Le 26/09/2014 16:20, Stefan Hornburg (Racke) a écrit :
On 09/26/2014 04:06 PM, Lutz Gehlen wrote:
Hello everybody, I have a problem with the builtin web server of Dancer1. I use it for development and testing purposes. Sometimes - I haven't figured out what triggers this behaviour, but it happens sometimes rather quickly, sometimes after running for hours or even days - the server mysteriously switches to the development environment and port 3000.
I usually start the server like this (omitting some nohup and bash redirection stuff): perl bin/app.pl --port 7000 --environment production
In the output I see this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:7000 Dancer::Plugin::Database::Core (0.06) Dancer::Plugin::Lexicon (0.05) Dancer::Plugin::Database::Core::Handle (0.02) Dancer::Plugin::Database (2.09) Dancer::Plugin::Auth::Basic (0.030) Dancer::Plugin::EscapeHTML (0.22) Dancer::Plugin::Ajax (1.00) == Entering the production dance floor ... [13413] core @0.000008> Dancer::Session::Storable using session_dir : sessions in /data/perl5/biodatabase/lib/perl5/Dancer/Session/Storable.pm l. 35 [13413] core @0.013884> loading Dancer::Handler::Standalone handler in /data/perl5/biodatabase/lib/perl5/Dancer/Handler.pm l. 45 [13413] core @0.014051> loading handler 'Dancer::Handler::Standalone' in /data/perl5/biodatabase/lib/perl5/Dancer.pm l. 483
So far, so good, but then - after variable amounts of time as sketched above, this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:3000 The problem is that obviously, from now on the server is not reachable under port 7000 any more, and eventually, my testers complain and I have to restart the server.
As you can see, the process ID does not change. Does the server exec itself forgetting the command line parameters? Or what else happens? I hope someone can help me avoid this behaviour. My recommendation is not to use the builtin web server at all.
You could use same deployment for live and development, just with a different Dancer environment.
Which is usually quite simple with plackup and an init script.
Regards Racke
Hi Racke, On Friday 26.09.2014 16:20:46 Stefan Hornburg (Racke) wrote:
On 09/26/2014 04:06 PM, Lutz Gehlen wrote: [...]
So far, so good, but then - after variable amounts of time as sketched
above, this:
Dancer 1.3123 server 13413 listening on http://0.0.0.0:3000
The problem is that obviously, from now on the server is not reachable under port 7000 any more, and eventually, my testers complain and I have to restart the server.
As you can see, the process ID does not change. Does the server exec itself forgetting the command line parameters? Or what else happens? I hope someone can help me avoid this behaviour.
My recommendation is not to use the builtin web server at all.
You could use same deployment for live and development, just with a different Dancer environment.
Which is usually quite simple with plackup and an init script.
Thanks for your quick reply. I'm testing plackup with Starman now. Cheers, Lutz
On 9/26/2014 08:06, Lutz Gehlen wrote:
perl bin/app.pl --port 7000 --environment production
I suspect what's going on there is that something causes Dancer to re-read config.yml, which makes it use whatever port and environment settings it finds there, or defaults if you haven't given them. Therefore, set the port number in either config.yml or in environment/production.yml, depending on whether that port is always used or only used for production mode. I've run Dancer for many days, possibly even weeks configured this way, using a nonstandard port, and it never changes out from under me.
Hi Warren, thanks for your reply. On Friday 26.09.2014 17:21:43 Warren Young wrote:
On 9/26/2014 08:06, Lutz Gehlen wrote:
perl bin/app.pl --port 7000 --environment production
I suspect what's going on there is that something causes Dancer to re-read config.yml, which makes it use whatever port and environment settings it finds there, or defaults if you haven't given them.
Hm, I wouldn't know what causes Dancer to reread the config. The behaviour I described certainly occurs without me touching any files under the application directory.
Therefore, set the port number in either config.yml or in environment/production.yml, depending on whether that port is always used or only used for production mode.
I agree that would take care of the port switch. Still the application would switch from production to development, which is clearly much less of a problem, but an inconvenience all the same.
I've run Dancer for many days, possibly even weeks configured this way, using a nonstandard port, and it never changes out from under me.
Thanks for that feedback, certainly interesting to know. Cheers, Lutz
On 9/26/2014 10:12, Lutz Gehlen wrote:
On Friday 26.09.2014 17:21:43 Warren Young wrote:
Therefore, set the port number in either config.yml or in environment/production.yml, depending on whether that port is always used or only used for production mode.
I agree that would take care of the port switch. Still the application would switch from production to development,
Not if config.yml also has: environment: "production" Basically, config.yml entirely takes over the role of your command line parameters.
participants (4)
-
Hugues -
Lutz Gehlen -
Stefan Hornburg (Racke) -
Warren Young