Re: [cgiapp] How to lazy-load runmodes
On 25/05/2011 07:37, Ron Savage wrote: > > I don't run Apache anymore. I run nginx and proxy cgi-bin/ to > mini-httpd. A 'weird error' won't be in those programs, it'll be in your > code, no matter how hard you find that to believe :-))). > > It's a classic symptom of using a global variable(s), although (of > course) it could be something else. > It was a global variable :-). 'Trouble is it didn't show up when using Apache/CGI. Only when deployed with nginx + Starman. That's why I thought it was a Starman issue. I thought these global variable issues were only with mod_perl but they seem to apply to Starman though I couldn't find any guidelines about avoiding such issues with Starman. OK, I know you shouldn't use globals, and there was only 1 in this module, but if it's going to bork your app this badly it should be documented a la mod_perl. If globals are simply not an option rather than sloppy style it should be clearly stated. gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] How to lazy-load runmodes
On 24/05/2011 19:08, Joshua Miller wrote: > > Completely agree and second this. If you have a choice of FastCGI or > CGI, just go FastCGI. If you're concerned about the differences in > memory usage and such, you're free to benchmark them, but I can > assure you that, under any load at all, FastCGI can serve more pages > using less memory and cpu time. > I just deployed the same app under CGI::Application::PSGI/nginx/Starman and I'm getting a weird error which is very difficult to debug. The app will run fine returning a results page from a database lookup but if hit the Back button and resubmit it will continue successfully for between 5 and 10 repetitions then fail on one of the app's error handlers for a for field having too many characters. So nginx has proxied successfully and Starman returns 200 but it's failing unpredictably. I don't know if this has anything to do with it but I used a proxy_pass nginx setting rather than a fastcgi_pass setting. gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] How to lazy-load runmodes
On 24/05/2011 06:23, Joshua Miller wrote: > On Mon, May 23, 2011 at 11:15 PM, gvim wrote: > > "isn't there a huge startup penalty..." Not if you're using FastCGI, > PSGI + something like FastCGI or mod_perl, mod_perl, Starman or any > other persistent perl thing. In those cases, it loads and compiles > once, and subsequent hits go to the compiled perl bytecode (more or > less). It's actually better and faster to have everything loaded at > first in these, so that memory is shared (COW for mod_perl under > linux). Under plain old bare-bones CGI, yes, there is a startup > penalty on every hit. > Whilst a FastCGI solution improves startup time it doesn't address the memory footprint. I'm comparing deploying an app with CGI::Application vs. CGI with separate Perl scripts on a VM with a modest amount of mempory. From the what I'm learning about CGI::Application it seems that the memory footprint will skyrocket if your codebase has, say, 15 Perl scripts each containing over 300 lines of code as you now have 15 x 300 lines of code running instead of 300, no? gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] How to lazy-load runmodes
On 24/05/2011 05:27, Ron Savage wrote:
> Hi gvim
>
> You don't have to use or load them all. If you adopt
> CGI::Application::Dispatch and a MVC structure, only 1 controller
> module gets loaded, and hence only the run modes in that module get
> loaded.
>
But if I have only 1 controller module which 'use's 10 or 15 runmode modules:
use base 'AppBase';
use Register;
use Email;
use Another
sub setup {
my $c = shift;
$c->start_mode('register');
$c->run_modes({
register=> 'Register::register',
email => 'Email::email',
another => 'Another::runmode',
...
});
}
1;
... then I'm loading all 15 at startup, right? Even worse if I pack all those
15 into subs without external modules as in a lot of examples on the CA website.
> There are plenty of modules on CPAN which use this method.
>
> Mine include App::Office::Contacts, App::Office::CMS,
> Business::Cart::Generic and CGI::Application::Demo::Dispatch (hint).
>
> Of course, if you run them under plack or Starman, they are
> permanently resident anyway, so the startup overhead is only incurred
> once.
But the memory footprint is still affected, surely? I'm just trying to weigh
the benefits when running CGI::Application on a VM with a modest amount of
memory.
>
> All the above modules include a plack/starman runner httpd/*/*.psgi
> using C::A::D.
>
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
[cgiapp] How to lazy-load runmodes
If I have a collection of, say, 15 fairly lengthy Perl scripts and I convert them into a CGI::Application app with 15 runmodes isn't there a huge startup penalty since my app must now load the code for all 15 runmodes prior to dispatch? Is there a way to lazy-load my runmodes? Although I have each one contained in a separate module I still have to 'use' all of them at once when the app starts. gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
Re: [cgiapp] $self->tt_error() ?
On 20/05/2011 00:24, Cees Hek wrote:
> The plugin throws an error if processing a template fails. So you can
> wrap your calls to tt_process in an eval and catch any errors.
>
> my $output = eval { $self->tt_process({}) };
> if ($@) {
># Something went wrong
> } else {
>return $output
> }
>
> I generally just let these errors bubble up and let the
> CGI:Application error handler deal with it.
>
> Cheers,
>
> Cees
>
What about error logs, though. My converted CA/TT app currently gives
"Premature end of script headers" errors. Nothing more. I've checked all the
usual suspects and converted everything to:
return $c->tt_process( ...
Removed all:
print header();
Still no luck.
gvim
# CGI::Application community mailing list
####
## To unsubscribe, or change your message delivery options, ##
## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp##
####
## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ##
## Wiki: http://cgiapp.erlbaum.net/ ##
####
[cgiapp] $self->tt_error() ?
I'm using CA::Plugin::TT and there's no mention in the docs of a corresponding method for $tt->error(), ie. $self->tt_error(). gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Titanium won't install
The latest Titanium failed to install on my CentOS 5.5 server, running Perl
5.12.3. It failed to load 2 deps:
Test::WWW::Mechanize::CGIApp
CGI::Application::Server
Output below.
gvim
PETDANCE/Test-WWW-Mechanize-1.30.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /sw/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/00load.t .. 1/1 # Testing Test::WWW::Mechanize 1.30, with
WWW::Mechanize 1.66, LWP 5.836, Perl 5.012003, /sw/bin/perl
t/00load.t .. ok
t/autolint.t skipped: HTML::Lint is not installed, cannot test
autolint
t/back_ok.t . ok
t/click_ok.t ok
t/content_contains.t ok
t/content_lacks.t ... 2/5
# Failed test 'Handles not finding it'
# at t/content_lacks.t line 40.
# STDERR is:
# # Failed test 'Shouldn't say it's a test page'
# # at t/content_lacks.t line 39.
# # searched: "\x{0a}\x{0a}Test
Page"...
# #and found: "Test Page"
# # at position: 33 (line 3 column 16)
#
# not:
# /#\s+Failed\ test.*?\n?.*?at\ t\/content_lacks\.t line 39.*\n?/
#
# # searched: "\x{0a}\x{0a}Test
Page"...
#
# #and found: "Test Page"
#
# # at position: 33
#
# as expected
t/content_lacks.t ... Failed 1/5 subtests
t/follow_link_ok.t .. ok
t/followable_links.t ok
t/get_ok-parms.t ok
t/get_ok.t .. ok
t/has_tag.t . ok
t/head_ok-parms.t ... ok
t/head_ok.t . ok
t/html_lint_ok.t skipped: HTML::Lint is not installed, cannot test
html_lint_ok
t/link_content.t ok
t/link_status.t . ok
t/links_ok.t ok
t/new.t . ok
t/page_links_content.t .. ok
t/page_links_ok.t ... ok
t/pod-coverage.t ok
t/pod.t . ok
t/put_ok.t .. ok
t/stuff_inputs.t ok
t/submit_form_ok.t .. ok
t/text_contains.t ... ok
Test Summary Report
---
t/content_lacks.t (Wstat: 0 Tests: 5 Failed: 1)
Failed test: 5
Files=26, Tests=203, 24 wallclock secs ( 0.24 usr 0.06 sys + 5.12 cusr 0.44
csys = 5.86 CPU)
Result: FAIL
Failed 1/26 test programs. 1/203 subtests failed.
make: *** [test_dynamic] Error 255
PETDANCE/Test-WWW-Mechanize-1.30.tar.gz
/usr/bin/make test -- NOT OK
//hint// to see the cpan-testers results for installing this module, try:
reports PETDANCE/Test-WWW-Mechanize-1.30.tar.gz
Running make install
make test had returned bad status, won't install without force
Running make for H/HA/HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz
Has already been unwrapped into directory
/sw/.cpan/build/Test-WWW-Mechanize-CGIApp-0.05-GA0QZv
CPAN.pm: Going to build H/HA/HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz
Warning: Prerequisite 'Test::WWW::Mechanize => 1.04' for
'HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz' failed when processing
'PETDANCE/Test-WWW-Mechanize-1.30.tar.gz' with 'make_test => NO'. Continuing,
but chances to succeed are limited.
cp lib/Test/WWW/Mechanize/CGIApp.pm blib/lib/Test/WWW/Mechanize/CGIApp.pm
Manifying blib/man3/Test::WWW::Mechanize::CGIApp.3
HARTZELL/Test-WWW-Mechanize-CGIApp-0.05.tar.gz
/usr/bin/make -- OK
Running make test
PERL_DL_NONLAZY=1 /sw/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0,
'blib/lib', 'blib/arch')" t/*.t
t/autorunmode.t ... skipped: Won't test autorunmode_hack if
CGI::Application::Plugin::AutoRunmode isn't installed.
t/cgiapp.t Can't locate object method "new" via package
"Test::WWW::Mechanize::CGIApp::SUPER" at lib/Test/WWW/Mechanize/CGIApp.pm line
23.
# Looks like your test exited with 255 before it could output anything.
t/cgiapp.t Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 13/13 subtests
t/dispatch.t .. Can't locate object method "new" via package
"Test::WWW::Mechanize::CGIApp::SUPER" at lib/Test/WWW/Mechanize/CGIApp.pm line
23.
# Looks like your test exited with 255 before it could output anything.
t/dispatch.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 13/13 subtests
t/instance.t .. Can't locate object method "new" via package
"Test::WWW::Mechanize::CGIApp::SUPER" at lib/Test/WWW/Mechanize/CGIApp.pm line
23.
# Looks like your test exited with 255 before it could output anything.
t/instance.t .. Dubious, test returned 255 (wstat 65280, 0xff00)
Failed 26/26 subtests
t/pod.t ... ok
t/pod_coverage.t .. ok
Test Summary Report
---
t/cgiapp.t (Wstat: 65280 Tests: 0 Failed: 0)
Non-zero exit status: 255
Parse errors: Bad plan. You planned 13 tests but ran 0.
t/dispatch.t(Wstat: 65280 Tests: 0 Fa
Re: [cgiapp] size of scripts and dependencies
Michael Graham wrote: A bare Catalyst test app has about 87K lines. After you add all the plugins and support modules listed the tutorial (DBIx::Class, Template Toolkit, Session, Authentication, Authorization, FormFu) you're up to around 170K lines. Michael The fact that Titanium isn't quite as bloated as Catalyst offers no comfort to anyone who turned to CGI::Application as an anitdote to Catalyst dependency hell. All I'm saying is that Titanium may be heading in the same direction re dependencies which impacts deployment. I still haven't been able to get Titanium to install on OS X 10.5.8 / Perl 5.8.8 due to a circular dependency on a module loader plugin. gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] More Titanium dependency hell
Perl 5.8.8 / OS X 10.5.8 After resolving the first install failure of Titanium - Module::Signature / gpg needed even if you're trying to bypass cryptography with option [3] (what happened to [1] and [2]?) - I now find Titanium is failing on Module::Starter::Plugin::CGIApp ** root# cpan -i Titanium ... Creating custom builder _build/lib/MyModuleBuilder.pm in _build/lib Checking whether your kit is complete... Looks good Checking prerequisites... Looks good Creating new 'Build' script for 'Module-Starter-Plugin-CGIApp' version '0.10' /usr/bin/perl lib/Module/Starter/Plugin/CGIApp/templates/titanium/Makefile.PL Checking if your kit is complete... Looks good Warning: prerequisite Titanium 0 not found. Could not open '': No such file or directory at /Library/Perl/Updates/5.8.8/ExtUtils/MM_Unix.pm line 2627. lib/Module/Starter/Plugin/CGIApp/templates/titanium/Makefile.PL failed at /Library/Perl/5.8.8/Module/Build/Base.pm line 2457. JALDHAR/Module-Starter-Plugin-CGIApp-0.10.tar.gz ./Build -- NOT OK Running Build test Can't test without successful make Running Build install Make had returned bad status, install seems impossible Running Build for M/MA/MARKSTOS/Titanium-1.03.tar.gz Has already been unwrapped into directory /var/root/.cpan/build/Titanium-1.03-ErMEEl CPAN.pm: Going to build M/MA/MARKSTOS/Titanium-1.03.tar.gz Warning: Prerequisite 'Module::Starter::Plugin::CGIApp => 0.05' for 'MARKSTOS/Titanium-1.03.tar.gz' failed when processing 'JALDHAR/Module-Starter-Plugin-CGIApp-0.10.tar.gz' with 'make => NO'. Continuing, but chances to succeed are limited. Copying lib/Titanium.pm -> blib/lib/Titanium.pm Manifying blib/lib/Titanium.pm -> blib/libdoc/Titanium.3pm MARKSTOS/Titanium-1.03.tar.gz ./Build -- OK Running Build test t/02-pod.t .. ok All tests successful. Files=1, Tests=1, 0 wallclock secs ( 0.04 usr 0.02 sys + 0.13 cusr 0.03 csys = 0.22 CPU) Result: PASS MARKSTOS/Titanium-1.03.tar.gz Tests succeeded but one dependency not OK (Module::Starter::Plugin::CGIApp) MARKSTOS/Titanium-1.03.tar.gz [dependencies] -- NA Running Build install make test had returned bad status, won't install without force ** This is a long way from the lightweight ease of install we had with CGI::Application. zaphod # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
[cgiapp] Titanium install failing on OS X 10.5.8
Perl 5.8.8 / OS X 10.5.8 Titanium install is hanging on test 3/11 when installing Test::WWW::Mechanize t/put_ok.t .. 2/11 I have to say my first impression of Titanium is that it is heading in the direction of Catalyst regarding the number of dependencies and is in danger of losing sight of being a lightweight, easily installed alternative to the monolith that is Catalyst. Just my 2 cents. gvim # CGI::Application community mailing list #### ## To unsubscribe, or change your message delivery options, ## ## visit: http://www.erlbaum.net/mailman/listinfo/cgiapp## #### ## Web archive: http://www.erlbaum.net/pipermail/cgiapp/ ## ## Wiki: http://cgiapp.erlbaum.net/ ## ####
