Re: Moving ExecCGI to mod_perl - performance and custom 'modules' [EXT]
As a long time Oracle DBA and perl mangler I have refrained from joining this conversation until now. Connection caching is a configuration option in DBI, not a coding requirement. For web servers it is a single line edit in startup.pl import DBICache versus import DBI if I recall incorrectly. NO CODE CHANGES REQUIRED Now caching connections will require clean code. Code that was acceptable on a short term connection causes problems on long term connections. Cursors left open, virtual connections not closed, etc are non-issues using DBI but huge problems with DBICache Applications doing heavy sql or batch work should not use DBICache. Just from an administrative perspective. Session less applications like web servers SHALL use it. And I use the legal meaning for shall I don't care what database is on the end of a DBI connection, I mangle em all, poorly YMMV Dave -- Dave Morgan Senior Consultant, 100 Alberta Limited dave.mor...@100.com 403 399 2442
Re: Disconnect database connection after idle timeout
What I don't understand is what you are worried about? Whether you are using Apache::DBI or David Wheelers DBIHandler (do I have that correct?) both will behave according to the configuration of the database and web server. Why not just let the servers decide whether to maintain or destroy a connection according to your configuration? Set your timeouts in both Oracle and Apache and let them deal with it On 11/13/2014 07:39 AM, Xinhuan Zheng wrote: If TTL were implemented, the module would have to disconnect from db connection after a pre-defined timeout so the oracle server process could be shut down more gracefully. Would it be possible to implement that? Or is it too hard to implement? No one cares about shutting down Oracle gracefully. I have not used shutdown immediate, other than by mistake in probably 10 years. I have never successfully used shutdown normal Idle db connections cost almost nothing, establishing a connection is expensive. Warning: I am better at Oracle than perl, and I am not very good with either :) YMMV Dave - xinhuan From: Paul Silevitch p...@silevitch.com mailto:p...@silevitch.com Date: Wednesday, November 12, 2014 at 11:53 PM To: Xinhuan Zheng xzh...@christianbook.com mailto:xzh...@christianbook.com, modperl modperl@perl.apache.org mailto:modperl@perl.apache.org Subject: Re: Disconnect database connection after idle timeout I don't fully understand your need here. I'm going to give my best. You could set an alarm in the cleanup handler that calls the disconnect after a specified amount of time. If a new request comes in, you could cancel the alarm in a postreadrequest handler (or something early in the cycle). To cover the race condition where the disconnect happens right before the cancel, you could check to make sure the database connection is active right after the cancel is called. HTH, Paul On Wed, Nov 12, 2014 at 9:36 PM, Xinhuan Zheng xzh...@christianbook.com mailto:xzh...@christianbook.com wrote: Hello, I am having a database connection management question. Our apache+mod_perl application initiates a database connection request when it needs to then do data processing. Afterwards, if there is no more requests coming to this apache process, the database connection basically will be sitting there in idle state for quite a while until the OS TCP/IP idle timeout has reached. At that point the database would send a message into its alert log, telling that a connection timeout has occurred and the server process will be cleaned. I would like to figure out if mod_perl application can implement keep-alive timeout mechanism. The mod_perl would maintain the database connection after it finishes some processing until an idle timeout defined in the application has reached, for example, 5 minutes. Then the mod_perl would initiate a database disconnection request so the server process can be cleaned more gracefully. We are using Oracle 11g database. I knew in 11G oracle has implemented the connection pooling. I would think the oracle side connection pooling would be the server side maintaining the connection idle timeout. Would it be possible on the client side the mod_perl implement something like that? I just don’t know which side is more appropriate and how on the client side it can implement something like that. Thanks, - xinhuan -- Dave Morgan Senior Consultant, 100 Alberta Limited dave.mor...@100.com 403 399 2442
Re: Disconnect database connection after idle timeout
On 11/13/2014 09:42 AM, Perrin Harkins wrote: On Thu, Nov 13, 2014 at 11:29 AM, Dr James Smith j...@sanger.ac.uk mailto:j...@sanger.ac.uk wrote: From experience - and having chatted with our DBAs at work, with modern Oracle and with MySQL keeping persistent connections around is no real gain and usually lots of risks MySQL I don't know, Oracle, every connection should be persistent if you are making more than a single call The last time I worked with Oracle, connections were too slow to run without caching them. That was years ago though, and the situation may have improved. I hate to quote myself but . On 11/13/2014 08:00 AM, Dave Morgan wrote: Idle db connections cost almost nothing, establishing a connection is expensive. Warning: I am better at Oracle than perl, and I am not very good with either :) Making a new connection to Oracle 11 or 12 is still painfully expensive. Dave -- Dave Morgan Senior Consultant, 100 Alberta Limited dave.mor...@100.com 403 399 2442
Re: Apache::DBI connection lost contact error
On 06/03/2013 03:14 PM, Perrin Harkins wrote: On Monday, June 3, 2013, Xinhuan Zheng wrote: What is the check to see if the server is restarting? Is that new child processes spawning? I always found the best way to run/test Apache::DBI was to run a mod-perl enabled http server without Apache::DBI. Test, let the webserver go idle, do not shutdown, check for live connections to the database. If any, you are doing it wrong :) Each request should create and destroy 1 database connection (or less) Once there are no hanging connections, ever, implement Apache::DBI as a simple use statement. You have accomplished 90% of what is possible. In today's modern world there are better solutions that can be controlled by the developer. DBIx::Connector being the most common I believe DO NOT USE Apache::DBI with DBI::Connector or any other database caching technique. This requires knowledge of the code!!! As an administrator I still rely and depend on Apache::DBI, even if it is unsupported. The only issue I have ever encountered is needing a specific version to talk to an Oracle 8 database Or where it is caching a cached handle I think is in the cache, I think, please let us not do this anymore... YMMV Dave -- Dave Morgan Senior Consultant, 100 Alberta Limited dave.mor...@100.com 403 399 2442
Re: [OT] AW: Unsuccessful stat on filename containing newline in RegistryCooker.pm
On 28/02/13 01:12 PM, André Warnier wrote: Randolf Richardson wrote: In truth, Microsoft is not alone there. An Apache httpd by default installs under a (created) directory named Apache Software Foundation of all things. One would think that /they/ at least would know better. But no. Why make it simple when annoying will do ? Huh, I didn't know that. I would have thought that I would of screwed up at least once and found that out. During the dot com boom I worked as production DBA for a company where the developers didn't think it necessary to produce a text version of the deployment instructions. Since I couldn't read the MSWord document on a command line unix machine it didn't get deployed that week :( Funny the next week the instructions were in text in a file called README.txt :) Still had to deal with spaces in the mount point and filename though. :( Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
Re: Connection aborted (blank line after headers?)
On 15/11/12 11:40 AM, Randolf Richardson wrote:
Snip.
Pretty well, we also get a similar problem when some IE clients download
pictures (jpg's).
Software caused connection abort at
/home/apache/metapoint/trunk/Metadot/UploadsManager.pm line 216,OUT chunk
1.\n
The code here is (edited for brevity)
open OUT, $read_file;
binmode (OUT);
print $CGI-header(%header_values);
{
local $/ = undef;
while(OUT) {
print;
}
}
[sNip]
One question: Do you need a blank line after the headers to
differentiate from the content? If $CGI-header isn't providing it,
then this could explain why the client isn't getting the image, and
raw binary data where headers are expected could be a problem too.
open OUT, $read_file;
binmode (OUT);
print $CGI-header(%header_values);
print \r\n; # --- Some systems may only need \n
{
local $/ = undef;
while(OUT) {
print;
}
}
Consider this to be a random idea that may be worth trying. I hope
this helps.
Tried in staging, broke everything :) Thanks for the idea.
After further checking the cause does appear to be the client
side aborting. We have checked with the exact clients/systems
reported and everything works properly when we do it so ..
Thanks to all for their help
Dave
--
Dave Morgan
Operations Manager, Cool Places In Canada
http://www.coolplaces.ca
dave.mor...@coolplaces.ca
403 288 8759 / 866 938 0516
Re: Connection aborted
Thanks Andre.
On 14/11/12 12:33 PM, André Warnier wrote:
Dave Morgan wrote:
Snip.
We did find the use statement and removed it. We now get
Software caused connection abort at
/home/apache/metapoint/trunk/Utility.pm line 231.
Ok, so now you know at which line of which module this issue happens.
Is that you only issue (this line in the logs) ?
Pretty well, we also get a similar problem when some IE clients download
pictures (jpg's).
Software caused connection abort at
/home/apache/metapoint/trunk/Metadot/UploadsManager.pm line 216, OUT chunk
1.\n
The code here is (edited for brevity)
open OUT, $read_file;
binmode (OUT);
print $CGI-header(%header_values);
{
local $/ = undef;
while(OUT) {
print;
}
}
Because if it is, it doesn't necessarily indicate a problem. It can happen
just because
the user clicks on some other link (or closes the window or the browser),
before your
server has had time to send it the full answer to the present request.
Because of that, there is no more client connection over which Apache can
continue to send
the response, and the next time your program tries to write something, it
triggers this
error and message in the log.
This only happens when the client is IE. From searching the net it
appears to be something to do with the http header not quite right.
No offense intended, but that sounds iffy to me; unless your $response below is
a PDF
document, in which case there was something indeed with some versions of the
Adobe PDF
plugin for IE not behaving correctly with some standard HTTP headers.
The code is quite simple:
print $CGI-header( $header_info_ref );
print $response;
-- maybe you could add or something-to-do-in-case-of-error here
The response is standard html/text, no fancy formats. I will look into catching
the error
and doing a dump.
Running curl provides the following output
Snip
The above looks like a perfectly valid request/response to me. Do you get an
error in the
logs when you do this with curl ?
No, not at all, as I mentioned the only time it happens is sometimes with IE.
:(
In short, what is your problem ?
I'm not sure there is one, however, this occurs 50-100 times a day which seems
very high to me.
Thanks for your help.
Dave
--
Dave Morgan
Operations Manager, Cool Places In Canada
http://www.coolplaces.ca
dave.mor...@coolplaces.ca
403 288 8759 / 866 938 0516
Connection aborted was ModPerl::Util::exit: (120000) exit was called at /usr/share/perl5/CGI/Carp.pm line 590
Original Message Thank you Andre, On 31/10/12 01:58 PM, André Warnier wrote: Dave Morgan wrote: How do I find out where the following call(s) are made from? See http://search.cpan.org/~dom/perl-5.14.3/lib/Carp.pm or by including the string -MCarp=verbose in the PERL5OPT environment variable. Exactly what I was looking for However, the above did not help as the call was to Carp::fatalstobrowser. We did find the use statement and removed it. We now get Software caused connection abort at /home/apache/metapoint/trunk/Utility.pm line 231. This only happens when the client is IE. From searching the net it appears to be something to do with the http header not quite right. The code is quite simple: print $CGI-header( $header_info_ref ); print $response; Running curl provides the following output [webadmin@web001 perl]$ curl -v 'http://www.coolplaces.ca/index.pl/Whitehorse' --raw * About to connect() to www.coolplaces.ca port 80 (#0) * Trying 69.90.118.205... connected * Connected to www.coolplaces.ca (69.90.118.205) port 80 (#0) GET /index.pl/Whitehorse HTTP/1.1 User-Agent: curl/7.19.7 (i386-redhat-linux-gnu) libcurl/7.19.7 NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2 Host: www.coolplaces.ca Accept: */* HTTP/1.1 200 OK Date: Wed, 14 Nov 2012 17:03:17 GMT Server: Apache Expires: Tue, 15 Nov 2011 17:03:17 GMT Pragma: no-cache Set-Cookie: sessionid=jHZgBLBfavSyJcZMIaz; path=/; expires=Mon, 13-May-2013 17:03:17 GMT Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1 55f2 !-- BEGIN portal_chooser.tt2 -- !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:v=urn:schemas-microsoft-com:vml xml:lang=en lang=en The only thing I can see is a line feed before the chunk size but I do not know if this is the issue or if so how to remove it. Any ideas? TIA Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516 -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
ModPerl::Util::exit: (120000) exit was called at /usr/share/perl5/CGI/Carp.pm line 590
Hi All. We moved our software stack to mod-perl2 six months ago and have been steadily cleaning up warnings and such. We have had problems with warning messages from regex's showing up without time information. The following issue appears similar. How do I find out where the following call(s) are made from? We are trying to remove all references to Carp from our code but that still leaves how many libraries? From my error log: [Tue Oct 30 04:40:14 2012] [error] [client 184.22.183.114] File does not exist: /home/apache/metapoint/be/html/8153.html ModPerl::Util::exit: (12) exit was called at /usr/share/perl5/CGI/Carp.pm line 590 ModPerl::Util::exit: (12) exit was called at /usr/share/perl5/CGI/Carp.pm line 590 ModPerl::Util::exit: (12) exit was called at /usr/share/perl5/CGI/Carp.pm line 590 ModPerl::Util::exit: (12) exit was called at /usr/share/perl5/CGI/Carp.pm line 590 [Tue Oct 30 04:59:51 2012] -e: Use of uninitialized value $id in concatenation (.) or string at /home/apache/metapoint/trunk/Metadot/GizmoBase.pm line 632. There are probably 200-300 pageviews in the 20 minutes covered. TIA Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
Re: ModPerl::Util::exit: (120000) exit was called at /usr/share/perl5/CGI/Carp.pm line 590
Thank you Andre, On 31/10/12 01:58 PM, André Warnier wrote: Dave Morgan wrote: How do I find out where the following call(s) are made from? See http://search.cpan.org/~dom/perl-5.14.3/lib/Carp.pm or by including the string -MCarp=verbose in the PERL5OPT environment variable. Exactly what I was looking for Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
Re: highscalability.com report
Hi All, So they did a complete rewrite without changing the hardware? My guess is that the site on the same hardware would be substantially slower. IMHO Dave On 04/04/12 08:23 AM, discobeta wrote: agree, any rewrite of old code should improve by at least 10%, even if it was written in pascal On Wed, Apr 4, 2012 at 10:21 AM, André Warnier a...@ice-sa.com mailto:a...@ice-sa.com wrote: Rolf Banting wrote: On Wed, Apr 4, 2012 at 1:31 PM, Perrin Harkins per...@elem.com mailto:per...@elem.com wrote: ... If they were to rewrite it in Perl today, *it would go up again*! - Perrin No performance anxiety there then. Particularly with a non-threaded Perl, which allows Apache to fork multiple times.. -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
Using Apache v1
On 28/02/12 11:59 AM, Randolf Richardson wrote: Snip Are a lot of people still using the version 1 series of httpd and/or mod_perl? Lots :) My codebase is apache/mod-perl independent and yet we still have v1 servers around. Hardware upgrades are scheduled for later this year or next year so we will retire the v1 stuff when the hardware gets changed out. The reason we still use v1 is it is/was a custom compiled perl/apache/mod_perl/ssl binary. All of our v2 is handled by the applicable package manager. HTH Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759 / 866 938 0516
Re: VirtualHost and ServerAlias
On 28/11/11 03:26 PM, André Warnier wrote: Vincent Veyron wrote: Snip That is why I was suggesting multipleVirtualHost sections. Snip ... This way, you can give each customer its own special things whenever they want, without interfering with your perl modules (or the other customer sites). This is what we do. The VirtualHosts section of httpd.conf is generated from the same database that generates the customer sites. We let each site control it's own users but it would be trivial to implement a single portal login for all sites. Accept user/password and redirect to the desired site. But then, you can give each one its own /images alias, pointing to a directory with its own logo, and its own /css alias, pointing to its own stylesheets etc.. You have to do it this way, otherwise you will end up in a maintenance nightmare. The only common directory we have is the perl code tree. All other files are unique to the client including the Template Toolkit files (are they perl or ..? :) HTH Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759
Re: mod_perl 2.0.5 Centos 6 rpms
On 26/09/11 11:51 AM, Fred Moyer wrote: For those Centos 6 users here looking for mod_perl 2.0.5, I rolled a few rpms. Thank you Fred, I cannot (but I'll try :) explain how useful this is to us. We started with mod-perl around 1999, I believe. We used/had to do do every thing by hand. A typical web server machine build took 2 to 4 days and involved: in rare cases make and install gcc install the base linux distribution make and install a custom kernel make and install required kernel modules make and install perl 5 make and install apache, mod-perl, mod-ssl etc. I am sure I am missing stuff. There were no central repositories. You had to visit each source site manually. The software stack was rarely updated, once you got it working you left it alone ;) Now we build a machine in 2-4 hours; - linux install - yum install *many things* - yum update Thank you once again. Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759
Re: [ANNOUNCE] Introducing GX
On 21/09/11 08:52 AM, Jan Pazdziora wrote: On Tue, Sep 20, 2011 at 03:49:53PM +0200, Jörg A. Uzarek wrote: I am happy to announce the first public (developer) release of GX, a web Snip .. Hello Jörg, Snip . Can you provide some high level comparison to (say) Catalyst? Surely there was a reason to come up with yet another web application framework, so what are the selling points? I would be extremely interested in such a comparison. Almost required for me to consider using it. Thanks Dave -- Dave Morgan Operations Manager, Cool Places In Canada http://www.coolplaces.ca dave.mor...@coolplaces.ca 403 288 8759
Re: Apache::DBI and DBIx::Class
First off, please let me apologize for the tone of my last email, It was certainly not what I intended. I have to stop having discussions about system design and philosophy after having meetings with a developer who's most intelligent statement was It works on my machine. Cold Fusion not mod-perl, and the problem is not with Cold Fusion. IMHO, worth exactly what you paid for it This was meant to refer to my opinion, not your code, sorry. On 27/06/11 09:38 PM, David E. Wheeler wrote: Yeah, too magical. I removed support for it in Bricolage years ago, though I can't remember the details of why anymore. connect_cached() worked much better for me (though it's kind of a PITA to set up). Never ran Bricolage in production. Did run a test system, ugh. I suspect the issue was with the Bricolage code, not Apache::DBI. I have never used connect_cached, never had the need. snip. I don't understand. PostgreSQL supports cursors, and you can read from them using FETCH. http://www.postgresql.org/docs/current/static/sql-fetch.html Might be my lack of knowledge of Oracle at work here, though. Postgres supports it but DBD::Pg doesn't, not with the standard DBI fetch* APIs. At least as of last year it didn't. If I didn't have to spend all my time reviewing and running other peoples code I would take the time to add the functionality. Well, DBIx::Connector does not do connection pooling (or caching), so that wouldn't be a problem. I am being unclear here. Each apache child/process will open 2 connections, one for Apache::DBI and one for DBIx::Class or DBIx::Connector. Possibly more connections if a variety of different modules are being used, each with it's own connection handling. This explains an issue I saw with a client 2 months ago where the number of open database sessions doubled with the introduction of some new code based on DBIx::Class. I believed the doubling of sessions was a symptom of poor code. Neither I nor their developers had any idea that Apache::DBI was being bypassed. Luckily it was a prototype and the issue was caught while stress testing in their staging environment. And so into the design and philosophy. As an admin I need to be able to deploy code without side effects that may adversely affect other processes or the system itself. Now at least you document your connection logic, so that if I do a quick review I can see the implications (I doubt I would actually catch it but at least you are giving me a chance :) whereas for DBIx::Class, if there is documentation about connecting I don't know where it is. Even so, I believe the logic should be if Apache::DBI use it else use my stuff I do not know the internals of DBI or the derived classes so I do not know if the above is practical. However, it is respectful of the environment it is going to run in. Writing code that specifically ignores how a system is configured is ... impolite! And yet Apache::DBI also has side effects. I revoke ALTER SESSION from any schema/user that will be accessed via Apache::DBI as there will be some unaware developer who will change the session characteristics (to get a different data format perhaps) and then will not change it back. And so the next time the connection/handle is used the code fails. Is this his fault? I don't believe so. It is a systems issue not a development issue. Yeah it was a lot of fun debugging the issue that resulted in that solution :) What I find so frustrating is that with all these magnificent tools we have now, modern hardware, screaming fast network, Apache, perl, mod_perl, the networking libraries and such I am still dealing with the same problems I had to deal with 10 and 15 years ago: - let the database do the work - do not try to configure network parameters - close all connections (file handles, RPC, serial port, network and database) - do not assume your code completes properly. - do not try to manage or allocate hardware resources, just use them - you have to share, your code is not the only thing running - the problem is not with the tools you are using, it is your code And it must be extremely frustrating to be a developer, have his systems people chew him out for some problem, when he/she has not changed anything and the problem is caused by an impolite library. And the database side is usually pretty good, the modules used for SCADA are much worse. It is inherent in the nature of perl, you have this wonderful library called CPAN, but, how do you ensure that the modules you use do what you want and nothing more? Do you really want to review (and understand) DateTime.pm? And finally back to the Cold Fusion issue : You don't get paid to make it run on your machine, you get paid to make it run on mine! I love my job, I love my job, I love my job ;) Sorry once again, Dave Best, David -- Dave Morgan Operations Manager, BorealEscapes
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On 27/06/11 02:22 PM, David E. Wheeler wrote: On Jun 27, 2011, at 1:13 PM, Fred Moyer wrote: Snip . You lost me. But really, I strongly recommend against the use of Apache::DBI. Some discussion here: http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description And having read that, I strongly recommend against the use of DBIx-Connector. But then I'm just a production DBA :) Dave -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: Apache::DBI and DBIx::Class [was Re: How do you use mod_perl for your web application?]
On 27/06/11 04:27 PM, David E. Wheeler wrote: On Jun 27, 2011, at 1:40 PM, Dave Morgan wrote: You lost me. But really, I strongly recommend against the use of Apache::DBI. Some discussion here: http://search.cpan.org/dist/DBIx-Connector/lib/DBIx/Connector.pm#Description And having read that, I strongly recommend against the use of DBIx-Connector. But then I'm just a production DBA :) Me too. What weaknesses do you see in it? What's the point of it? As far as I can see the author claims to have issues with Apache::DBI and does not like the hidden aspect. I have never experienced his issues and the hidden aspect is the good part. Apache::DBI can be deployed by an admin without consulting the developers, without affecting their code. It does not require any use statements in the source code. He claims that it does no caching across threads. Why not? If the thread uses the same connection/session state then why not use a cached connection. If it doesn't then it is the developers responsibility. Transaction management: I cannot see the point of it, however, I can see the utility to others. My personal viewpoint is that a if good commit, else rollback make what's happening explicit which when dealing with a db is extremely useful. Mind you I believe AutoCommit is a bad thing and should never have been made. My shop also use stored procs for almost everything. Wish DBD::Pg would let me read cursors, like DBD::Oracle, that's what I really need. I suppose it is all a matter of personal preference but I have found that the further removed the developer is from the database the worse they are at accessing it. DBIx::Class is the perfect example. Please spare me the hassle of trying to debug/explain/improve any code that uses that. I am sure that high quality code can be written using DBIx::Class but I have yet to see it. Oops, just realized you are the author :). Please don't take anything above personally, I just think that if you wanted transaction management, it would have been better to write a module that just does that and nothing else. Then, if a developer in my shop wanted to use it I could load it without having to worry about apache managing two connection pools. IMHO, worth exactly what you paid for it Dave Best, David -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: How do you use mod_perl for your web application?
On 15/06/11 10:01 PM, Fred Moyer wrote: I'm interested in hearing about what application frameworks (Catalyst, CGI::App, Mojolicious) are used here with mod_perl. We currently support an open source corporate CMS called Metapoint http://www.metapointcms.com (derived from Metadot, derived from the original Redhat CMS) which runs on mod_perl 1.3 and mod_perl 2.0.x without change It is fully dynamic. supporting MySQL, Postgres, SQLLite and Oracle. It easily integrates with external systems including VOIP and and source control applications. It is easily extendible so that any code can be called through wrappers in perl modules. We do nothing fancy with mod-perl, everything is done with Apache::Registry. We use a fair number of Apache modules, including mod_deflate as Fred mentioned earlier. In order to leverage other programmers work we have spent a lot of time looking at web frameworks and have a prototype running under Catalyst. We will gradually port our code ( and clean up a lot of crap) to Catalyst and I hope to be running on it within a year. Years ago we compiled apache, mod_perl and our other modules from source but now we rely on the CentOS packages. I really have no interest in perl webservers per se but I would like to hear about other frameworks that may meet our needs. Mojolicious appears to be a little underdeveloped for what we want but I am willing to be corrected on this. HTH Dave -- Dave Morgan Operations Manager, BorealEscapes http://www.borealescapes.ca dave.mor...@borealescapes.ca 403 288 8759
Re: Apache::Registry executing scripts multiple times
Thanks to all who responded. It is a development setup so no proxy or load balancer in the mix I could have sworn I had tested the behaviour in other clients, we use Opera, so I took the Apache configuration back to bare bones and still had the issue. Testing with Firefox showed the expected (single call) behaviour. Fsck, I hate browsers. Anyway, now to test a simple CGI call and see if the Opera strangeness continues Thank once again for your help Dave Perrin Harkins wrote: On Wed, Nov 4, 2009 at 5:58 PM, Dave Morgan d...@100.com wrote: I have a very simple index_test.pl script which appears to get called by Apache::Registry multiple times. I don't see anything in what you've shown us here that would explain this behavior. I think the problem is in the rest of your httpd.conf, or your proxy/load-balancer, or your test client. - Perrin -- Dave Morgan Senior Consultant, 100 Alberta Limited dave.mor...@100.com 403 399 2442
Apache::Registry executing scripts multiple times
Hi All, Please forgive me if the answer is in the docs, I looked without success. I have a very simple index_test.pl script which appears to get called by Apache::Registry multiple times. I have tested in single server mode (httpd -X) and still get the same results. The output is correct but the error_log shows multiple calls from the Apache::Registry module. While this simple program appears to get called 5 times our big one was only getting called twice, however, that did have a very noticeable effect on response time. We have also removed the Apache::Reload module without effect. Any ideas, pointers or help appreciated Dave ### Environment: Apache 1.3.37 mod-perl 1.30 perl 5.8.8 Relevent httpd.conf section: ScriptAlias /metapoint/ /home/tomcat/metapoint/trunk/ Directory /home/tomcat/metapoint/trunk AllowOverride None SetHandler perl-script PerlInitHandler Apache::Reload PerlHandler Apache::Registry Options ExecCGI Order allow,deny Allow from all /Directory index_test.pl: our $i; print pre hello $i br /; $i++; my ($package, $filename, $line) = caller(); print STDERR $package, $filename, $line, $i\n\n; print hello $i; ## output: pre hello 84 hello 85 ### error_log output: Apache::Registry, /opt/lib/perl5/site_perl/5.8.8/i686-linux/Apache/Registry.pm, 149, 1 Apache::Registry, /opt/lib/perl5/site_perl/5.8.8/i686-linux/Apache/Registry.pm, 149, 1 Apache::Registry, /opt/lib/perl5/site_perl/5.8.8/i686-linux/Apache/Registry.pm, 149, 2 Apache::Registry, /opt/lib/perl5/site_perl/5.8.8/i686-linux/Apache/Registry.pm, 149, 2 Apache::Registry, /opt/lib/perl5/site_perl/5.8.8/i686-linux/Apache/Registry.pm, 149, 3 ## -- Dave Morgan 100 Alberta Limited dave.mor...@100.com 403 399 2442
