Re: mod_perl-1.31 compilation with perl 5.14.1 fails
According to Fred Moyer f...@redhotpenguin.com on Tue, 06/28/11 at 16:50: Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 The problem here didn't appear to be 5.14 compatibility, more an issue of an inexperienced user trying to setup the latest version of httpd/perl/mod_perl. No specific 5.14 incompatibilities were identified. I am a bit surprised by your summary of my problem. I have been a user of FreeBSD since 1996 and have found the FreeBSD ports system to be an excellent resource and advantage to the UNIX world. The way I insure my systems are relatively free of security risks is to keep my operating system up-to-date and my applications rebuilt when security issues are disseminated. It is always a good idea to use the tested and packaged versions of mod_perl/httpd that come with your operating system if you are looking to deploy a production application and don't have much experience with compiling from source. Note that I most certainly am using/building the apache2 and mod_perl2 that come with my operating system. In fact, I would be had pressed to consider doing otherwise. While I am not by any measure an expert on mod_perl (1 or 2), a recent well respected application required me to build apache2 and mod_perl2 in order to run that Perl application. And when I say build here, I mean build from source using the FreeBSD ports system. Prior to my June 9th upgrade of both my operating system and all my ports (all the user-land applications), I had been running apache2 (2.1.7) along with mod_perl2 (2.0.4) successfully for months. Note that all these ports were built from up-to-date source per the excellent FreeBSD ports system meta-structure, ditto the FreeBSD 8.2-STABLE operating system. I had followed the README that came with this Perl web application (which was not in the ports tree, but came as a tar file) to configure apache2 and mod_perl2. Everything was fine and ran smoothly. Then I did the June 9th upgrade, and after the build of almost all my ports was complete, I attempted to launch apache2. This failed. :-( Since I got a strange error from apachectl(8) I immediately suspected the newer versions of either apache2 (2.1.9) or mod_perl2 (2.0.5). I had also upgraded to Perl 5.14 from the prior 5.12.3 version I had been running up until June 9th, but I didn't suspect Perl 5.14 until later. When I asked the developers of the Perl application about this error, they were clueless. I was led to suspect something in their code base after running down several suggestions both local and from various mailing lists. When the dust settled, and since I have neither the time nor the expertise to debug the issue with any of these large packages (apache2, mod_perl2, Perl, this Perl web application), I made the reluctant decision to completely redo my June 9th upgrade but this time moving back to Perl 5.12.3 to see if that one change would help. As I have reported to those venues attempting to assist me, this upgrade was successful. Note that the only thing that changed in this upgrade was the version of Perl. The apache2, mod_perl2 and the Perl web application were identical to the June 9th upgrade. In fact, not one thing had changed with the Perl web application since March 2011. The way the FreeBSD ports system operates, one can use pre-built binaries, or one can build ports from source, or a mixture of both. I always (re-)build from source (including the operating system), even when this may seen unnecessary. I do this infrequently enough that the burden is acceptable, but I do it often enough to ensure my system has no known security risks. However, I did not plan to do two ground-up rebuilds within a two week period! This experience (and some issues I had with one other FreeBSD port) made me suspect Perl 5.14 (or perhaps, the side effects in other code bases that use Perl caused by changes found in Perl 5.14). It may take several months for all the affected software packages to migrate to being compatible with Perl 5.14 but I am happy to remain at Perl 5.12.3 for the foreseeable future since everything works. Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
Re: Apache::DBI and DBIx::Class
On Jun 28, 2011, at 11:34 AM, Dave Morgan wrote:
First off, please let me apologize for the tone of my last email,
It was certainly not what I intended.
No worries. I assumed it was a caffeine shortage. That's what I suffer from
sometimes. :-)
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.
Someone put cold fusion in your espresso. That can cause a bad day no question.
IMHO, worth exactly what you paid for it
This was meant to refer to my opinion, not your code, sorry.
Ah, okay.
Never ran Bricolage in production. Did run a test system, ugh.
I suspect the issue was with the Bricolage code, not Apache::DBI.
Based on what evidence, exactly?
I have never used connect_cached, never had the need.
If you rely on Apache::DBI, you wouldn't need connect_cached, of course.
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.
What's wrong with SQL? Example:
#!/usr/local/bin/perl -w
use v5.14;
use utf8;
use DBI;
my $dbh = DBI-connect(
'dbi:Pg:dbname=try', '', '', {
PrintError= 0,
RaiseError= 1,
AutoCommit= 1,
pg_enable_utf8= 1,
pg_server_prepare = 0,
}
);
$dbh-begin_work;
$dbh-do('CREATE TABLE foo (id INT)');
$dbh-do('INSERT INTO foo VALUES (1), (2), (3), (4), (5), (6)');
$dbh-do('DECLARE getfoo CURSOR FOR SELECT id FROM foo');
my $sth = $dbh-prepare('FETCH FORWARD 2 FROM getfoo');
for (1..3) {
say $_;
$sth-execute;
while (my $r = $sth-fetch) {
say .. $r-[0];
}
}
$dbh-rollback;
Output:
1
.. 1
.. 2
2
.. 3
.. 4
3
.. 5
.. 6
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.
DBIx::Connector disables Apache::DBI, so there should only be one. If not,
there's a bug. Also, most folks who use DBIx::Connector don't use Apache::DBI
at all.
Possibly more connections if
a variety of different modules are being used, each with it's own connection
handling.
Yes, that's a risk. Don't do that.
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.
Sounds like a bug in 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.
Yes, DBIx::Class should disable Apache::DBI when it does its connecting, just
like DBIx::Connector does. Apache::DBI should still be usable if you're
connecting by some means other than DBIx::Class. But this is one of the three
raisons d'être for DBIx::Connector: Use it to connect instead of the DBI and do
your own connection caching. I believe DBIx::Class will be switching to
DBIx::Connector eventually.
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.
Yeah, that's exactly the complaint about Apache::DBI. Its entire purpose is
side-effects.
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.
Yeah, I had to do some mining to dig it out for DBIx::Connector.
Even so, I believe the logic should be
if Apache::DBI use it
else use my stuff
IIRC, I can't use Apache::DBI and still support the ability to reconnect when a
database connection has dropped. That's its second raison d'être (pings mostly
go away when you use it in fixup mode, which is recommended).
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!
Well, one could interpret Apache::DBI as doing exactly the same thing. Someone
loads it unbeknownst to you, and all of a sudden the behavior of DBI-connect
is globally changed.
And yet Apache::DBI also has side effects. I revoke ALTER SESSION from
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
On Wed, Jun 29, 2011 at 5:39 AM, William Bulley w...@umich.edu wrote: According to Fred Moyer f...@redhotpenguin.com on Tue, 06/28/11 at 16:50: Some in this thread : http://www.gossamer-threads.com/lists/modperl/modperl/103167 The problem here didn't appear to be 5.14 compatibility, more an issue of an inexperienced user trying to setup the latest version of httpd/perl/mod_perl. No specific 5.14 incompatibilities were identified. I am a bit surprised by your summary of my problem. I have been a user of FreeBSD since 1996 and have found the FreeBSD ports system to be an excellent resource and advantage to the UNIX world. My apologizes, I didn't mean to imply that you were inexperienced overall, but it seemed like you didn't have much experience with setting up mod_perl apps, specifically with startup.pl. Or whomever built the app you were installing didn't put the startup.pl program together like it is recommended in the docs. It looked like we kind of lost the 2.0.6-dev/5.14 aspect of that thread too, and after running 5.14 with 2.0.6 for a month or so now, I haven't run into any compatibility issues there.
Re: mod_perl-1.31 compilation with perl 5.14.1 fails
According to Fred Moyer f...@redhotpenguin.com on Wed, 06/29/11 at 14:04: My apologizes, I didn't mean to imply that you were inexperienced overall, but it seemed like you didn't have much experience with setting up mod_perl apps, specifically with startup.pl. Or whomever built the app you were installing didn't put the startup.pl program together like it is recommended in the docs. No need to apologize. I just wanted to clarify for any who joined in the thread late. The application in question has no startup.pl file. It is a Mason based web application and starts with an index.html file that has embedded Perl code. I have only been working with this application for a few months, and due to its large size (92 MB deployed), I have yet to understand all aspects of it. Not only am I new to mod_perl2, I am also new to Mason, sigh... :-( It looked like we kind of lost the 2.0.6-dev/5.14 aspect of that thread too, and after running 5.14 with 2.0.6 for a month or so now, I haven't run into any compatibility issues there. I was advised (by you?) to try mod_perl2 (2.0.6) just to see if 2.0.5 was at fault. I did and it wasn't. I am leaning toward some Perl 5.14 issue that exists within this large Perl web application. I have asked the developers there to try running their application under Perl 5.14 and have yet to hear any feedback on that suggestion. YMMV. BTW, several other Perl based web applications I have written are built on CGI::Application and do have what you call a startup.pl file although those (short) files are rarely, if ever, called startup.pl. Maybe I need to read more about the mod_perl2 experience. :-) Regards, web... -- William Bulley Email: w...@umich.edu 72 characters width template -|
