(unknown)

.100% proven way to make money  http://kumlai.free.fr/facebook.finance.php/?amlucky=79ed5

mod_perl and Apache::DBI - what happens on request termination

Hi,

I have a small question about the Apache::DBI behaviour:

If a http-connection drops (for any reason), while a huge amount of data 
is loaded from the database to the webserver, will Apache::DBI cancel 
the loading (means cancel the query) or will it continue loading the 
data till the end (means finish the execution of the query / not in a 
transaction) and then become ready for a new request again?

Thanks for all your answers,
Best regards,
Erik

Re: mod_perl and Apache::DBI - what happens on request termination

Erik Scholtz wrote:
> Hi,
> 
> I have a small question about the Apache::DBI behaviour:
> 
> If a http-connection drops (for any reason), while a huge amount of data 
> is loaded from the database to the webserver, will Apache::DBI cancel 
> the loading (means cancel the query) or will it continue loading the 
> data till the end (means finish the execution of the query / not in a 
> transaction) and then become ready for a new request again?
> 
> 
Maybe a beginning of an answer :

Generally speaking, a response handler responding to a client HTTP request, will not even 
know that the client<->httpd connection has been dropped, before it tries to send 
something back to the client.  Then it will get a "write to client socket error".  But 
before that, it will not know.

So, if the response handler (which runs your script/program which runs the DBI code) is 
busy doing something with the database server, but not writing anything back to the 
client, it will happily continue doing that for as long as it takes.

When it is done talking to the database server, and starts sending the data to the client, 
then it will get the error and probably crash, unless it is prepared for such errors and 
returns nicely.

Re: mod_perl and Apache::DBI - what happens on request termination

On Mon, Jun 4, 2012 at 3:43 PM, André Warnier <aw <at> ice-sa.com> wrote:
> So, if the response handler (which runs your script/program which runs the
> DBI code) is busy doing something with the database server, but not writing
> anything back to the client, it will happily continue doing that for as long
> as it takes.
>
> When it is done talking to the database server, and starts sending the data
> to the client, then it will get the error and probably crash, unless it is
> prepared for such errors and returns nicely.

After all that, Apache::DBI will issue a rollback on the database
handle IF you initiated the handle with AutoCommit turned off.

For people who don't use Apache::DBI or who start their connections
with AutoCommit on and turn it off for brief sections, I recommend
installing your own cleanup handler that will issue a rollback in case
there's an uncaught exception in your code during a transaction.

- Perrin

Re: mod_perl and Apache::DBI - what happens on request termination

André,

thanks for your answer, which confirms my observation on this: Do you 
have documents that will explain this behaviour in detail?

Greetings,
Erik

>> If a http-connection drops (for any reason), while a huge amount of
>> data is loaded from the database to the webserver, will Apache::DBI
>> cancel the loading (means cancel the query) or will it continue
>> loading the data till the end (means finish the execution of the query
>> / not in a transaction) and then become ready for a new request again?
>>
> Generally speaking, a response handler responding to a client HTTP
> request, will not even know that the client<->httpd connection has been
> dropped, before it tries to send something back to the client. Then it
> will get a "write to client socket error". But before that, it will not
> know.
>
> So, if the response handler (which runs your script/program which runs
> the DBI code) is busy doing something with the database server, but not
> writing anything back to the client, it will happily continue doing that
> for as long as it takes.
>
> When it is done talking to the database server, and starts sending the
> data to the client, then it will get the error and probably crash,
> unless it is prepared for such errors and returns nicely.

Re: mod_perl and Apache::DBI - what happens on request termination

On Tuesday, 05 June 2012 10:52:54 Erik Scholtz wrote:
> thanks for your answer, which confirms my observation on this: Do you 
> have documents that will explain this behaviour in detail?

Simple explanation, you have a single thread of execution. It can either block 
on the database or watch for events on the client socket.

I assume you want to abort the database transaction if the client closes the 
socket. This can possibly be achieved if the client isn't sending the next 
request over the same connection before the reply for the first has been 
received. However, I haven't done this yet.

First, get the file descriptor of the client socket. See
http://perl.apache.org/docs/2.0/api/Apache2/Connection.html#C_client_socket_
http://perl.apache.org/docs/2.0/api/APR/Socket.html#C_fileno_

Note, the $c->aborted flag isn't of any use here. It is set only when the 
socket is written to by the core output filter. Also, APR::Socket::fileno 
works only on UNIX-like systems where the file descriptor is a number.

Then obtain the file descriptor of the database handle. For example, if you 
are using PostgreSQL DBD::Pg provides it as $dbh->{pg_socket}.

Now, start the transaction asynchronously. See "Asynchronous Queries" in the 
DBD::Pg manual.

Read the request body. If in doubt call $r->discard_request_body.

Then you can watch both file descriptors by means of select(2) or similar (I 
prefer AnyEvent here). If it returns with the client socket ready try to 

Re: [ANNOUNCE] mod_perl 2.0.7

On Tue, 2012-06-05 at 19:49 -0700, Fred Moyer wrote:
> I'm pleased to announce the release of mod_perl 2.0.7, available at
> the following apache.org URL, along with a CPAN mirror near you
> shortly, as well as http://perl.apache.org.

w00t!

well done

> 
> This release of mod_perl contains an update for perl 5.16, see the
> change log below. Thanks to the code contributor and mod_perl dev team
> members who made this quick release possible!
> 
> http://apache.org/dist/perl/mod_perl-2.0.7.tar.gz
> http://apache.org/dist/perl/mod_perl-2.0.7.tar.gz.asc (pgp sig)
> 
> MD5 (mod_perl-2.0.7.tar.gz) = e8b3d7b6d67505a8e3050cb9042b944b
> 
> 
> =item 2.0.7 June 5, 2012
> 
> Fix breakage caused by removal of PL_uid et al from perl 5.16.0. Patch from
> rt.cpan.org #77129. [Zefram]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe <at> perl.apache.org
> For additional commands, e-mail: dev-help <at> perl.apache.org
> 

[mp2] Configure fails w/Perl 5.16.0

Re: [mp2] Configure fails w/Perl 5.16.0

There is a patch under development on the dev list
(dev <at> perl.apache.org) for httpd 2.4 compatibility. mod_perl 2.0.7 was
released yesterday, which includes the Perl 5.16 compatibility.

On Mon, Jun 4, 2012 at 11:01 AM, Bruce Pettyjohn
<bruce.pettyjohn <at> gmail.com> wrote:
> Thanks for any help in resolving this bug.  I have been using mod_perl for
> years and been happy.  I would like to take advantage of the new Apache and
> need mod_perl to be part of it.
>
>
>
> Cheers,
>
>
>
> Bruce Pettyjohn
>
>
>
>
>
> -------------8<---------- Start Bug Report ------------8<----------
>
> 1. Problem Description:
>
>
>
>
>
> I am trying to configure with Apache 2.4.2, mp 2.0.6 and Perl 5.16.0 with no
> luck.
>
>
>
> Perl was compiled with and without threads.
>
>
>
> $ ./Configure -des -Dusethreads
>
> $ ./Configure -des -Uusethreads
>
>
>
> Apache 2.4.2 was compiled with
>
>
>
> $ ./configure --prefix=/usr/local/apache2/httpd/prefork \
>
> --with-mpm=prefork \
>
> --enable-mods-shared=all \
>
> --with-included-apr \
>
> --with-perl=/usr/local/perl \
>
> --enable-ssl --enable-so
>
>
>
> The latest patch for modperl_perl.c was applied and the make process stops
> prematurely with this error note.
>
>
>
>
>
> root <at> dev2 downloads]# cd mod_perl-2.0.6
>
> [root <at> dev2 mod_perl-2.0.6]# perl Makefile.PL
> MP_APXS=/usr/local/apache2/httpd/prefork/bin/apxs
> MP_APR_CONFIG=/usr/local/apr/bin/apu-1-config
>
> Reading Makefile.PL args from  <at> ARGV
>
>    MP_APXS = /usr/local/apache2/httpd/prefork/bin/apxs
>
>    MP_APR_CONFIG = /usr/local/apr/bin/apu-1-config
>
> no conflicting prior mod_perl version found - good.
>
> Configuring Apache/2.4.2 mod_perl/2.0.7 Perl/v5.16.0
>
> [  error] Using Perl 5.016000 w/o ithreads and 'dynamic' mpm httpd.
>
> [  error] Failed requirements:
>
> [  error]   - Perl built with ithreads (build perl with -Dusethreads)
>
>
>
> The error_log file (t/logs/error_log) is non-existent.  The “logs” directory
> is missing in this distribution.  After adding the “logs” directory the
> “error_log” file was not created.
>
>
>
>
>
>
>
>
>
> 2. Used Components and their Configuration:
>
>
>
> *** mod_perl version 2.000006
>
>
>
> *** using /var/downloads/mod_perl-2.0.6/lib/Apache2/BuildConfig.pm
>
>
>
> *** Makefile.PL options:
>
>   MP_APR_CONFIG  => /usr/local/apr/bin/apu-1-config
>
>   MP_APR_LIB     => aprext
>
>   MP_APXS        => /usr/local/apache2/httpd/prefork/bin/apxs
>
>   MP_COMPAT_1X   => 1
>
>   MP_GENERATE_XS => 1
>
>   MP_LIBNAME     => mod_perl
>
>   MP_USE_DSO     => 1
>
>
>
>
>
> *** The httpd binary was not found
>
>
>
>
>
> *** (apr|apu)-config linking info
>
>
>
>  -L/usr/local/apr/lib -laprutil-1     -lexpat
>
>
>
>
>
>
>
> ***  -V
>
>
>
> *** Packages of interest status:
>
>
>
> Apache2            : -
>
> Apache2::Request   : -
>
> CGI                : 3.59
>
> ExtUtils::MakeMaker: 6.63_02
>
> LWP                : 5.834, 6.04, 6.04
>
> mod_perl           : -
>
> mod_perl2          : -
>
>
>
>
>
> 3. This is the core dump trace: (if you get a core dump):
>
>
>
>   [CORE TRACE COMES HERE]
>
>
>
> None
>
>
>
>
>
> This report was generated by t/REPORT on Mon Jun  4 17:35:24 2012 GMT.
>
>
>
> -------------8<---------- End Bug Report --------------8<----------
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

compiling mod_perl 2.0.6 for non-threaded perl