Re: mod_perl 2.0 $r->content and how to integrate GET, POST, multiple select data
Aren't you looking for APR::Request it should provide anything you need
doesn't it?
http://search.cpan.org/~joesuf/libapreq2-2.06-dev/
Tom
Ashtanga Yogi wrote:
> In http://www.stonehenge.com/merlyn/LinuxMag/col66.html (a recent intro to
> mod_perl by Randal Schwartz),
> he shows how to preserve query parameters which might be listed multiple
> times by calling $r->content
>
> use CGI;
>
> my $q = CGI->new($r->args . $r->content);
> my @name = $q->param("name");
>
> However, ModPerl::MethodLookup shows ->args() as part of RequestRec but not
> ->content
>
> For my mod_perl development, I really had no interest in using CGI.pm at all,
> but, the 2.0 docs on mod_perl don't seem to currently have any examples of
> getting GET and POST data as well as multiple select query data, so I decided
> to try this approach. And I certainly don't want a piece-meal approach in
> mod_perl: I want to make one API call and provide one query parameter and
> get back what I want, regardless of location.
>
> So, the 2 questions are:
>
> 1 - how to get the above method using CGI to work under mod_perl 2.0
> 2 - how to drop the above method and use something in mod_perl 2.0 which is
> just as convenient
>
>
>
signature.asc
Description: OpenPGP digital signature
Re: Fwd: PAUSE indexer report OPI/Apache-DBI-Cache-0.06.tar.gz
On Sun, Dec 04, 2005 at 10:45:03AM +0100, Enrico Sorcinelli wrote: > > Have you contacted Apache::DBI maintainer in order to integrate your work with > that module? I have the distinct impression that the maintainer is too busy to respond. If I am not mistaken Philippe has tried this with no result. I as well have approached Ask with no reply whatsoever. Please don't take this as an impolite comment, just an observation. Regards, Frank
Re: Fwd: PAUSE indexer report OPI/Apache-DBI-Cache-0.06.tar.gz
On Mon, 5 Dec 2005 11:47:59 +0100 Frank Maas <[EMAIL PROTECTED]> wrote: > On Sun, Dec 04, 2005 at 10:45:03AM +0100, Enrico Sorcinelli wrote: > > > > Have you contacted Apache::DBI maintainer in order to integrate your work > > with > > that module? > > I have the distinct impression that the maintainer is too busy to respond. > If I am not mistaken Philippe has tried this with no result. I as well > have approached Ask with no reply whatsoever. Please don't take this as an > impolite comment, just an observation. Hi Frank, on 20 Aug 2005, Philip M. Gollucci take over the maintenance of Apache::DBI :-) - Enrico
apache2::upload with reverse_proxy
Hi, I did have two seperate machines in my test environment. A lite weight front end with just apache2 and a back end with mod_perl. File uploads worked fine using apache2::upload Now I have a front_end and mod_perl on the same machine but file uploads stopped working front_end with just one machine is Apache/2.0.55 (Unix) mod_ssl/2.0.55 OpenSSL/0.9.8a and the back_end on the same machine is Apache/2.0.55 (Unix) DAV/2 PHP/4.4.1 mod_apreq2-20050712/2.1.3-dev mod_perl/2.0.2 Perl/v5.8.5 Now when I try to upload a file it doesn't work. I get no errors in either logs files. What is the reason for it to stop working? Both apache process are running as same user 'nobody' Regards Scott
RE: Maintainer of Apache::DBI [was: ...OPI/Apache-DBI-Cache-0.06.tar.gz]
(put back on the list as per request) >> On Mon, Dec 05, 2005 at 12:11:29PM +0100, Enrico Sorcinelli wrote: >>> On Mon, 5 Dec 2005 11:47:59 +0100 >>> Frank Maas <[EMAIL PROTECTED]> wrote: >>> >>> on 20 Aug 2005, Philip M. Gollucci take over the maintenance of >>> Apache::DBI :-) >> >> Is that the case...? 'cause when I ask CPAN, it tells me >> >> Module Apache::DBI (A/AB/ABH/Apache-DBI-0.94.tar.gz) >> >> Module id = Apache::DBI >> DESCRIPTION Persistent DBI connection mgmt. >> CPAN_USERID ABH (Ask Bjoern Hansen <[EMAIL PROTECTED]>) >> CPAN_VERSION 0.94 CPAN_FILEA/AB/ABH/Apache-DBI-0.94.tar.gz >> DSLI_STATUS MmpO (mature,mailing-list,perl,object-oriented) >> MANPAGE Apache::DBI - Initiate a persistent database >> connection >> >> which is kind of cumbersome since I got Philippe's 0.99xx already on >> the system, but am never able to update automatically... Well, this >> is getting off topic, so only to you and Philippe. >> >> Regards, >> >> Frank > > Hi Frank, > > I don't think that Apache::DBI CPAN indexing problem is off topic, > since I think that mod_perl community doesn't known it too much. > > So, I suggest you to repost also to modperl list. > > - Enrico
Re: Fwd: PAUSE indexer report OPI/Apache-DBI-Cache-0.06.tar.gz
Hi, sorry for the late answer. I'll try to explain what Apache::DBI and my module does. Maybe it will then be clear why my module cannot be compatible with Apache::DBI and why it therefore must be an extra module. In fact I thought at first to create a quick patch to Apache::DBI. It would have saved a lot of work. With Apache::DBI when DBI->connect is called the first time for a given DSN an attributes a new DBI handle is created and stored in %Connected. When DBI->connect is called a second time with the same parameters Apache::DBI finds a matching handle in %Connected and reuses it. Additionally, at request cleanup time Apache::DBI checks all handles created with AutoCommit=>0 and rolls a possibly pending transaction back. From this logic there can only be one handle for a given set of attributes (and DSN). And this makes sense for Apache::DBI because there is no notion whether a handle is really in use or not. Further, Apache::DBI provides a C subroutine that allows code outside Apache::DBI to access %Connected and thus to all cached handles. With Apache::DBI::Cache on the other hand handles are cached only when they are free. When DBI->connect is called the module tries to find a matching free one in the cache. If that fails a new one is created. Then the handle is returned to the caller and Apache::DBI::Cache do NOT hold any references to the handle. There are 2 occasions when a handle can go out of use. Firstly, when C is called or when the handle is simply forgotten. The second event can be caught with a C method. Apache::DBI::Cache catches these 2 events and puts the handle in the cache preventing it from really get disconnected. In the DESTROY case it adds a reference and the handle will not be touched by the garbage collector. Now you can have as much identical connections to a DB server as you need. For example you can connect 2 times with AutoCommit=>1 then start a transaction on one handle and use the second for lookups. When the lookup fails (missing table, missing column etc.) it does not disturb your transaction. Of course by adding a dummy attribute this could also be achieved with Apache::DBI. But suppose a big installation with quite a number of independent developers. Dummy attributes can be quite error-prone. Further, maybe you want to do something even a transaction over the lifetime of a connection. This cannot be done with Apache::DBI. (I don't say that would be good practice.) My module cannot provide C since it does not know them all. Torsten On Sunday 04 December 2005 10:45, Enrico Sorcinelli wrote: > On Wed, 30 Nov 2005 13:37:56 -0500 > > Perrin Harkins <[EMAIL PROTECTED]> wrote: > > Hi Torsten, > > > > A few comments on the new module: > > > While Apache::DBI caches connections at connect time this module caches > > > them only at disconnect or DESTROY. > > > > Why? I don't understand the value in doing this. > > > > > Apache::DBI does not distinguish between currently used and free > > > connections. Hence, it cannot support multiple identical connections. > > > This module does. > > > > To get multiple connections to the same database with Apache::DBI, you > > just need to add something unique to the attributes hash in your connect > > string. > > > > > Apache::DBI resets all connections at request cleanup. > > > Apache::DBI::Cache intercepts disconnect or DESTROY events to do that. > > > > For the rollback you mean? That's not good. The purpose of the > > automatic rollback in Apache::DBI is to reset the connection when your > > code dies due to a bug. There won't be any disconnect or DESTROY called > > in that situation. > > > > > Apache::DBI::Cache includes the DBD driver name in the caching key > > > while Apache::DBI does not. Hence with Apache::DBI the following 2 DSNs > > > can result in the same DBI handle: dbi:mysql:dbname=db and > > > dbi:Pg:dbname=db > > > > Sounds like a good idea. > > > > > I wrote this module because Apache::DBI had changed the logic of our > > > programs. > > > > How so? > > > > > Further, we had really much DSNs mostly MySQL in various configuration > > > files all using different syntaxes to connect to a dozen databases on 2 > > > database hosts. > > > > I think the normalization of connect strings is a good idea. It could > > be useful on its own, for people who don't use mod_perl. > > > > - Perrin > > Hi Torsten, > > as Perrin says, your module has some nice things and some that I don't > understand too much me too. > > Apache::DBI is a well known and famous module largely used by mod_perl > users. IMHO, trying to improve that instead of writing a new one would have > been the better thing for the mod_perl community. > > Have you contacted Apache::DBI maintainer in order to integrate your work > with that module? > > by > > - Enrico
Re: Fwd: PAUSE indexer report OPI/Apache-DBI-Cache-0.06.tar.gz
On Mon, 2005-12-05 at 17:51 +0100, Torsten Foertsch wrote:
> With Apache::DBI::Cache on the other hand handles are cached only when they
> are free.
Now I understand -- you are using the cache as a way to mark unused
handles. This is kind of confusing. It would be easier to understand
if you always kept them in the cache and just have a "in_use" attribute
that you set for each one or something similar. In fact you already
seem to have one with your "disconnected" attribute.
You actually could do all of this with a wrapper around Apache::DBI. It
could keep track of in-use handles and create new ones when needed by
adjusting a dummy attribute.
> There are 2 occasions when a handle can go out of use. Firstly,
> when C is called or when the handle is simply forgotten. The
> second event can be caught with a C method.
DESTROY is unreliable. Scoping in Perl is extremely complicated and
modules like Apache::Session that rely on DESTROY for anything are a
source of constant problems on this list. People accidentally create
closures, accidentally return the object into a larger scope that keeps
it around longer, put it in global variables, etc. I would avoid this.
> Now you can have as much identical connections to a DB server as you need.
> For
> example you can connect 2 times with AutoCommit=>1 then start a transaction
> on one handle and use the second for lookups.
This sounds like a bad idea to me, since the second one won't be able to
see things added by the first one. There may be some other useful case
for this though.
> My module cannot provide C since it does not know them all.
I think DBI will provide something equivalent soon.
The only serious issue I see with this module is the way you handle
rollbacks. This will only do a rollback if you call disconnect. What
happens if your code hits an unexpected error and dies without calling
disconnect? No rollback, and potentially a transaction left open with
questionable data and possibly locks. (You can't rely on the object
going out of scope for safety.) Apache::DBI prevents this with its
cleanup handler, although that is somewhat flawed as well if you connect
with AutoCommit on and then turn it off.
Hmm... It also does direct hash accesses on the $dbh object for storing
private data. That's a little scary. The $dbh->{AutoCommit} stuff in
DBI is special because it uses XS typeglob magic. Doing your own hash
accesses is not really safe.
- Perrin
Re: Fwd: PAUSE indexer report OPI/Apache-DBI-Cache-0.06.tar.gz
On Monday 05 December 2005 18:57, Perrin Harkins wrote:
> On Mon, 2005-12-05 at 17:51 +0100, Torsten Foertsch wrote:
> > With Apache::DBI::Cache on the other hand handles are cached only when
> > they are free.
>
> Now I understand -- you are using the cache as a way to mark unused
> handles. This is kind of confusing. It would be easier to understand
> if you always kept them in the cache and just have a "in_use" attribute
> that you set for each one or something similar. In fact you already
> seem to have one with your "disconnected" attribute.
I cannot cache the handle on connect. Since then it would never be DESTROYed.
The "disconnected" attribute is used to prevent double disconnect (to keep
statistics correct).
> You actually could do all of this with a wrapper around Apache::DBI. It
> could keep track of in-use handles and create new ones when needed by
> adjusting a dummy attribute.
Yes, but then again I won't catch the DESTROY event. This leads to the request
cleanup handler what I would like to prevent.
> > There are 2 occasions when a handle can go out of use. Firstly,
> > when C is called or when the handle is simply forgotten. The
> > second event can be caught with a C method.
>
> DESTROY is unreliable. Scoping in Perl is extremely complicated and
> modules like Apache::Session that rely on DESTROY for anything are a
> source of constant problems on this list. People accidentally create
> closures, accidentally return the object into a larger scope that keeps
> it around longer, put it in global variables, etc. I would avoid this.
I would not say that. DESTROY is reliable in that it does exactly what it
should. It is called when the last reference to an object goes away.
And as you said, DESTROY is used only a last resort to put a handle back into
the cache. Normally, disconnect would be called.
The module was developed to be less invasive than Apache::DBI. When an
application runs without Apache::DBI and without Apache::DBI::Cache and there
are closures that prevent handles from beeing forgotten then with
Apache::DBI::Cache that should remain the same. On the server it was first
used there where a lot of singleton DBI connections stored in global
variables. In some cases resuing them for anything else led to errors. (I
don't know why.)
If you need to store handles in global variables you can try
C to put them back into the cache at request
cleanup. Here the PerlCleanupHandler is back, ;-). If it works, ok, if not go
and use the global handle.
> > Now you can have as much identical connections to a DB server as you
> > need. For example you can connect 2 times with AutoCommit=>1 then start a
> > transaction on one handle and use the second for lookups.
>
> This sounds like a bad idea to me, since the second one won't be able to
> see things added by the first one. There may be some other useful case
> for this though.
That example was used as an example. And in fact it can be useful. I have seen
applications where for each month a new set of tables was created. The fact
that a table did not exist simply meant 0 for each of it's columns. If a
select had to check something for a particular range of months then some
tables could not exist. Within a transaction that would cause the whole
transaction to abort.
> The only serious issue I see with this module is the way you handle
> rollbacks. This will only do a rollback if you call disconnect. What
> happens if your code hits an unexpected error and dies without calling
> disconnect? No rollback, and potentially a transaction left open with
> questionable data and possibly locks. (You can't rely on the object
> going out of scope for safety.) Apache::DBI prevents this with its
> cleanup handler, although that is somewhat flawed as well if you connect
> with AutoCommit on and then turn it off.
See above, it was not my goal to make an application better than it is. If it
was developed with global handles, well ... so be it. Oh, I forgot to say the
module was not developed with Registry scripts in mind. I had originally a
bunch of handcrafted modperl applications that created handles, disconnected
them arbitrarily. Some used singletons others connect/disconnect for each
request. That led to 2 problems a) the total amount of connections to some
mysql databases was quite great (several thousand) and b) the frequent
connect calls led to problems on a DNS server (as I was told).
> Hmm... It also does direct hash accesses on the $dbh object for storing
> private data. That's a little scary. The $dbh->{AutoCommit} stuff in
> DBI is special because it uses XS typeglob magic. Doing your own hash
> accesses is not really safe.
You mean $dbh->{$PRIVATE} is wrong? Maybe because $dbh->{$PRIVATE}||=... would
not work? That has been avoided in the code. What else is wrong with that?
And how can it be cirumvented?
Thanks, Perrin, for reviewing my code,
Torsten
Re: Fwd: PAUSE indexer report OPI/Apache-DBI-Cache-0.06.tar.gz
On Mon, 2005-12-05 at 20:44 +0100, Torsten Foertsch wrote:
> I would not say that. DESTROY is reliable in that it does exactly what it
> should. It is called when the last reference to an object goes away.
The issue is that things don't always go out of scope when people think
they do. We've all seen this with Apache::Session problems and I've
also seen it with Class::DBI using weak references to keep an "object
index." People are often surprised to discover they have done something
that prevents an object from going out of scope. It's just a side
effect of Perl's complexity.
> See above, it was not my goal to make an application better than it is. If it
> was developed with global handles, well ... so be it.
This is different from Apache::DBI though. With Apache::DBI, the
rollback will get called as long as something called connect() for that
handle during the request. With your module, if disconnect() and
DESTROY don't happen (because something died, but the handle didn't go
out of scope for some reason), no rollback will happen. It probably
seems like more of an issue to me than to you because you trust DESTROY
to happen and I don't.
> You mean $dbh->{$PRIVATE} is wrong? Maybe because $dbh->{$PRIVATE}||=...
> would
> not work? That has been avoided in the code. What else is wrong with that?
In general, it's not a good idea to access the internals of someone
else's class implementation. DBI does allow it, but has certain rules
about namespaces. See the section "General Interface Rules & Caveats"
in the DBI docs. There are also other ways to store private attributes
without touching the object itself, like making your own container
object to hold the handle and the metadata.
- Perrin
Re: Maintainer of Apache::DBI
> On Mon, 5 Dec 2005 16:52:30 +0100, "Frank Maas" <[EMAIL PROTECTED]> said: >> I don't think that Apache::DBI CPAN indexing problem is off topic, >> since I think that mod_perl community doesn't known it too much. >> >> So, I suggest you to repost also to modperl list. Thanks, I've fixed that on the CPAN indexer. It will take a few hours to propagate, of course. -- andreas
The apache CPU race..
PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE 548 httpd 73.3% 0:45.79 6291 404 26.5M 44.6M 32.4M 110M 547 httpd0.0% 0:00.00 1 9 231 5.81M 39.1M 708K 59.6M This is the status aprox. 40 sec after the last page was delivered. (if i turn off other stuff running here it goes towards 100% consuming.) Around 60s after last page was done the process knocks it off and goes back to idle... I kinda hope for a bit more traffic than 1 per min.. so any help would be appreciated. darwin 10.3.9 / apache 2.2.0 w/ worker / mod_perl 2.0.2 / perl 5.8.1 Had same issue on the apache 2.0.55 version in fact... ~ F
Re: The apache CPU race..
Without seeing any code about what you are doing we cann't say much. Tom > --- Ursprüngliche Nachricht --- > Von: Fredrik Lindmark <[EMAIL PROTECTED]> > An: modperl@perl.apache.org > Betreff: The apache CPU race.. > Datum: Tue, 6 Dec 2005 03:36:05 -0200 > >PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE > =20= > > VSIZE >548 httpd 73.3% 0:45.79 6291 404 26.5M 44.6M 32.4M > =20= > > 110M >547 httpd0.0% 0:00.00 1 9 231 5.81M 39.1M 708K > =20= > > 59.6M > > This is the status aprox. 40 sec after the last page was delivered. > (if i turn off other stuff running here it goes towards 100% consuming.) > Around 60s after last page was done the process knocks it off and goes=20= > > back to idle... > > I kinda hope for a bit more traffic than 1 per min.. so any help would=20= > > be appreciated. > > darwin 10.3.9 / apache 2.2.0 w/ worker / mod_perl 2.0.2 / perl 5.8.1 > Had same issue on the apache 2.0.55 version in fact... > > ~=A0F > > -- Telefonieren Sie schon oder sparen Sie noch? NEU: GMX Phone_Flat http://www.gmx.net/de/go/telefonie
Re: [mp2] Windows nmake test results
On Fri, 2 Dec 2005, Goehring, Chuck wrote: Gentlemen, Having some problems building as shown below. Should I go ahead and file a bug report? On Win 2000, "nmake test" finishes like below. Log indicates some files are missing near the end. What do you suggest? Failed Test Stat Wstat Total Fail Failed List of Failed --- t\apr-ext\finfo.t 272 7.41% 10 24 t\apr\finfo.t 282 7.14% 11 25 Thanks for the report, Chuck. This is a failure in the ctime() tests of finfo - the difference between the expected and obtained value is 3600 s. It may be that on Win32 this test isn't reliable (it was passing at some point in the not-so-distant past) - I'll look into this some more. Thanks again. -- best regards, randy kobes
