>From the docs:
> You must call clean_request_args() on the ApacheHandler object at the end of
> the request, unless you are making a new ApacheHandler object for every
> request. Otherwise bad things will happen.
>
> This is lame, so if someone thinks of a better way to do this, I'd be happy to
On 5/12/04 12:30 PM, Dave Rolsky wrote:
> On Wed, 12 May 2004, John Siracusa wrote:
>>> You must call clean_request_args() on the ApacheHandler object at the end of
>>> the request, unless you are making a new ApacheHandler object for every
>>> request. Ot
What is the status of DBI connection pooling (a la Apache::DBI) in mod_perl
2? The 2.0 guide says, "a replacement for Apache::DBI based on the tipool
will allow to reuse database connections between multiple threads of the
same process."
"will allow"? Does that mean it's not done yet? How are p
What does a DBIx::* module have to do in order to correctly call
Apache::DBI's no-op version of disconnect() when running under mod_perl with
Apache::DBI?
Below is an example that illustrates a bug I found when using a particular
DBIx:: module.
---
package MyTest;
use strict;
use Apache::DBI;
us
On Fri, 13 Aug 2004 15:32:03 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 15:25, John Siracusa wrote:
> > What does a DBIx::* module have to do in order to correctly call
> > Apache::DBI's no-op version of disconnect() when running under mod
On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
> > return 200;
>
> this is wrong - you should be returning OK (0) not HTTP_OK (200) from
> handlers if everything is swell. while 200 works in mp1 (due to mod_perl
> "guessing" what you meant) you cannot do this in mod_perl 2.0. so, if
On Fri, 13 Aug 2004 12:51:32 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
> John Siracusa wrote:
> > On Fri, 13 Aug 2004 15:38:41 -0400, Geoffrey Young wrote:
> >
> >>> return 200;
> >>
> >>this is wrong - you should be returning OK (0) not HTT
On Fri, 13 Aug 2004 12:50:44 -0700, Stas Bekman <[EMAIL PROTECTED]> wrote:
> Also make sure that you read:
>
http://perl.apache.org/docs/1.0/guide/databases.html#Opening_Connections_With_Di
fferent_Parameters
Unfortunately, setting RootClass after the connect doesn't have the desired
effect (and
On Fri, 13 Aug 2004 16:22:00 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
>> So what you're saying is that DBIx::* and Apache::DBI will simply never get
>> along because they both want to do the same thing, but use different (and
>> apparently incompatible) methods to do so?
>
> They both subc
On Fri, 13 Aug 2004 13:37:55 -0700, Stas Bekman wrote:
> Perrin Harkins wrote:
> > I would like to replace Apache::DBI with something oriented
> > towards connection management rather than porting old CGI scripts. I
> > don't like the disabling of disconnect. The old Apache::DBI could stick
> > a
On Fri, 13 Aug 2004 16:45:59 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Fri, 2004-08-13 at 16:37, Stas Bekman wrote:
> > IMHO, that should be folded into DBI::Pool
>
> I'm not really interested in tackling pooling, since I don't plan to run
> threads. All that I really want my module t
On Fri, 13 Aug 2004 17:02:27 -0400, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> > > Now that Perl has lexically scoped filehandles, there isn't any reason
> > > to explicitly call close() in most cases. ;)
> >
> > Tsk, for shame. Just wait until you forget to call close() after writing to
> > a fi
On 8/13/04 5:23 PM, Perrin Harkins wrote:
> On Fri, 2004-08-13 at 17:15, John Siracusa wrote:
>> Something tells me you haven't been bitten by this bug yet, but let me save
>> you the grief. When, say, your disk fills up and you let that file handle
>> go out of scope,
On 8/13/04 5:22 PM, Perrin Harkins wrote:
> On Fri, 2004-08-13 at 17:05, John Siracusa wrote:
>> Even without threads, wouldn't you rather have each apache child pulling
>> connections from a shared, server-wide pool rather than holding onto at
>> least one connection a
On 8/13/04 10:34 PM, John Siracusa wrote:
> In the situation I described, for example, print will happily return 1 so long
> as what it's printing fits in the output buffer, regardless of whether or not
> the data is actually going to make it to the disk.
Er, that should read
On 8/13/04 5:43 PM, Perrin Harkins wrote:
> This patch should make Apache::DBI work with subclassed DBI
> connections. The only downside is that it makes ALL of your cached
> connections subclassed if you give it one that is subclassed. Given how
> most people use DBI subclasses (for universal fu
On Fri, 13 Aug 2004 22:48:30 -0400, John Siracusa wrote:
> On 8/13/04 5:43 PM, Perrin Harkins wrote:
> > This patch should make Apache::DBI work with subclassed DBI
> > connections. The only downside is that it makes ALL of your cached
> > connections subclassed if yo
I'm looking for the best, most reliable way to determine if I'm running
under mod_perl 1 or 2, or not under mod_perl at all. I suppose I can look
at $ENV{'MOD_PERL'}, but that reminds me a bit too much of a user-agent
style opaque string that I may not be able to trust or predict. Also, what
if I
On 10/18/03 11:18 AM, Ged Haywood wrote:
> http://www.mail-archive.com/[EMAIL PROTECTED]/msg36041.html
Whoop, I think this is the post I was looking for earlier :)
http://ken.coar.org/burrow/index?month=2003-07#511
-John
I'm going to chime in, as someone working on a suite of modules that are
intended to eventually work with apache 1.x and 2.x. First, I agree with
this:
On 12/31/04 2:27 PM, Adam Kennedy wrote:
> For the moment, I'm asking just that the release of mod_perl 2.0 be put
> on hold until this problem,
On 12/31/04 4:40 PM, Stas Bekman wrote:
> Finally you don't want to use it - don't use it. It's an open source
> software, it will succeed or fail by *its own merits* and not because the
> infrastructure has a long known problem but is not willing to evolve.
>
> And to repeat this again. If you ins
On Thu, 17 Mar 2005 17:39:21, Dominique Quatravaux <[EMAIL PROTECTED]> wrote:
> For the record I use the following dubious hack as an interim measure:
>
> sub modperl_major_version {
> ~use DynaLoader ();
> ~return 1 if DynaLoader::dl_find_symbol_anywhere("XS_Apache_define");
> ~return
On Thu, 17 Mar 2005 14:57:24, Geoffrey Young <[EMAIL PROTECTED]>
wrote:
> just added to svn is $ENV{MOD_PERL_API_VERSION}, which is currently just "2".
Cool.
> what exactly is the issue you guys are trying to work around?
I'm writing code that's intended to work under both MP1 and MP2. To split
Confusing subject, simple question:
PerlSetVar MyRoot "/foo/bar"
SetHandler perl-script
PerlHandler MyModule
MyModule calls $r->dir_config('MyRoot') to get the "/foo/bar" path.
I want to ditch the "PerlSetVar MyRoot" line because it will always have
the same value as the "Location" di
On 6/8/05, Geoffrey Young <[EMAIL PROTECTED]> wrote:
> $r->location() ?
Duh, I'm an idiot. Thanks :)
-John
On 6/8/05, Dorian Taylor <[EMAIL PROTECTED]> wrote:
> $r->location will also return whatever's in a LocationMatch, Directory
> and DirectoryMatch directive, should the scope of the request lay
> in one of those. if you're simply clipping the location off the
> front of the request uri you could pot
On 10/23/07, Arshavir Grigorian <[EMAIL PROTECTED]> wrote:
> I just started using Rose::DB and have been experiencing certain
> database connectivity issues.
>
> DBD::Pg::st execute failed: ERROR: prepared statement "dbdpg_1" already
> exists
A quick google turned up this page which offers a pos
On 10/23/07 5:17 PM, Perrin Harkins wrote:
> On 10/23/07, John Siracusa <[EMAIL PROTECTED]> wrote:
>> I've had some bad experiences with passing database handles around in
>> pnotes.
>
> It should be safe to do that. One thing to remember is that pnotes
> take
On 10/23/07 6:42 PM, Arshavir Grigorian wrote:
> Does Rose::DB bypass Apache::DBI if connect_on_init() hasn't been called?
Rose::DB just calls DBI in a straightforward manner. It doesn't do anything
fancy. (Also, it's surprisingly hard to "bypass" Apache::DBI; it's not
something that will happen
On 10/24/07 10:39 AM, Perrin Harkins wrote:
> In mod_perl 1, you can only store pnotes at a request level, so a
> subrequest has separate pnotes. This meant you would need to lookup
> the parent request ($r->main) to get your pnotes. In mod_perl 2, you
> have the option of using pnotes on a conne
On 12/21/07 2:32 AM, Andreas J. Koenig wrote:
> I fear I do not understand enough of mod_perl to volunteer to make a
> release.
Me neither, but have you at least contacted the mod_perl maintainers about
this? Perhaps you could file a bug on rt.cpan.org even?
-John
Is there some hook or other way to run some Perl code just before the very
first fork() of the original apache process? The "manual" way is to put the
code at the very end of the last Perl file evaluated during server start-up,
but I'm looking for some way that I can do that on behalf of the user
On Tue, Nov 11, 2008 at 1:27 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
> On Nov 11, 2008, at 10:15 AM, Perrin Harkins wrote:
>
>> I'm fine with people using other open source tools to get where they
>> want to go but the justifications they make about mod_perl being
>> heavier or slower rarel
On Tue, Nov 11, 2008 at 1:15 PM, Perrin Harkins <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 11, 2008 at 12:49 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
>> To a certain degree, Apache/mod_perl is a victim of the success of HTTP. It's
>> fairly easy to implement a new HTTP server, so there are a l
On 9/11/09 6:57 PM, Jonathan Swartz wrote:
>> PerlSetVar ReloadAll On
>>
>> PerlSetVar ReloadHttpds My::Moose
>>
>> So that modules in ReloadHttpds terminates existing user httpd
>> processes and causes the server to fork off new httpd children.
>
> But again, if Apache::Reload runs as part of t
35 matches
Mail list logo
