Quoting Greg McClure <[EMAIL PROTECTED]>:
> However, when I try to run this code:
>
> * <%init>
> * use DBI;
> * my $dbh = DBI->connect("DBI:mysql:remembering", "root", "");
> * my $sth = $dbh->prepare("insert into users
> * (username, password, fir
Hello mod_perl world,
I'm running a new installation of Mason, with Apache::DBI, and everything on
the Mason side seems to be working well.
However, when I try to run this code:
* <%init>
* use DBI;
* my $dbh = DBI->connect("DBI:mysql:remembering", "root", "");
* my $sth = $dbh
Perrin Harkins wrote:
> I wrote an overview, available here:
> http://perl.apache.org/docs/tutorials/tmpl/comparison/comparison.html
I this context - I'd find it very useful if someone evaluated memcached
(http://www.danga.com/memcached/) and compared it to other methods (with
different kernel ver
>>> This tells me that if I want to write a script that builds a number
>>> of modules plus apache, I will have to answer a prompt when the
>>> script gets to the mod_perl portion of my script (unless I want to
>>> make mod_perl the last module built and use "DO_HTTPD=1" instead
>>> of doing a make
Stas Bekman wrote:
Wes Barris wrote:
Stas Bekman wrote:
Stas Bekman wrote:
Wes Barris wrote:
[...]
Notice that there is no "$apache" variable used here and I am showing
that the correct directory exists.
You are correct, Wes. There is a mismatch between the docs and the
reality.
Using APA
On Mon, Nov 24, 2003 at 05:48:43PM -0800, Stas Bekman wrote:
> > I believe that was an answer to my first question. Though I'm having
> > trouble parsing it... :-)
>
> Sorry, typing faster than thinking. I hope you don't try and upgrade your
> production server before trying things on the dev/t
Wes Barris wrote:
Stas Bekman wrote:
Stas Bekman wrote:
Wes Barris wrote:
[...]
Notice that there is no "$apache" variable used here and I am showing
that the correct directory exists.
You are correct, Wes. There is a mismatch between the docs and the
reality.
Using APACHE_SRC and DO_HTTPD=
Jay R. Ashworth wrote:
On Mon, Nov 24, 2003 at 05:18:00PM -0800, Stas Bekman wrote:
Jay R. Ashworth wrote:
I'm running a perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)', to
see if it helps me with a PerlMagick/ImageMagick version(?)
incompatibility, and in the process, it decided to upgrade
Stas Bekman wrote:
Stas Bekman wrote:
Wes Barris wrote:
[...]
Notice that there is no "$apache" variable used here and I am showing
that the correct directory exists.
You are correct, Wes. There is a mismatch between the docs and the
reality.
Using APACHE_SRC and DO_HTTPD=1 avoids the prompt:
On Mon, Nov 24, 2003 at 05:18:00PM -0800, Stas Bekman wrote:
> Jay R. Ashworth wrote:
> > I'm running a perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)', to
> > see if it helps me with a PerlMagick/ImageMagick version(?)
> > incompatibility, and in the process, it decided to upgrade my
> > mod
Jay R. Ashworth wrote:
I'm running a perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)', to
see if it helps me with a PerlMagick/ImageMagick version(?)
incompatibility, and in the process, it decided to upgrade my
mod_perl...
to 1.29.
As Stas knows, I've actually already installed 1.99 for Apac
Stas Bekman wrote:
Wes Barris wrote:
[...]
Notice that there is no "$apache" variable used here and I am showing
that the correct directory exists.
You are correct, Wes. There is a mismatch between the docs and the reality.
Using APACHE_SRC and DO_HTTPD=1 avoids the prompt:
Configure mod_per
Stas Bekman wrote:
Wes Barris wrote:
[...]
Notice that there is no "$apache" variable used here and I am showing
that the correct directory exists.
You are correct, Wes. There is a mismatch between the docs and the reality.
Using APACHE_SRC and DO_HTTPD=1 avoids the prompt:
Configure mod_perl
I'm running a perl -MCPAN -e 'CPAN::Shell->install(CPAN::Shell->r)', to
see if it helps me with a PerlMagick/ImageMagick version(?)
incompatibility, and in the process, it decided to upgrade my
mod_perl...
to 1.29.
As Stas knows, I've actually already installed 1.99 for Apache2, and
I'm wondering
Wes Barris wrote:
[...]
Notice that there is no "$apache" variable used here and I am showing
that the correct directory exists.
You are correct, Wes. There is a mismatch between the docs and the reality.
Using APACHE_SRC and DO_HTTPD=1 avoids the prompt:
Configure mod_perl with ../apache-1.3/s
Stas Bekman wrote:
Wes Barris wrote:
Ged Haywood wrote:
Hello again,
On Mon, 24 Nov 2003, Wes Barris wrote:
To avoid the two prompts:<-- This is what I am trying to do.
And this is my reply to your original question of November 17.
:( I received no response. )
Why not try using a
Wes Barris wrote:
Ged Haywood wrote:
Hello again,
On Mon, 24 Nov 2003, Wes Barris wrote:
To avoid the two prompts:<-- This is what I am trying to do.
And this is my reply to your original question of November 17.
:( I received no response. )
Why not try using a makepl_args.mod_perl fi
Ged Haywood wrote:
Hello again,
On Mon, 24 Nov 2003, Wes Barris wrote:
To avoid the two prompts: <-- This is what I am trying to do.
And this is my reply to your original question of November 17.
:( I received no response. )
Why not try using a makepl_args.mod_perl file?
Because it does n
Bruno Pommerel wrote:
[...]
It seems that when one handler gets called, the second one does not get into
play. How can I stack the handlers in the correct order ? What pre-requisite
must the perl handler comply with ?
That's correct. Your mistake is very simple:
>
> SetHandler modperl
^
[I hoped that someone will reply to this trivial mp1 question, but nobody did
for a week. Please help us spend less time answering emails, that others can
easily handle, so we can concentrate on coding and asnwering more complicated
emails. Thank you.]
Sreeji K Das wrote:
I want to access an EN
Geoffrey Young wrote:
And if you return Apache::HTTP_OK, in response handler it's
essentially an error too. If people feel really strong about it, we
can put back the special case for Apache::HTTP_OK. Though if you think
about it, it makes your life much simpler is you remember that all you
h
On Mon, 2003-11-24 at 16:17, Jordan Lederman wrote:
> The only thing that sticks in my mind about this is
> that I'm never explicitly releasing the connections. Won't I run out or
> waste/leak memory over time?
If you always use the same connection info, you should have one
connection per proces
On Monday 24 November 2003 04:13 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 15:57, Jordan Lederman wrote:
> > The my $dbh line above is located at the beginning of the file. When I
> > copy it to the beginning of the sub all is fixed!
>
> Apache::DBI tries to help you by not keeping persiste
On Mon, 2003-11-24 at 15:57, Jordan Lederman wrote:
> The my $dbh line above is located at the beginning of the file. When I copy it
> to the beginning of the sub all is fixed!
Apache::DBI tries to help you by not keeping persistent copies of
database handles that you open during startup. In thi
hi
i'm not quite ready to submit a bug report, but i'm getting close.
i can get apache to run with mod_perl. if i complile mod_perl with
PERL_INIT=1 i keep getting segvs.
i've tried running under gdb but all it does is hang there, it never
returns anything from the request. i've tried only start
Geoffrey Young wrote:
how it handles that pool underneath a prefork mpm is a mystery to me.
The same way it handles pools under threaded mpm. Interpreter pools
have nothing to do with threads. Under both mpm you create several
interpreters under the same process and then you use them, regardle
On Monday 24 November 2003 03:49 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 15:35, Jordan Lederman wrote:
> > > You just have to look at the code you run from httpd.conf and
> > > startup.pl to see if it opens any connections. The code you posted
> > > looks fine, but what's in Q2::Init?
>
On Mon, 2003-11-24 at 15:35, Jordan Lederman wrote:
> > You just have to look at the code you run from httpd.conf and startup.pl
> > to see if it opens any connections. The code you posted looks fine, but
> > what's in Q2::Init?
>
> 25 $Apache::DBI::DEBUG = 2;
> 26
> 27 my $dbh = D
On Monday 24 November 2003 03:35 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 15:11, Jordan Lederman wrote:
> > Honestly I don't yet know enough to tell you.
>
> You just have to look at the code you run from httpd.conf and startup.pl
> to see if it opens any connections. The code you posted
On Mon, 2003-11-24 at 15:11, Jordan Lederman wrote:
> Honestly I don't yet know enough to tell you.
You just have to look at the code you run from httpd.conf and startup.pl
to see if it opens any connections. The code you posted looks fine, but
what's in Q2::Init?
> If nothing useful is found he
On Monday 24 November 2003 03:05 pm, Perrin Harkins wrote:
> On Mon, 2003-11-24 at 14:54, Jordan Lederman wrote:
> > Well I've upgraded apache and mod_perl to 1.29 and I'm still having the
> > same issue.
>
> Are you opening database connections during server startup? That could
> cause this, if y
On Mon, 2003-11-24 at 14:54, Jordan Lederman wrote:
> Well I've upgraded apache and mod_perl to 1.29 and I'm still having the same
> issue.
Are you opening database connections during server startup? That could
cause this, if you have a connection open when the server forks. If
that's not it, y
On Friday 21 November 2003 08:15 pm, Perrin Harkins wrote:
> On Fri, 2003-11-21 at 19:13, Jordan Lederman wrote:
> > The page located at http://perl.apache.org/docs/1.0/guide/
> > debug.html#Handling_the__User_pressed_Stop_button__case
> > says that things can be more complex with mod_perl can
how it handles that pool underneath a prefork mpm is a mystery to me.
The same way it handles pools under threaded mpm. Interpreter pools have
nothing to do with threads. Under both mpm you create several
interpreters under the same process and then you use them, regardless
whether you are ru
Geoffrey Young wrote:
[...] in the meanwhile I'll see if I can't
prototype a perl interface for killing both processes and interpreters.
I'd suggest discussing this before spending any time prototyping things. I
can't quite see how are you going to kill interpreters and how are you going
to make
Rafael Garcia-Suarez wrote:
Stas Bekman wrote:
Again, this information could be wrong if you have more than one build of
mod_perl under the same perl tree. Consider: you build and install mod_perl.so
against a threaded httpd and then you build and install another one against a
non-threaded http
Geoffrey Young wrote:
[...]
the thing is, my understanding/reading of mod_perl core leads me to
believe that whenever _perl_ is threaded mod_perl uses the interpreter
pool approach. from mod_perl.c:
#ifdef USE_ITHREADS
static void modperl_init_clones(server_rec *s, apr_pool_t *p)
how it han
Elizabeth Mattijsen wrote:
At 10:03 -0500 11/24/03, Geoffrey Young wrote:
this all assumes that what is important is whether the mpm is threaded
or not, not whether the threads are fixed in number or can grow, etc
(which seems reasonable to me).
What _I_ am interested in, is a flag with which
Elizabeth Mattijsen wrote:
[...]
Most users don't need to know. I would like to supply my general
purpose modules, which can run in a stand-alone script, under mod_perl 1
or mod_perl 2, with sensible default behaviour. So that you don't need
to make changes to your config when you switch from
I'm a little concerned by two things here.
1. The, er, blind reliance on the mantra that because of a, b and c
then it makes sense to do d.
2. The fact that we might have to worry at all about whether we're
using a pool of interpreters or not.
I don't think it's as bad as all that.
for the
Hi all,
On Mon, 24 Nov 2003, Geoffrey Young wrote:
> [snip, snip]
> Elizabeth Mattijsen wrote:
> >
> > What _I_ am interested in, is a flag with which I could see whether it
> > would make sense to load as much as possible, rather than on demand.
>
>#ifdef USE_ITHREADS
>static void mo
Hi all,
I'm setting up an Apache-based reverse proxy (using regular the mod_proxy),
and I'd like to chain the incoming HTML flow into a mod_perl filter handler,
so that I could fix some text (mainly URLs, cos the site is built using
absolute URLs that make users send their requests w/o getti
Geoffrey Young <[EMAIL PROTECTED]> writes:
> for the record, this is exactly how apache behaves for people writing
> C modules
> - it expects a handler to return OK, DECLINED, DONE, or
> _some_http_status_all_of_which_mean_"error"
>
> so, I'd rather not go back to 200 == OK. not only does this
Perrin Harkins wrote:
On Sat, 2003-11-22 at 16:46, Stas Bekman wrote:
This week at ApacheCon in Las Vegas, Geoff, Philippe and I sat down and
created a new TODO list:
http://cvs.apache.org/viewcvs.cgi/*checkout*/modperl-2.0/todo/release?rev=HEAD&content-type=text/plain
which contains issues we
Giovani,
The problem you are having may also just be Internet Explorer. If the
browser is not set to check for newer versions of stored pages every
time it goes to the page, it can show some _very_ odd behaviours.
Here's how to verify what IE is doing:
1. Open IE.
2. Select the Tools->Inte
And if you return Apache::HTTP_OK, in response handler it's essentially
an error too. If people feel really strong about it, we can put back the
special case for Apache::HTTP_OK. Though if you think about it, it makes
your life much simpler is you remember that all you have to return in OK
or
Elizabeth Mattijsen wrote:
At 10:03 -0500 11/24/03, Geoffrey Young wrote:
this all assumes that what is important is whether the mpm is threaded
or not, not whether the threads are fixed in number or can grow, etc
(which seems reasonable to me).
What _I_ am interested in, is a flag with whic
At 10:03 -0500 11/24/03, Geoffrey Young wrote:
this all assumes that what is important is whether the mpm is
threaded or not, not whether the threads are fixed in number or can
grow, etc (which seems reasonable to me).
What _I_ am interested in, is a flag with which I could see whether
it would
Stas Bekman wrote:
Elizabeth Mattijsen wrote:
[...]
So is there a way to find out whether a prefork MPM is being used in
mod_perl while running a Perl script?
In the test suite we have this information via:
require Apache::Test;
my $mpm = Apache::Test::config()->{vars}->{mpm};
see also have_a
At 10:43 + 11/24/03, Ged Haywood wrote:
On Mon, 24 Nov 2003, Elizabeth Mattijsen wrote:
> > > is there a way to find out whether a prefork MPM is being used in
> > mod_perl while running a Perl script?
>use Config; ?
I thought Config.pm was specific for your Perl installation, and had
>
Stas Bekman wrote:
> Again, this information could be wrong if you have more than one build of
> mod_perl under the same perl tree. Consider: you build and install mod_perl.so
> against a threaded httpd and then you build and install another one against a
> non-threaded httpd. Apache::Build will
Hello again,
On Mon, 24 Nov 2003, Elizabeth Mattijsen wrote:
> > > is there a way to find out whether a prefork MPM is being used in
> > > mod_perl while running a Perl script?
> >use Config; ?
> I thought Config.pm was specific for your Perl installation, and had
> nothing to do with mod_per
Elizabeth Mattijsen wrote:
[...]
So is there a way to find out whether a prefork MPM is being used in
mod_perl while running a Perl script?
In the test suite we have this information via:
require Apache::Test;
my $mpm = Apache::Test::config()->{vars}->{mpm};
but I think what you really want to kn
At 09:39 + 11/24/03, Ged Haywood wrote:
On Mon, 24 Nov 2003, Elizabeth Mattijsen wrote:
> is there a way to find out whether a prefork MPM is being used in
> mod_perl while running a Perl script?
use Config; ?
And what would I need to be looking for in Config.pm specifically to
know the scr
Hi there,
On Mon, 24 Nov 2003, Elizabeth Mattijsen wrote:
> is there a way to find out whether a prefork MPM is being used in
> mod_perl while running a Perl script?
use Config; ?
73,
Ged.
--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modpe
The canonical way of finding out whether a module of yours is being
called in a mod_perl environment, appears to be (thanks Stas!):
use constant MP => $ENV{MOD_PERL}
? eval { require mod_perl; $mod_perl::VERSION >= 1.99 ? 2 : 1 } : 0;
giving:
- 0 not in mod_perl
- 1 in mod_perl 1, prefo
Hello again,
On Mon, 24 Nov 2003, Wes Barris wrote:
> >>To avoid the two prompts: <-- This is what I am trying to do.
> >
> >
> > And this is my reply to your original question of November 17.
> > :( I received no response. )
> >
> > Why not try using a makepl_args.mod_perl file?
>
> B
57 matches
Mail list logo