Re: [Catalyst] Suggestions for sending email from cron job using 'Catalyst' templates?
On 04/11/2011 06:30 PM, Charlie Garrison wrote:
Good evening,
On 11/04/11 at 10:34 AM +0930, Jon Schutz jon+catal...@youramigo.com
wrote:
Perhaps fire up your app from the cron job using
Catalyst::Engine::Embeddable?
Thanks, didn't know about that one; I'll have a look.
Hmm, the documentation is a bit sparse; I can't see how to get $c (or
$app). I can't see anything in the test files either which show how to
get the app object. Do you have an example you could share?
Or should I just start the embeddable instance and then do a
handle_request to process the email sending?
That was my thought. Usage is essentially...
use strict;
use warnings;
use HTTP::Request;
BEGIN {
$ENV{CATALYST_ENGINE} = 'Embeddable';
}
require MyApp;
my $response;
MyApp-handle_request(HTTP::Request-new('GET',
'http://localhost/send/email'), \$response);
--
Jon Schutz
http://notes.jschutz.net/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Suggestions for sending email from cron job using 'Catalyst' templates?
On 12/04/11 08:10, Charlie Garrison wrote:
Good morning,
On 11/04/11 at 9:20 PM +0930, Jon Schutz jon+catal...@youramigo.com
wrote:
That was my thought. Usage is essentially...
use strict;
use warnings;
use HTTP::Request;
BEGIN {
$ENV{CATALYST_ENGINE} = 'Embeddable';
}
require MyApp;
my $response;
MyApp-handle_request(HTTP::Request-new('GET',
'http://localhost/send/email'), \$response);
Thanks for clarifying. And other than not tying up a FastCGI process,
what is the advantage of that approach over just sending a request via
http?
Depends on your circumstances, and personally I'd probably take the
approach of divorcing the templates from the catalyst context and just
use TT outside of Catalyst. But potential advantages of the embedded
approach are:
* Not needing to expose private URLs - if the URL you need to hit to
generate the email is not supposed to be available to the outside world,
you can use a different configuration for the app controlled from the
cron job.
* Still works if your Apache/FastCGI happen to be not running, in the
midst of restarting, or in bad shape for whatever reason, so save a
range of error checking and recovery that you would otherwise have to do.
* Can send your emails from another machine even if you don't have an
app running there.
BTW, you can use whichever form of URL that you like in the embedded
request - all of these forms that I tried still work (though as Matthias
pointed out, may affect how URLs appears in your templated output):
http://my.domain.com/send/email
http:///send/email
/send/email
--
Jon Schutz
http://notes.jschutz.net/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Suggestions for sending email from cron job using 'Catalyst' templates?
Perhaps fire up your app from the cron job using Catalyst::Engine::Embeddable? -- Jon Schutz http://notes.jschutz.net On 10/04/11 22:40, Charlie Garrison wrote: Good evening, First, I may not be approaching this the right way at all. So I'm happy to take any suggestions for a better way to do what I need. I've got a daily task (cron job currently) which sends emails to users. I want to use existing TT templates to generate the email content. I'm using Mail::Builder::Simple for the message creation sending. All the simple tests are working fine, until I want to use the existing template setup that I've been using to send email from within Catalyst. Specifically, the wrapper template (with header, footer, etc) makes fairly extensive use of c.uri_for and c.uri_for_action. And of course the Catalyst context is not available from the cron job (at least no way that I could find). One option is to move all the logic to a controller action and just have the cron job make an http request. That doesn't seem like the right approach though. Does anyone have suggestions on how I can use my existing template structure and still be able to use `c` from a cron job? Or should I use a completely different approach? Thanks, Charlie ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Job Queue recommendation
On 01/21/2011 07:35 PM, Octavian Rasnita wrote: Hello, Can you recommend a job queue system that works under Windows (and which works with Oracle if it needs a database)? TheSchwartz can't be installed, TheSchwartz::Moosified doesn't work with Oracle and Gearman::Server can't be installed under Windows because of Danga::Socket. Have you considered Amazon SQS? (Amazon::SQS::Simple) Or depending on your requirements, it might be just as easy to build your own. -- Jon Schutz http://notes.jschutz.net/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How receive signals from FCGI::ProcManager?
On 12/23/2010 06:28 AM, rimas rimas wrote: Hello! Some components of my application require accurate de-initialization to avoid resource leaks. I using Catalyst which running under FastCGI(ProcManager) and looking for possibility get notification that application is restarting or shutting down to perform specific cleanup actions. Seems to me ProcManager have required callbacks to notify application about events(e.g. pm_die) but is it possible to subscribe on such events without serious Catalyst hacking? Serg Gulko Create your own App::FCGIManager with 'use base qw(FCGI::ProcManager)', and run your process with 'app_fastcgi.pl -M App::FCGIManager'. Then you have access to override or adapt any of the FCGI::ProcManager methods that you want to. -- Jon Schutz http://notes.jschutz.net ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Issue with Plugin::Session
Could it be that you are working on localhost:3000 and/or other ports? I recall cases where some browsers don't deal with localhost and/or port numbers correctly. For example, if you have had sessions running on localhost:2999 and localhost:3000, the browser might be ignoring the port and sending cookies for both, so Catalyst might be taking the wrong cookie. Suggest you look at the Set-Cookie and Cookie headers on the wire to work out what's going on. -- Jon Schutz http://notes.jschutz.net On 01/06/2011 02:37 AM, jeff robinson wrote: Hi Having a prblem with Safari and IE browsers and the Session plugin. The app works fine with Firefox, but session data is being reset between requests with these other browsers. Example: DB1 x $c-session 0 HASH(0xac06a3c) '__address' = '10.87.199.12' '__created' = 1294242706 '__updated' = 1294242706 '__user_agent' = 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/4.1.3 Safari/533.19.4' After a single request using Safari, its now: DB2 x $c-session 0 HASH(0xad41888) '__address' = '10.87.199.12' '__created' = 1294242721 '__updated' = 1294242721 '__user_agent' = 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_4_11; en) AppleWebKit/533.19.4 (KHTML, like Gecko) Version/4.1.3 Safari/533.19.4' Exact same everything, except using Firefox DB1 x $c-session 0 HASH(0xc2f9b70) '__address' = '10.87.199.12' '__created' = 1294243509 '__updated' = 1294243509 '__user_agent' = 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 GTB7.1' After single request using FF. DB2 x $c-session 0 HASH(0xc2f3d18) '__address' = '10.87.199.12' '__created' = 1294243509 '__updated' = 1294243538 '__user_agent' = 'Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13 GTB7.1' 'user' = HASH(0xc31738c) 'accesscode' = 681430 'companyid' = 'bluestone' 'email' = 'jeffrobin...@bluestonetel.com' 'first' = 'jeff' 'last' = 'robinson' 'roles' = 'admin' 'serverid' = 'cpark-s1-v0' 'shortcompanyid' = 'blue' 'validate' = 'yes' Any ideas?? - J Catalyst 5.80029 | Catalyst::Plugin::ConfigLoader 0.28 | Catalyst::Plugin::Session 0.31 | Catalyst::Plugin::Session::State::Cookie 0.17 | Catalyst::Plugin::Session::Store::File 0.18 ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/ ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] JSON encoding issue: array of hashes
Your line
$c-stash( @results );
is the problem. Something like
$c-stash( results = \...@results );
is probably what you are looking for.
It's all explained here:
http://search.cpan.org/~bobtfish/Catalyst-Runtime-5.80025/lib/Catalyst.pm#$c-%3Estash
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
On 08/29/2010 04:43 PM, Dan wrote:
Hi people :)
Catalyst beginner here. I'm trying to get an array of hashes encoded.
Something is going wrong.
My code:
---
sub getRetailers :Path :Args(1) {
my ( $self, $c ) = @_;
my $results = $c-model('ESDB::Retailer')-search_literal( '1=1' );
my @results;
foreach my $result ( $results-all ) {
push( @results, {
id = $result-retailerid,
label = $result-retailername
} );
};
$c-stash( @results );
$c-forward('EasySaver::View::JSON');
}
---
Output:
{HASH(0x9f8bf88):{label:AGL,id:4},HASH(0xa4dbfb8):{label:Integral,id:2}}
---
So obviously the HASH(memory location) stuff is wrong. And also I see 2
records there, id 2 and id 4. I'm missing id 1 and id 3.
Anyone know what I'm doing wrong?
Thanks :)
Dan
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst and UTF8 Chained URLs
How would this patch affect systems that choose to encode their URLs in
something other than UTF-8? (Other character encodings are widely used,
particularly on Asian sites).
There might be a case for having the encoding type as a configurable
option (where one option is no decoding so the application can handle
it) - otherwise it has to be left to the application where the app
designers can reverse whatever encoding they have chosen.
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
On 09/09/2009 11:15 AM, Rod Taylor wrote:
I have a URL which includes UTF8 components which are in the chained
(CaptureArgs) position. The escape mechanism is supposed encode each
byte of the UTF8 sequence individually when creating the URL (which
Catalyst seems to do) and reverse this on the way in.
The below adjustment appears to fix the issue I'm having with URL
arguments not being decoded on the way in.
This may not be the right place to handle it as it could break older
applications which work around arguments not being decoded properly to UTF8.
This makes a good test URL.
$uri = $c-uri_for( $cont-action_for($action), ['VÜ Living', '他们有理
性和良心' ]);
Should result in VÜ Living and 他们有理性和良心 being in the first and
second captured arguments.
*** Chained.pm.orig Tue Sep 8 21:10:10 2009
--- Chained.pm Tue Sep 8 21:35:38 2009
***
*** 168,174
$request-action(/${action});
$request-match(/${action});
! $request-captures($captures);
$c-action($action);
$c-namespace( $action-namespace );
--- 168,187
$request-action(/${action});
$request-match(/${action});
!
! # Decode Captures
! my $decodedCaptures = [];
! if ($captures @$captures) {
! for my $arg (@{$captures}) {
! $arg =~ s/%([0-9A-Fa-f]{2})/chr(hex($1))/eg;
! utf8::downgrade($arg);
! utf8::decode($arg);
! push(@{$decodedCaptures}, $arg);
! }
! }
! $request-captures($decodedCaptures);
$c-action($action);
$c-namespace( $action-namespace );
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] How to enhance Log4Perl log-files about the loggend in user ($c-user-id)?
Somewhere early on on the request cycle do
Log::Log4perl::MDC-put( 'user' = $user );
then insert it into your log messages via your Log4perl configuration
such as:
log4perl.appender.Logfile.layout.ConversionPattern: %d %-5p %c -
USER:%X{user} - %m%n
Christoph Metz wrote:
Hi,
i got a Catalyst-App which inits a session on the startpage, after a
user logged sucessfully in with his login-data. Now, i also use
Log4Perl to do extensive logging, as far as the app is enough tested. so
i use the log4perl conf file this way:
__PACKAGE__-log(Catalyst::Log::Log4perl-new(__PACKAGE__-config-{home}.'/log.conf'));
where log.conf logs all data into a file myapp.log. There are many
useful cspecs to show really exact log-entrys but one is missing,
i want to see which debug/error/warn message was logged by which user.
so how to pass the logged in user ($c-user-id) into the
log4perl log-files?
custom cspecs like descripted on CPAN
Log::Log4Perl::Layout::PatternLayout are not able to access the
namespace of my app,
or at least i am not able to pass the context to the custom-cspecs sub
in the log4perl conf-file :(
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Slow fastcgi: A debugging aid
Octavian Râsnita wrote on 5/4/09 5:43 PM: It would be nice to be able to limit the number of requests per fastcgi child process... On Mon, 2009-05-04 at 19:56 -0500, Peter Karman wrote: Catalyst::Plugin::AutoRestart Would I be correct in my reading of the code, that since the exit() happens in handle_request, the request that triggers the restart does not get served? I did a similar thing by subclassing FCGI::ProcManager and adding the restart logic into pm_post_dispatch so the restart does not interfere with any current requests. The subclass name is passed to the start-up script with the -M option. Would be nicer to be able to do this in a plugin, of course, but I couldn't at the time see any post-request hooks in Catalyst itself that could be used to ensure that the full request cycle completes before the server restarts. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] fastcgi error
On Fri, 2009-05-01 at 04:14 -0700, gutta wrote: hello, when i am starting my fastcgi server using perl script/bizmo_fastcgi.pl -l /tmp/bizmo.socket -n 5 -p /tmp/bizmo.pid -d i am getting following error [Fri May 01 09:48:26 2009] [error] [client 122.166.21.34] (2)No such file or directory: FastCGI: failed to connect to server /tmp/bizmo.fcgi: connect() failed [Fri May 01 09:48:26 2009] [error] [client 122.166.21.34] FastCGI: incomplete headers (0 bytes) received from server /tmp/bizmo.fcgi could anyone tell me what is the problem? Looks like you've told apache that your socket is at /tmp/bizmo.fcgi but you've told the script that it's /tmp/bizmo.socket. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] fastcgi error
On Fri, 2009-05-01 at 04:45 -0700, gutta wrote: Hi, I have given the following in my apache config file apache2.conf FastCgiExternalServer /tmp/bizmo.fcgi -socket /var/www/thebizmo/tmp/bizmo.socket Alias / /tmp/bizmo.fcgi/ do i need to change the above configurations u mean? I would think that should read: FastCgiExternalServer /tmp/bizmo.fcgi -socket /tmp/bizmo.socket -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Catalyst, MVCs and other MVCs
Hi Jacinta, On Tue, 2008-11-04 at 14:25 +1100, Jacinta Richardson wrote: If anyone has anything they'd like to share about Catalyst vs Jifty, Gantry, CGI::App, Maypole, Mojolicious etc, I'm certainly open to insights. I don't have enough time to learn all of these frameworks properly so I'm very dependent - at this stage - on information from the users and creators. Here is a piece I wrote some time ago about why we chose Catalyst - hopefully there's something useful for you in there: http://software-reviews.summer-snowstorm.com/content/view/17/1/ -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
[Catalyst] Plug your Favourite Search Solution (was [Announce][META] MojoMojo 0.999021 has been released to CPAN)
On Sun, 2008-11-02 at 00:51 +, Dermot wrote: I was considering Lucene as the basis of an text search engine. Lucence fans claim it's the industry standard. http://search.cpan.org/~tbusch/Lucene-0.18/lib/Lucene.pm I guess if you developing in a Perl env then KinoSearch should be your choose. Having looked at the docs at http://www.rectangular.com/kinosearch/docs/stable/KinoSearch/Docs/Tutorial.html We have been using Sphinx full-text search with considerable success. For anyone interested I have written up a bit of an overview of using Sphinx with Perl: http://notes.jschutz.net/18/perl/integrating-sphinx-into-perl-applications -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Configuration of $c-log with Catalyst::Log::Log4perl
On Thu, 2008-05-08 at 16:42 +0200, Jochen Luig wrote: So, can anyone tell me where I should continue looking for the error? Can anyone think of a scenario where the logger config gets messed up after initial configuration? If any part of your app invokes Log::Log4perl-easy_init(), that will break it. There was such a line of code in a SQL::Translator file at one stage, but it has been fixed in more recent versions. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Configuration of $c-log with Catalyst::Log::Log4perl
On Fri, 2008-05-09 at 10:04 +0930, Jon Schutz wrote: On Thu, 2008-05-08 at 16:42 +0200, Jochen Luig wrote: So, can anyone tell me where I should continue looking for the error? Can anyone think of a scenario where the logger config gets messed up after initial configuration? If any part of your app invokes Log::Log4perl-easy_init(), that will break it. There was such a line of code in a SQL::Translator file at one stage, but it has been fixed in more recent versions. I take that back - the file in question is SQL::Translator::Schema::Graph.pm and the call to easy_init() is still there. There's a good chance this module is loaded if you are using DBIx::Class and calling deploy() from your app. Details in: http://www.mail-archive.com/[EMAIL PROTECTED]/msg03436.html -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Fri, 2008-04-25 at 15:53 +0100, Matt S Trout wrote: There's no written standard currently; I'd love to see somebody take a crack at writing one but I'm not sure what would need to go in it. I've attached a draft based on some of our company procedures to show the sorts of things that need to be addressed. I've changed a few things to reflect some of the Catalyst conventions that I am aware of but it will need your input, particular w.r.t. any conventions from PBP that you disagree with. having this interesting discussion. Can we put a timescale on it? What is the plan for release of 5.7013 and/or 5.80? Next week or two would be ideal; if you can't make time that soon then you need to say -now- so somebody else can fix this. I'd need 2-3 weeks as the next week and a half is out and I'm concerned about the time it will take to review the original code to check the subtleties, and then write new tests. The code itself is only a few minutes work... -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo (Proposed) Catalyst Coding Standards and Policies This document outlines the standards and policies for contributing to the Catalyst Project and attempts to capture the conventions that the project team has chosen to use to ensure that the quality and consistency of the code base is maintained. The project greatly benefits from the many contributors in the Catalyst community, and in turn the wider Catalyst community benefits from consistent and reliable code through adherence to these agreed standards. Any questions or clarifications regarding this document should be directed to the Catalyst mailing list. These standards are to be applied for core Catalyst development and are recommended for use with plugins and other contributed code. 1. Coding Standards 1.1. Perl Best Practices (Oreilly, Conway) should be followed unless otherwise noted here. 1.2. All code shall be clear of perlcritic warnings (at severity level 5), with the following exemptions: 1. Stricture disabled at line ... See page 429 of PBP. (Severity: 5) This warning is acceptable providing the 'no strict ...' is applied within the minimum scope necessary. (perlcritic does not seem to be able to reliably recognise minimum scope). 1.3 Indentation Use 4-space indentation. Hard tabs are prohibited. 2. Documentation Standards Please familiarise yourself with the Perl Best Practices description of types of documentation. 2.1 All User API functions shall have appropriate documentation suitable for end users of the API. These should appear in perldoc. 2.2 Documentation associated with functions and methods that are not part of the User API shall be as follows: - private functions and methods (as identified by a leading underscore in the function/method name) shall have any documentation in comments so as to not appear in perldoc. - internal functions and methods (meant for use within the same package only) shall be flagged as such and have documentation in comments so as to not appear in perldoc. - internal functions and methods that are not for general users buy may be used by extensions (which may be packaged separately, such as derived classes or plugins) should appear in perldoc, clearly identified as Developer API methods. 3. Testing Guidelines Write the documentation for your API functions to adequately define the inputs and expected outputs. Then write tests that match. * Each module should have at least one corresponding file in the 't/' test directory. Permissible exceptions: o where the module is trivial, such that it can be adequately tested by code inspection o where the module requires external infrastructure (e.g. a remote website) which is unreasonable to duplicate; in this case it may be more appropriate to add a working example into the 'examples/' subdirectory. Make sure that everything that can be reasonably tested through a regression test, is; this might mean splitting the module, placing the reusable, testable components in their own modules and keeping the application level code that requires the external infrastructure separate. o modules which only include configuration data for a suitably tested parent class may not need their own tests * All public methods (user and developer API methods) should be tested. Permissible exceptions: o where the method is inherited and suitably tested in the parent class o where the method is created through configuration of a suitably tested parent (such as accessors created using Class::Data::Inheritable or Class::Accessor) * Testing of private/protected methods may be appropriate when sufficient test coverage is difficult to achieve when testing
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Mon, 2008-04-21 at 19:18 +0100, Matt S Trout wrote: On Mon, Apr 21, 2008 at 11:29:56AM +0930, Jon Schutz wrote: I'm making a stand here for the rights of all developers! Backward compatibility is a must for defined interfaces, but to carry that through to say that all design decisions turn into interfaces that must be preserved, even though not meant for external consumption, discourages innovation. Many factors separate good projects from bad, and one is well defined interfaces! And the tradition in perl is that if it doesn't start with an _, it's a public interface. The leading underscore indicates a private variable or function, from which it does _not_ follow that everything else is public. Example - Catalyst.pm contains: 1. Clearly private, internal methods with leading underscore and documentation in comments 2. Private methods with leading underscore that do pop up in the perldoc ($c-_localize_fields, which I presume is probably just an oversight) 3. Perldoc-documented methods with no leading underscore that are identified as internal methods (like 'friend' or 'protected' methods, I guess) - the doc says These methods are not meant to be used by end users. 4. Perldoc-documented methods with no leading underscore that are bona- fide user API methods. 5. Undocumented methods with no leading underscore ($c-setup_finished, for example). The point is, it's pretty clear what users _are_ allowed to access, so anyone applying the leading underscore rule does so at their peril. DBIx::Class originally used an if it's not documented it's not a public interface approach and I got massive negative feedback over that from people who'd followed the perl convention and got bitten later. But presumably that was because there was insufficient documentation in the first place, so early adopters had to get into the code. Which leads me to an aside - Why do we insist on having unit tests but let basic API documentation escape? How can we write tests without the API documentation?? Really, we are only having this discussion because $c-stats had no docs in the first place. Fact is I agree with most of what you say, it's just a question of where the boundary lies. If I had a choice, I'd follow documentation means public, no docs means use at your own risk. But there's an established standard, and that isn't it, so we live with the world we have. You're not making a stand for anything except your right to buck standard perl practice and get away with it; I tried, failed, had unhappy users, and learned. Welcome to the real world sucking. If it was perfect, we'd need a lot less developers :) Not at all; the implication of what you say is that standard perl practice is poor software engineering practice (not to say that there aren't inadequacies, of course there are). Respecting APIs is pretty fundamental, yes? -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Mon, 2008-04-21 at 19:16 +0100, Matt S Trout wrote:
On Mon, Apr 21, 2008 at 11:49:56AM +0930, Jon Schutz wrote:
On Sun, 2008-04-20 at 15:15 +0100, Matt S Trout wrote:
So far as I can see, all we really need to do is supply a proxy of the
common Tree::Simple method from the C::Stats object through to
$self-{tree}
and we're done. That'll provide compatibility with obvious usages without
adding any significant compatibility overhead.
I was hoping Jon would do this because he was the original author of
C::Stats
and could see any subtleties that needed paying attention to that I've
missed.
I would have to review the pre-5.7012 code but from memory there were
some differences in when internal fields in the tree were set, so
returning $self-{tree} will stop crashes but there may be some side
effects, such as inaccuracies in the resulting reports.
Well, if there is you can make the warning mention that.
Trouble with explicitly proxying the methods is that Tree::Simple has
many methods and who knows how many people have used what out there (I
suspect, very few and very little, but who knows?).
So? That's just a for() loop setting up *{$name} = sub { ... } entries.
You've heard my objections on principle and resistance due to minimal
residual impact in practice, but if one were to fix it, I suppose a
simple compromise would be something like this (untested):
That's not a compromise, that's an AUTOLOAD, which is poor coding practice
when you know what methods the object on the other side exists.
Indeed it is a compromise. PBP says don't use AUTOLOAD, but for all the
reasons it gives for not using it, it could probably have a footnote
saying something like If you're just putting in AUTOLOAD to support a
deprecated interface that's not going to be supported in the next major
revision, and the lifetime is pretty short, and nobody you know of is
actually using that deprecated interface anyway, then it's probably OK -
at least as a compromise. That's what it says in my copy of PBP, I
think.
I'm aware you object on principle; however I've stated very clearly why I
believe your objections are incorrect and since you're contributing to
Catalyst I'd ask that you follow the current Catalyst standards for
backwards compatibility even if you disagree, just the same as you'd do
for coding style and other matters of opinion. If I ever contribute to one
of your projects I'll happily return the favour :)
No problems, if that's what the Catalyst standard says; I must have
missed it. Where is it? I'd like to consult it on a number of
matters... please post the link.
Please can you do a specific setup, with tests; I'd suggest using
Class::Inspector to pull the list of methods and to proxy all those that
don't currently exist in your class.
Then we can have a warning included and happily throw these methods out in
5.80; the point is that people's code shouldn't go from fully working to
completely broken without a stage of still works but warns them they're
doing it wrong first (and note that if we'd called the method $c-_stats
I'd agree with you that it was private and we can deprecate it at will. but
we didn't. such is life)
The fact that it's supposedly already in a stage of completely broken
kind of undermines that theory.
I'm quite aware that I've spent more time debating the point than it
would have taken just to do this nugatory work, but then we wouldn't be
having this interesting discussion. Can we put a timescale on it? What
is the plan for release of 5.7013 and/or 5.80?
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Thu, 2008-04-24 at 04:16 -0500, Jonathan Rockway wrote: No problems, if that's what the Catalyst standard says; I must have missed it. Where is it? I'd like to consult it on a number of matters... please post the link. Basically it's more of a zeitgeist than an actual document. There are some things that the community has decided and just do. One is not breaking things or adding features between point releases. We've fucked this up a number of times, but that doesn't really matter, the point is we try to fix our mistakes. Compare this to other frameworks that just break things and say fuck you. A standard is not a standard unless it's written down as a common reference for everybody to see. People in the community come and go and don't all have the same history, or longevity of memory for all the let's make this a standard decisions that happen along the way. This is perhaps getting close to the crux of the problem. Clearly Matt and I, and you it seems, have a different concept of what the standard is. Is there someone out there, then, with the right background, to set up a Wiki page and document this zeitgeist? The fact that it's supposedly already in a stage of completely broken kind of undermines that theory. Not really. It just means we need to fix it even sooner. I'm quite aware that I've spent more time debating the point than it would have taken just to do this nugatory work, but then we wouldn't be having this interesting discussion. Can we put a timescale on it? What is the plan for release of 5.7013 and/or 5.80? Can you either: * do this now * or say you're not going to do it? No I can't do it now, but may well be able to if given a time frame. That would make it easier for someone else to just get this done. Obviously you aren't obligated to do anything, because it's an open source project. But when someone contributes changes, we release them, and then realize that there's a problem, it's nice to have the contributor around to fix the issues. When they just disappear or argue against the project's conventions, it doesn't really look good, right? The stats code is good stuff. Why taint it with flamewars when it can be loved-by-everyone in just a few minutes? :) I thought we were having a discussion, an exchange of views, perhaps challenging what the conventions really are - and I think so far everyone contributing has managed to be fairly level about it. Apologies if my statements have been taken the wrong way. It seems to me that there are some underlying issues here which need to be sorted out. At least I think so. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Sun, 2008-04-20 at 15:15 +0100, Matt S Trout wrote:
So far as I can see, all we really need to do is supply a proxy of the
common Tree::Simple method from the C::Stats object through to $self-{tree}
and we're done. That'll provide compatibility with obvious usages without
adding any significant compatibility overhead.
I was hoping Jon would do this because he was the original author of C::Stats
and could see any subtleties that needed paying attention to that I've
missed.
I would have to review the pre-5.7012 code but from memory there were
some differences in when internal fields in the tree were set, so
returning $self-{tree} will stop crashes but there may be some side
effects, such as inaccuracies in the resulting reports.
Trouble with explicitly proxying the methods is that Tree::Simple has
many methods and who knows how many people have used what out there (I
suspect, very few and very little, but who knows?).
You've heard my objections on principle and resistance due to minimal
residual impact in practice, but if one were to fix it, I suppose a
simple compromise would be something like this (untested):
our $AUTOLOAD;
sub AUTOLOAD {
my $self = shift;
my $name = $AUTOLOAD;
$name =~ s/.*://o;
warn Catalyst::Stats method $name is deprecated.;
return $self-{tree}-$name(@_);
}
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Fri, 2008-04-18 at 19:54 +0100, Matt S Trout wrote: On Sat, Apr 12, 2008 at 08:37:49PM +0930, Jon Schutz wrote: Prior to 5.7012, $c-stats was an internal object (in so far as it was not documented as part of the API) so anyone manipulating it directly does so at their own risk. This one user who was kind enough to report it to the list will by far not be the only one with this problem. Catalyst::Plugin::SubRequest was also hit by this. Never, ever assume that 'undocumented' means 'I can break compat any time I like'. This works in theory, and in theory, theory is the same as practice, but ... I apologise to anyone who was inconvenienced by this change. I've written a guide to upgrading for anyone who was using the Tree::Simple object directly: http://notes.jschutz.net/17/perl/adding-action-timings-to-your-catalyst-output Nevertheless I stand by my comment that anyone who digs through the source code to find an internal object or function and then chooses to use that in external code does so at their own risk. Furthermore I suggest that anyone who is savvy enough to get into the code, understand it, and chooses to use an internal object/function, is aware of the risk and is more than capable of adapting their own code should an internal object/function change. Catalyst::Stats was introduced to define an interface for the stats object so that one could safely override the default implementation if they wished; the default implementation also introduced profiling methods that were not there before. You need to consider your failure to maintain backwards compatibility a bug and fix it. I said this at the time but apparently you didn't get round to fixing the Catalyst::Stats patch. Please do so as soon as you get time; Catalyst::Stats' API is a great leap forward but not at the cost of previously running code (although I think perhaps the compat code -should- warn that you're using an API you shouldn't have been and that it'll go away in the future). How would one define backwards compatibility in this case? That $c- stats must return a Tree::Simple object with all of the same user- defined fields as before? The logical extension of this argument says that on any minor release, the internal representation of *any* stored data or the signature of *any* internal function or method may not change, which surely is too restrictive on developers. 5.7012 has been out since December 2007. It seems to me a case of closing the gate after the horse has bolted. I don't hear an angry mob out there complaining. Perhaps as a result of this being raised the angry mob will come knocking; that being the case, I'll be happy to revisit the code. As it stands I'm unconvinced of the need for backward compatibility in this case, both of the principle (of preserving unpublished undocumented undefined interfaces) and the level of popular demand. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Mon, 2008-04-14 at 20:21 +0100, Richard Jones wrote: Jon Schutz wrote: Did you set the -Stats flag to a non-zero value? i.e. use Catalyst qw/-Stats=1/ Err, no ;-) But I have now and it's fine - thanks. But there seems to be nothing I can do to set the flag at the command line when I start the devel. server (eg myapp_server.pl -Stats, myapp_server.pl MYAPP_STATS=1, myapp_server -STATS=1, etc). The idea is to enable stats for browser access but spare the t/*.t tests from dumping masses of timing data to the console when run. Other way around ... MYAPP_STATS=1 myapp_server.pl or export MYAPP_STATS=1 myapp_server.pl -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Why does $c-stats require -Debug flag?
On Sat, 2008-04-12 at 10:45 +0100, Richard Jones wrote:
I think you probably want $c-stats-report, but can't think why you're
calling this directly as it is invoked in finalize() if -Debug or -Stats
is set. See perldoc Catalyst::Stats.
Because I never got round to delving into Catalyst::Stats or
Tree::Simple inner workings. I copy/pasted the example from
http://www.onemogin.com/blog/559-adding-action-timings-to-your-output.html
into my Root::end() method and it just worked.
At least it did until I removed the -Debug flag. And then tried to
recover functionality by updating Catalyst::Stats to the latest version,
which also updated Catalyst itself (I was using an earlier 5.70x). So
I've no idea in which module(s) the change occurred to stop the process
working. Maybe someone more familiar with these modules could offer a clue?
Following the example in the blog post, the solution is to set -Stats
and change your Root::end() method to something like:
@report = $stats-report;
$c-stash-{'action_stats'} = [EMAIL PROTECTED];
and then adjust your template as now you're getting an array of arrays
rather than an array of hashrefs.
Prior to 5.7012, $c-stats was an internal object (in so far as it was
not documented as part of the API) so anyone manipulating it directly
does so at their own risk. Catalyst::Stats was introduced to define an
interface for the stats object so that one could safely override the
default implementation if they wished; the default implementation also
introduced profiling methods that were not there before.
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
___
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Template::Plugin::Latex 3.00_05 and catalyst
The weird thing is that the workaround doesn't work for me with
version 3 of the T:P:Latex, but if I force (in the T:P:Latex code,
not in my application) the return value of the system call to be 0,
then it works. The hack proposed in the catalyst calendar looks like
this, and I can't see anything that would make it work only for a
particular version of a plugin.
{
no warnings 'redefine'; # right here, you can tell bad things
will happen
local *Template::Latex::system = sub {
my $ret = system(@_);
# guesstimate whether the system call was successful or not
return 0 if ( guess == OK );
return $ret;
} if $c-engine =~ /^Catalyst::Engine::HTTP/;
Any ideas why it doesn't work?
Not sure, but I have successfully used Template::Plugin::Latex 3.00_05
in Catalyst dev server using a patch for the system() problem previously
posted on the catalyst-dev list, which I have attached. Seems others
may not have had the same success as me, so YMMV.
--
Jon SchutzMy tech notes http://notes.jschutz.net
Chief Technology Officerhttp://www.youramigo.com
YourAmigo
---BeginMessage---
On Sat, 2007-10-27 at 12:46 -0400, Andy Grundman wrote:
optional_http-server.t + live_fork.t already tests for this and was
failing the tests for system() and backticks return codes. Post-patch
it passes system() and still fails backticks exit code.
Hmm, even with the patch both the system and backticks tests fail for
me. The output is the same with or without the patch:
Well, I checked with vanilla 5.8.8, vanilla 5.9.5 and RHEL5
perl-5.8.8-24, and on all systems I got the same - prepatch both system
() and backticks fail, and postpatch system() is fixed but backticks
still fails.
Nevertheless, I thought I'd have a look at the backticks problem as
well, and implement the double-fork approach - the main process forks
and reaps its child inline, which happens without delay because all the
child does is fork again and exit, so there is no need for any SIG{CHLD}
handling at all.
Attached is suggested patch against svn 7075, with which I get all tests
passing on optional_http-server and optional_http-server-restart. (And
yes, my app still works too!) Please give it a try and see if you have
more success.
--
Jon
Index: t/live_fork.t
===
--- t/live_fork.t (revision 7075)
+++ t/live_fork.t (working copy)
@@ -15,9 +15,6 @@
use lib $FindBin::Bin/lib;
use Catalyst::Test qw(TestApp);
-plan skip_all = 'Using remote server'
-if $ENV{CATALYST_SERVER};
-
plan skip_all = 'Skipping fork tests: no /bin/ls'
if !-e '/bin/ls'; # see if /bin/ls exists
Index: t/live_stats.t
===
--- t/live_stats.t (revision 7075)
+++ t/live_stats.t (working copy)
@@ -6,9 +6,12 @@
use FindBin;
use lib $FindBin::Bin/lib;
-use Test::More tests = 5;
+use Test::More;
use Catalyst::Test 'TestAppStats';
+plan skip_all = 'Using remote server'
+if $ENV{CATALYST_SERVER};
+plan tests = 5;
{
ok( my $response = request('http://localhost/'), 'Request' );
ok( $response-is_success, 'Response Successful 2xx' );
Index: lib/Catalyst/Engine/HTTP.pm
===
--- lib/Catalyst/Engine/HTTP.pm (revision 7075)
+++ lib/Catalyst/Engine/HTTP.pm (working copy)
@@ -11,6 +11,7 @@
use Socket;
use IO::Socket::INET ();
use IO::Select ();
+use POSIX :sys_wait_h;
# For PAR
require Catalyst::Engine::HTTP::Restarter;
@@ -189,7 +190,6 @@
}
my $restart = 0;
-local $SIG{CHLD} = 'IGNORE';
my $allowed = $options-{allowed} || { '127.0.0.1' = '255.255.255.255' };
my $addr = $host ? inet_aton($host) : INADDR_ANY;
@@ -278,8 +278,22 @@
if ( $options-{fork} ) {
if ( $pid = fork ) {
DEBUG warn Forked child $pid\n;
+ # Wait for child to complete its fork
+ my $kid;
+ do {
+ $kid = waitpid($pid, WNOHANG);
+ } until $kid 0;
next;
}
+ else {
+ # child forks again
+ # double-fork avoids defining SIG{CHLD} in main process,
+ # which causes system() and backticks to return incorrect status
+ if ($pid = fork) {
+ die Fork failed: $! if $pid 0;
+ exit;
+ }
+ }
}
$self-_handler( $class, $port, $method, $uri, $protocol );
@@ -324,7 +338,6 @@
DEBUG warn Shutting down\n;
if ($restart) {
-$SIG{CHLD} = 'DEFAULT';
wait;
### if the standalone server was invoked with perl -I .. we will loose
___
Catalyst-dev mailing list
[EMAIL PROTECTED]
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev
---End Message
Re: [Catalyst] Web hosting?
On Fri, 2008-01-04 at 09:28 +0800, Martin Ellison wrote: Dreamhost have refused to accept our site on the grounds of their frad detection system. No explanation given, and I have no idea why as this is a legitimate business. Did you contact a human at Dreamhost and ask why? In contrast to some hosting providers, I have found Dreamhost's humans to be reasonable people. -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Database connections leaking
On Fri, 2007-12-21 at 18:34 -0700, [EMAIL PROTECTED] wrote: The program seems to be working fine while on the Catalyst test server, and when on an Apache/mod_perl server when the postgres database is on the same physical server. The database connections don't start leaking until we attempt to use a separate (physical) database server. We verified this using iptraf and seeing none of the connections being re-used *or* closed. How many database connections are you actually seeing? You should expect up to one per Apache/mod_perl process. Are you also seeing growth in the number of Apache processes? -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Database connections leaking
On Fri, 2007-12-21 at 21:32 -0700, Kevin Nathan wrote: I can't check the server right now (need to be at work for that), but I didn't think to watch for Apache/mod_perl processes. What we were looking for was port 5432 connections (postgres). When it works, we get two or three connections per login and they stay steady. When it's not working, they continuously increase until config limit is reached (we've gone as high as 3000 connections). It will be a few days now, before I can check it again unless I get some time to drive to the colocation, but I will check for the Apache processes. If they are going up, too, where should I look? Any hints (or websites) that may help? Thanks for the quick response! It seems to me you would know about it, one way or another, if you had 3000 apache processes! I would speculate that the logic in Catalyst::Model::DBI that checks whether it currently has an active connection, is not working for remote Postgres connections, so it keeps creating new ones. I suggest (a) making sure you have the latest version of DBI and DBD::pg and postgres libraries, and if that doesn't solve it, (b) add debug into Catalyst::Model::DBI stay_connected sub to find out which bit of the logic is causing a reconnect. As I'm not much of a postgres or mod_perl user, I bow out here and let the experts take over... -- Jon SchutzMy tech notes http://notes.jschutz.net Chief Technology Officerhttp://www.youramigo.com YourAmigo ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] Re: Ubuntu / Catalyst
On Tue, 2007-11-13 at 11:16 +, Richard Jones wrote: Peter Edwards wrote: Centos 5 == Red Hat Enterprise Linux 5. For production quality, you can expect it to be pretty stable and I have corporate customers running it successfully. It's one of our development platforms. However, note mst's comments about the broken Perl on it. I found that quite shocking considering it's supposed to be a premier Linux hosting platform. As usual, compiling your own perl and Apache and providing your own PERL5LIB dir per live application area is a sane way of going about delivering standardised live applications you can roll out and support. Possibly a bit OT now, but as I'm about to set up another production server and was going to use CentOS 5, I'm a bit concerned. Matt mentioned fstab and init, but not as far as I can see Perl - in what way is Perl broken on CentOS 5? We have some tens of production servers running CentOS 4/5, and apart from the CentOS 5 perl issue (which was quite nasty) have been satisfied with it as a production platform. Its key asset is that you don't get any surprises, like version upgrades that have incompatible configuration files so your services stop working. Personally I would not consider Ubuntu suitable as a production server platform as it is too close to the bleading edge. However, really any O/S version could be used in production if you turn off automatic updates and you're prepared to manage and test every upgraded and security patched package on an individual basis. Whichever platform you choose for production (presumably in an Internet environment), getting your firewalling right, keeping your footprint small, keeping your security patches up to date and knowing your configuration baseline are probably the main criteria to ensure a reliable software subsystem. -- Jon ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] [OT] Search Solution
On Thu, 2007-11-08 at 13:48 +0200, Octavian Rasnita wrote: What do you think about e-swish, Kinosearch and Lucene? As it has been years since I have reviewed these (swish-e and lucene), it wouldn't be fair for me to comment. Lots of detail and links at http://www.searchtools.com/tools/tools.html -- Jon ___ List: Catalyst@lists.scsys.co.uk Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst Searchable archive: http://www.mail-archive.com/[EMAIL PROTECTED]/ Dev site: http://dev.catalyst.perl.org/
Re: [Catalyst] DProf
If benchmark testing isn't showing the fault, it's likely that it is data-dependent, i.e. it depends on something in the request or response - something that the benchmark doesn't trigger. Perhaps clients are left lingering - an incorrect Content-Length could cause that. I've also seen apache get stuck in busy wait states when proxying through to a remote site that is not responding correctly. Your top output is very likely an indication that some requests are not being served to completion. You could try (as root) netstat -nap | grep http to see what network connections the httpd processes are holding open. lsof may also tell you something useful. Try attaching an strace to one of the busy httpds to see what system calls it is doing. The difficulty with the mod_perl environment is that your httpd processes are polluted with everything else that is happening on your server - PHP etc - so what perl is responsible for is obscured. Testing in a fastcgi environment is better in this respect since perl and apache are separated. If you are able to try fastcgi, it might reveal some further insights. On Sat, 2007-11-03 at 11:39 +0200, Octavian Rasnita wrote: From: Jon Schutz [EMAIL PROTECTED] Hi Octavian, As useful as DProf is, it's giving you a global picture and not localising the parts of your app which are chewing up the time. Is TT really the problem? Have you seen a big difference in times reported against View::TT-process in the stats summary (seen with debug on) since introducing I18N? Well, I have started Apache with a single process and I put apache bench (ab) to make requests to the server, but when testing it, the processor doesn't become very occupied. But if I let the server work in its normal way, after a few hours I see that there are very many tasks running, many apache processes, and the processor becomes very used. I also see that the memory usage increases even if in the moment I check there are no many visitors for sure, and if I do an apache restart, the memory usage and the processor usage problems are solved temporarily. If the TT render times are not substantially different, then your problem lies elsewhere and you might benefit from grabbing the current svn version of Catalyst with the new $c-profile() method, which would allow you to narrow down which parts of your code are taking the time. If it is TT, then I would take the approach of systematically removing parts of the template to isolate the cause. Have your response times changed substantially, or is it just more CPU being used for the same response time? The response time also increases, and sometimes the server doesn't restart because the processor is very used that I can connect very hard with ssh to the server in some cases. So I think I might have a memory leak in the program, and it might also affect the processor usage... I don't know, and I don't know how to check if I have a memory leak somewhere. Here is the result of the top command when the processor is very used, and then below it is the result of the same command after doing a service apache restart: top - 10:13:05 up 102 days, 21:55, 2 users, load average: 50.84, 51.63, 52.75 Tasks: 172 total, 51 running, 121 sleeping, 0 stopped, 0 zombie Cpu(s): 99.9%us, 0.1%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8099328k total, 7988468k used, 110860k free, 222800k buffers Swap: 8707220k total, 104352k used, 8602868k free, 1676436k cached PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 26626 apache25 0 494m 158m 3948 R 10 2.0 61:04.35 httpd 26716 apache25 0 527m 190m 3980 R 10 2.4 46:21.67 httpd 26770 apache25 0 493m 157m 3972 R 10 2.0 52:21.82 httpd 27110 apache25 0 492m 156m 3980 R 10 2.0 49:22.97 httpd 28415 apache25 0 479m 142m 3944 R 10 1.8 18:11.57 httpd 28458 apache25 0 477m 141m 3944 R 10 1.8 17:36.15 httpd 28471 apache25 0 477m 141m 3948 R 10 1.8 15:40.51 httpd 28474 apache25 0 477m 141m 4024 R 10 1.8 14:23.98 httpd 28510 apache25 0 477m 140m 3916 R 10 1.8 15:48.10 httpd 28532 apache25 0 493m 157m 4024 R 10 2.0 10:07.61 httpd 28649 apache25 0 482m 146m 4028 R 10 1.9 7:57.07 httpd 28667 apache25 0 485m 149m 3944 R 10 1.9 9:09.52 httpd 28678 apache25 0 483m 147m 3952 R 10 1.9 8:31.92 httpd 28720 apache25 0 452m 116m 4048 R 10 1.5 1:56.92 httpd 28771 apache25 0 472m 136m 3980 R 10 1.7 5:53.55 httpd 28772 apache25 0 474m 138m 3908 R 10 1.8 6:42.63 httpd 27118 apache25 0 525m 188m 4024 R 10 2.4 50:12.74 httpd 26906 apache25 0 492m 156m 3968 R9 2.0 55:05.21 httpd 27060 apache25 0 493m 156m 3936 R9 2.0 59:29.47 httpd 27087 apache25 0 493m 156m 3960 R9 2.0 49:26.85
