Re: Apache2::URI::unescape_url bug?

[Cees Hek]

Hi Mark,

I think the problem that David is having is that you were not very clear in
your message what the problem was.  It might have been helpful to show the
output, plus your expected output:

Log contains: 6-41913/UK1\0UK1

But I expected this: 6-41913/UK1

Unfortunately I don't have anything more to contribute except that it does
look like a bug.

Cheers,

Cees


On Sat, Jun 28, 2014 at 3:12 AM, Mark Hedges 
wrote:

> The intent was to report that Apache2::URI::unescape does not seem to work
> correctly.
>
> Mark
>
> -Original Message-
> From: David Booth [mailto:da...@dbooth.org]
> Sent: Thursday, June 26, 2014 8:43 PM
> To: modperl@perl.apache.org
> Subject: Re: Apache2::URI::unescape_url bug?
>
> On 06/26/2014 08:42 PM, Mark Hedges wrote:
> > Try in a handler.  (Apparently you cannot use Apache2::URI from command
> line?)
> >
> > use Apache2::Log ();
> > use Apache2::URI ();
> > sub handler {
> >  my ($r) = @_;
> >  my $string = "6%2D41913%2FUK1";
> >  Apache2::URI::unescape($string);
> >  $r->log_error($string);
> > }
> >
> > Log contains: 6-41913/UK1\0UK1
> >
> > ??
>
> Not sure what is the intent of your question/comment, but I often use
> uri_unescape in URI::Escape and it seems to work fine.
>
> David
>
>

Re: X-Forwarded-For

[Cees Hek]

On Mon, Oct 15, 2012 at 8:25 AM, Perrin Harkins  wrote:

> On Sat, Oct 13, 2012 at 7:41 AM, pangj  wrote:
> > In nginx's config file we have added the x-forwarded-for header.
> > With modperl (MP2) how to get this header?
>
> Use headers_in():
> http://perl.apache.org/docs/2.0/api/Apache2/RequestRec.html#C_headers_in_
>
>
As an alternative, you could use something like mod_rpaf on your backend
apache server:

http://stderr.net/apache/rpaf/

This will look for an X-Forwarded-For header and if it is from a trusted
proxy server (ie a server specified in your config), it will update the
remote client information that apache sees.  Makes ip addresses in your
access log much more useful, and means you don't need custom code to look
at proxy headers to figure out the real client ip address.

Cheers,

Cees Hek

Re: disabling directives in .htaccess files

[Cees Hek]

On Mon, Feb 13, 2012 at 11:58 PM, Aaron Knister  wrote:
> Hi Tuomo,
>
> I don't mean 80,000 virtual hosts. I have over 80k unix accounts for which 
> content is being served via mod_userdir. And I consider each one it's own 
> "site". It's critical to the environment that users be prevented from 
> specifying handlers in htaccess files in part exactly for the reasons you 
> specified. The other issue is the potential for suexec abuse. I only have one 
> perl access handler I need to use and it has no global variables.

Hi Aaron,

In the end would it not be safer to remove mod_perl all together?  You
don't mention exactly what you are doing with mod_perl so this may not
be practical, but you do mention you only have one perl access
handler.  Can that not be rewritten in C?  Is there no existing third
party C module that can do what you need (or be modified slightly to
do what you need)?

Also, you briefly mentioned  sections.  These are generally
pretty easy to get around by just pre-generating your apache.conf file
using a simple perl script and a templating module.  This is how I
understand most people create complex apache.conf files and this is
how I have always done it.

It might sound odd for someone to tell you not to use mod_perl on the
mod_perl mailing list, but I think in your situation a lighter-weight
solution would save you a lot of headaches.

Cheers,

Cees

Re: How do you use mod_perl for your web application?

[Cees Hek]

On Thu, Jun 16, 2011 at 2:01 PM, Fred Moyer  wrote:
> I'm interested in hearing about what application frameworks (Catalyst,
> CGI::App, Mojolicious) are used here with mod_perl.

We have a lot of code using CGI::App as well as a mix of in-house
custom frameworks (old legacy stuff that goes back 8 to 10 years).
All our apache/mod_perl servers sit behind three nginx boxes that do
caching, SSL offloading and content compression.  90% of what is
behind the proxies is running apache2/mod_perl2 (stock debian packages
for ease of maintenance), but there is still some apache1.3/mod_perl1
stuff hanging around too.

Some apps run through FastCGI, but the majority are mod_perl content
handlers or Registry scripts.

Cheers,

Cees

Re: CGI and character encoding

[Cees Hek]

Hi André,

There is a perlmonks post from a few years ago that explains one way
of automating this with CGI.pm.  I've used this for several years now
without problems.

http://www.perlmonks.org/?node_id=651574

Just remember that decoding params is just one part of dealing with
utf-8.  You need to worry about any data coming into or going out of
your app (reading files, retrieving from DB, send HTML out to the
browser, etc...).  The following wiki book has some great information
on how to deal with utf-8 in your perl applications (and it also
includes the CGI.pm hack from Rhesa that I linked to above in the
perlmonks link).

http://en.wikibooks.org/wiki/Perl_Programming/Unicode_UTF-8

Cheers,

Cees Hek


On Fri, Feb 25, 2011 at 8:31 AM, André Warnier  wrote:
> Hi.
>
> I wonder if someone here can give me a clue as to where to look...
>
> I am using
> Apache/2.2.9 (Debian) DAV/2 SVN/1.5.1 mod_jk/1.2.26 PHP/5.2.6-1+lenny9 with
> Suhosin-Patch mod_ssl/2.2.9 OpenSSL/0.9.8g mod_apreq2-20051231/2.6.0
> mod_perl/2.0.4 Perl/v5.10.0
>
> perl -MCGI -e 'print $CGI::VERSION'
> 3.52
>
> A perl cgi-bin script running under mod_perl, receives posted form
> parameters from a form defined as such :
>
>        "http://www.w3.org/TR/html4/loose.dtd";>
> 
>        
>        
> 
>  
>                        enctype="multipart/form-data" charset="UTF-8" method="POST">
> ...
> 
> ...
>
> (Note: the html page itself has been saved as UTF-8 by an UTF-8 aware
> editor)
>
>
> When I retrieve the above hidden field using
>
> my $chars = $cgi->param('de-utf8');
>
> the variable $chars does contain the proper UTF-8 encoded *bytes* for the
> above string (in other words, 2 bytes per character e.g.), but it arrives
> into the script /without/ the perl "utf8" flag set.
>
> If I then use this value to print to a filehandle opened as such :
>
> open(FH,'>:utf8',"myfile");
> print FH $chars,"\n";
>
> It comes out of course as .. well, I cannot type this on my keyboard, but
> anyone aware of double-encoding issues can imagine the "A-tilde Copyright
> A-tilde squiggle.. " result.
>
> I can of course convert it, by using
>
> $chars = Encode::decode('utf8',$cgi->param('de-utf8'));
>
> but it is a p.i.t.a. and I would like to know if there is a way to retrieve
> the posted value directly as UTF-8, and if yes what this depends on.
> (I cannot find a setting for instance in the CGI.pm module documentation.)
>
>
> Thanks.
> André
>
> P.S.
> Unfortunately, when the browser (Firefox 3.5.3) is posting this data to the
> server, it is posting it as something like
>
> ...
> Content-Type    multipart/form-data;
> boundary=---326972172326727
> ...
>
> -326972172326727
> Content-Disposition: form-data; name="de-utf8"
>
> ÄäÖöÜü
> -326972172326727
>
> which means that there is no charset header to the parts either.
>

Re: huge apache+mod_perl processes

[Cees Hek]

Also, if you are using something like Cache::FastMmap, your processes
will look quite large depending on the size of your cache, but this
memory is shared between children so it is not that big a deal.  From
the docs:

-
Because Cache::FastMmap mmap's a shared file into your processes
memory space, this can make each process look quite large, even though
it's just mmap'd memory that's shared between all processes that use
the cache, and may even be swapped out if the cache is getting low
usage.
-

Not sure if you are using this module, but it could explain your
process size jumping up by a large amount, but not growing
significantly after that.

Cheers,

Cees

On Wed, Oct 6, 2010 at 5:49 PM, William T  wrote:
> If you don't have an unbounded growth issue it is likely do to some
> library pulling in alot of dependencies or the creation/caching in
> memory of some large data structure.  You can preload all the
> offending libraries and see if that causes a jump in the initial
> memory allocation for you apache procs.  If not you can create a
> Handler that fires during cleanup/log phase to capture memory size
> right after each access.
>
> 2010/9/29 Eugene Toropov :
>> Greetings,
>>
>> We have a problem with huge Apache+mod_perl2 processes of 150-200 Mb in
>> size. After apache restart they are usually 40-50 Mb in size, then in a
>> minute grow up to 100-150 Mb and then some time later may grow up to 200 Mb.
>> I suspect a certain type of http queries and would like to know if there are
>> any manuals/howtos/tools to investiagate such cases.

Re: mod_perl in larger scale environments

[Cees Hek]

On Thu, Apr 15, 2010 at 4:38 PM, Cosimo Streppone  wrote:
> In data 15 aprile 2010 alle ore 05:11:15, Brad Van Sickle
>  ha scritto:
>
>> LVS does sound interesting but in your infrastructure layout aren't your
>> single LVS load balancers single points of failure?
>
> I simplified a bit too much :)
>
> Every LVS machine has a hot-spare, and you can perform
> manual or automated failover.
>
> Automated failover is said to keep your connections running
> while migrating them over to the backup lvs. We have never
> had a failure, just manual failover due to upgrades, etc...

We use LVS to load balance our reverse proxies as well as our app servers.

- 2 LVS servers using heartbeat for automatic failover (we are looking
to switch to keepalived instead of heartbeat in the future),
- 3 nginx servers which do content compression and ssl offloading as
well as caching (we don't need 3 of them but we like the redundancy
and the ability to drop one without impacting performance)
- 5 app servers running apache and mod_perl

We have just switched to nginx from squid in the last few months and
have been very happy with it.  nginx can also deliver static content
directly or act as a FastCGI frontend (relaying the requests to
backend app servers) as well as many other things.  But our main
reason for switching to nginx was the ability to offload SSL requests
and remove that complexity from the app servers (we previously used
squid as our reverse proxy which can't do SSL offloading).

nginx can do it's own load balancing as well but we preferred to use
our existing LVS infrastructure to handle that for us.

As an added bonus, LVS also load balances our mail cluster...

Cheers,

Cees Hek

Re: GnuPG module producing empty files

[Cees Hek]

On Fri, Oct 16, 2009 at 1:12 AM, Laurent MARTIN  wrote:

> Hi!
> I've recently upgraded one of my old website to mod_perl (ModPerl::PerlRun)
> and I'm not able to make GnuPG (0.10) work properly :/ As soon as I try to
> encrypt a plaintext file, I get an empty encrypted file. See below what I
> get in error log with the 'trace' option set to true:
> protocol error: expected SHM_GET_XXX got \n at
> /usr/lib/perl5/site_perl/5.8.5/GnuPG.pm line 154
>
> Any clue? Thanks in advance :)
>

This might be because the GnuPG module executes the 'gpg' binary directly to
run it's commands and it plays with STDIN, STDOUT and STDERR to do that.

I had a similar issue using GnuPG::Interface under mod_perl, but was able to
solve it by untieing and saving STDIN and STDOUT when making calls to
GnuPG::Interface (the example below calls Mail::GPG which in turn uses
GnuPG::Interface to do the grunt work):

use constant MP => ( exists $ENV{MOD_PERL} );
use constant MP2 => ( exists $ENV{MOD_PERL_API_VERSION} and
$ENV{MOD_PERL_API_VERSION} >= 2 );

# mod_perl ties STDIN and STDOUT which conflicts with GnuPG::Interface
my ( $stdin, $stdout );
if ( MP and not MP2 ) {
$stdin  = tied *STDIN;
$stdout = tied *STDOUT;
untie *STDIN;
untie *STDOUT;
}
my $mg = Mail::GPG->new( gnupg_hash_init => \%GNUPG_OPTIONS );
my $key_id = eval { $mg->query_keyring( search => $name ); };
if ( MP and not MP2 ) {
tie *STDIN,  ref $stdin,  $stdin;
tie *STDOUT, ref $stdout, $stdout;
}
die "query_keyring failed:  $@" if $@;


Note though that I only noticed the issues with mod_perl1 and not with
mod_perl2 so it may be something different that you are seeing.  Here's
hoping it gives you some hints on where to look next...

Cheers,

Cees

Re: which reverse proxy for modperl?

[Cees Hek]

On Sat, Dec 13, 2008 at 1:02 PM, Jeff Pang  wrote:
> Hello,
>
> I have a modperl application on a host which is running with heavy load.
> I have the plan to put a reverse proxy before it.
> There are two well known reverse proxy software, one is Squid, another is
> nginx.
> Which one is better for modperl application? or is there any others which
> are better than these two?

I can't tell you which is better, but I can tell you that we have been
very happy with squid.  We run four load balanced squid proxies in
front of all of our web servers and they never break a sweat.  Squid
is very efficient and can handle a massive amount of concurrent
connections with minimal hardware requirements.  We run them on old
school single proc PIII DL360s as squid barely uses the CPU and just
load them up with RAM since squid will use as much as you throw at it
to serve cached content out of RAM instead of the disk.

I'll include a few numbers below in case it helps out (these were
taken on a Saturday afternoon, so definitely not peak time).  We run
an average of 10mb/s through our internet feed where most of the
traffic is web traffic which all goes through the squids.

Load balancer connection stats (notice that one of our squids is
actually down for maintenance today)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port   Forward Weight ActiveConn InActConn

TCP  xxx.xxx.xxx.xxx:8090 lc
  -> syd-webcache-04Route   1  297882
  -> syd-webcache-02Route   1  297816
  -> syd-webcache-01Route   1  2911169
  -> syd-webcache-03Route   0  0  0

syd-webcache-01: $ uptime
 14:28:28 up 50 days, 22:17,  1 user,  load average: 0.14, 0.12, 0.09

syd-webcache-01: $ vmstat 5
procs ---memory-- ---swap-- -io -system-- cpu
 r  b   swpd   free   buff  cache   si   sobibo   in   cs us sy id wa
 0  0 750428  53064  38388 24380087 4 195  4  2 91  3
 0  0 750428  52224  38540 24484400   22243  845  620  3  4 88  4
 0  0 750416  53492  38100 24376850   27072  865  571  5  3 88  4
 1  1 750396  54108  37776 243300   190   35182  988  770  7  6 82  5

800Mhz Pentium III (Coppermine) with 2Gb RAM and stripped SCSI disks

We've been running this setup for several years now and it has never
been a bottle neck for us (mind you we have never been slashdotted
either :) )

Cheers,

Cees Hek

Re: [mp2] symbol lookup error on Debian (testing)

[Cees Hek]

On 4/27/06, Garrison Hoffman <[EMAIL PROTECTED]> wrote:
> Can anyone guide me in the right direction?
>
> I'm trying to run a recent mod_perl2 setup on Debian but I've run in to:
>
> /usr/sbin/apache2: symbol lookup error:
> /usr/lib/perl5/auto/APR/Request/Apache2/Apache2.so:
> undefined symbol: apreq_handle_apache2

Make sure you load the apreq module in your apache2 config file:

LoadModule apreq_module /usr/lib/apache2/modules/mod_apreq2.so

In debian there is a file in /etc/apache2/mods-available called
apreq.load.  Just link that to your
/etc/apache2/mods-enabled directory and restart apache2

ln -s /etc/apache2/mods-available/apreq.load
/etc/apache2/mods-enabled/apreq.load

Cheers,

Cees

Re: Apache::Session: can I have a "date" in session

[Cees Hek]

On 4/27/06, Igor Chudov <[EMAIL PROTECTED]> wrote:
> I run algebra.com with a few thousand registered users and a lot more
> unregistered. I use Apache::Session to store their session info. Right
> now I clean sessions every month. I would like to be smarter and clean
> sessions based on date information (ie remove sessions that are more
> than 3 weeks old).
>
> Can I have a date as a relational column in the sessions table?
>
> I know that I could maintain a date in the session data blob, but, it
> is expensive to use that for a few reasons.

You can have the database do all that for you using a trigger (if your
database suports it).  I have used PostgreSQL in the past to do the
following:

CREATE TABLE sessions (
   id varchar(32) NOT NULL PRIMARY KEY,
   a_session text NOT NULL,
   lm timestamp with time zone DEFAULT now()
);
CREATE FUNCTION update_session_lm() RETURNS "trigger"
   AS '
   BEGIN
 NEW.lm := ''now'';
 RETURN NEW;
   END;
 '
   LANGUAGE plpgsql;

CREATE TRIGGER update_session_lm_trig
   BEFORE UPDATE ON sessions
   FOR EACH ROW
   EXECUTE PROCEDURE update_session_lm();

The deleting the sessions becomes a simple SQL statement against the
lm column.  And this requires no code changes as everything is handled
in the database.

There is always a trade off though.  This means more load up front
when the sessions are created and/or altered.  The database has to do
slightly more work on each request to make the expiring of sessions
easy for you in the end.

Cheers,

Cees

Re: ANN: Apache2::UploadProgress

[Cees Hek]

On 4/24/06, RA Jones <[EMAIL PROTECTED]> wrote:
> Exactly what I have spent the last weekend looking for! But it looks
> like a non-starter for Win32 as it appears to have Cache::FastMmap as a
> dependency, which doesn't have a ppm and won't install as a CPAN module.
> Any way it can configured to run without FastMmap?

Hi Richard,

That is already on the TODO list.  We are planning to abstract out the
storage system so that it will be more easily plugable.  The reason
Cache::FastMmap was chosen to start with is because it is extremely
fast.  But all that is really needed is a method to share data between
all Apache children (which could be as simple as a plain text file). 
However, efficiency is critical, since the cache is written to quite
often (currently after ever bucket processed, but there are plans to
reduce the number of writes as well).

Patches are of course welcome ($CACHE only appears three times in the
module, so it shouldn't take too much to make it work with another
caching module).  Otherwise, we will hopefully get to this in the next
couple of weeks.

Cheers,

Cees

ANN: Apache2::UploadProgress

[Cees Hek]

The URL

http://cees.crtconsulting.ca/perl/modules/Apache2-UploadProgress-0.2.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/C/CE/CEESHEK/Apache2-UploadProgress-0.2.tar.gz
  size: 26235 bytes
   md5: da726fab802ba49d954c0c9042d0324b

Apache2::UploadProgress allows you to easily add progress monitors to
any of your existing upload forms without having to change any of your
backend code.  The tracking of the upload is seemslessly handled
through a PerlPostReadRequestHandler and the updates retrieved through
a content handler (either through AJAX calls, or by refreshing a popup
window).  To configure your HTML form, just add an onsubmit handler to
the form, and add an extra empty DIV tag for the progress monitor.

Usage:

In Apache:

PerlLoadModule  Apache2::UploadProgress
PerlPostReadRequestHandler  Apache2::UploadProgress

In your HTML form:

 
 
 
 
 
 
 

The support files (js/css/xsl) are automatically alliased in Apache so
you do not need to copy them into your web directory, unless you wish
to customize them (see the docs on how to do that).

All the Apache code was written by Christian Hansen, so most of the
credit goes to him.  I have helped to piece together the JavaScript,
CSS styles and XSL stylesheets to make it all work as easily and
seemlessly as possible.

There are live demos running at the following URLs:

http://cees.crtconsulting.ca/perl/examples/uploadprogress/embedded.cgi
http://cees.crtconsulting.ca/perl/examples/uploadprogress/popup.cgi

Please limit the size of the files that you are uploading to between
30 and 50K.  The upload is artificially slowed down with sleep calls
(~ 8K/sec) so that you will see the progress updates even with small
files.  All uploaded files are immediately sent to the bit bucket.

Any and all feedback is welcome (see the TODO file for things
currently in the works), and we would be happy to accept new
styles/scripts/patches to improve look and workings of this module.

Cheers,

Cees Hek

Re: [mp2] $ENV{MOD_PERL}

[Cees Hek]

Charlie Smith wrote:
Very funny.  You guys are ganging up on me.   What ever the count is, I 
get the point.
Don't take it personal.  I doubt it was intended directly at you, 
although I can understand if you thought it was.  If you follow this 
list regularly, you will notice that very few users follow the 
guidelines for posting questions on the list 
(http://perl.apache.org/bugs/).  Sometimes it is new users not knowing 
what to do (understandable), and other times it is people not willing to 
put the time in to do a little experimenting and filing a proper report 
(not really acceptable).

Stas and Geoffrey spend a tonne of their time answering questions on 
this list, and if people spent a little bit more time defining their own 
problems when posting, it would save Stas, Geoffrey and everyone else 
who commonly answers questions here a lot of time.

Most questions if properly filed can usually be answered very quickly. 
Instead we regularly see three or four responses asking for more info 
before the right piece of info is presented and the answer is given. 
More often than not, by working through the bugs page, the user ends up 
solving their own problem.

So please don't take this as an attack on you, and don't let it stop you 
from posting on this list.  Just look through the archives to see how 
responsive this list really is, and how many people do actually get the 
answers they are looking for.  Stas and Geoffrey are really just making 
jokes out of frustration, and trying to make light of a situation that 
they just have not been able to change (admittedly at your expense)

Cheers,

Cees


 >>> "Stas Bekman" <[EMAIL PROTECTED]> 03/12/04 05:42PM >>>
Geoffrey Young wrote:
 >>It should be there. If it's not, then we need to be able to reproduce it
 >>and you need to help us to do that.
 >
 >
 > I just tested with the skeleton and saw $ENV{MOD_PERL} right away.
 >
 >
 >>May be after
 >>it'll be repeated 10,000 times on this list people will remember to
 >>actually do so ;)
 >
 >
 >>Even better, submit a selfcontained bug report as Geoff suggested:
 >>http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
 >
 >
 > that makes 3 times for the skeleton in this "thread", so about 9,437 
times
 > for the bug report and 9,997 times for the skeleton left

You forget that http://perl.apache.org/bugs/ links to
http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
So it makes 9,996 times for the skeleton left. But
http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
is repeated twice (and one more time) in this email, and there is one more
link to http://perl.apache.org/bugs/. 
So the current count is:

9,989  http://perl.apache.org/~geoff/bug-reporting-skeleton-mp2.tar.gz
9,434  http://perl.apache.org/bugs/
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/  mod_perl Guide ---> 
http://perl.apache.org 
mailto:[EMAIL PROTECTED] http://use.perl.org  
http://apacheweek.com 
http://modperlbook.org  http://apache.org   
 http://ticketmaster.com 



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [DBI] Virtual hosts running startup scripts with same name

[Cees Hek]

Brett Randall wrote:
On 11 Mar 2004, Perrin Harkins wrote:

As Skylos also pointed out, a common approach for handling these
things is to have a singleton class.  If that sounds too confusingly
OO for you, just think of a simple utility function that you always
call to get a $dbh:


Wow... Perrin... That seems to have worked a charm! Thanks to yourself
and Skylos for your help. I think its time I pulled out the old Perl 5
textbook and moved to the OOP chapter :)
Glad to hear you are back on the right track (Perrin really is good at 
consisely stating and solving these problems isn't he).

If you want to look at a clean and simple framework for building OO CGI 
apps, have a look at the CGI::Application module.  Don't let the name 
confuse you, it works equally well under mod_perl (as long as you avoid 
the standard mod_perl pitfalls).

It will give you a good start, and will most likely save you from some 
common pitfalls when building OO CGI applications.  Depending on how you 
built your app, it might even be easy to move to this model (if you 
currently use a separate function for each page).  There is also a very 
helpful mailing list with an active community supporting it.

Cheers,

Cees

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: [DBI] Virtual hosts running startup scripts with same name

[Cees Hek]

Brett Randall wrote:
My problem is that SOMETIMES while accessing one virtual host, it will
appear as though it is actually pulling data from the other virtual
host's database (each virtual host uses a different database as shown
below), however the URL does not change. All the links, etc, continue
to point to the right domain, however the data is just wrong (and only
intermittently).
You are most likely running into name space conflicts.  There is quite a 
bit of documentation regarding this issue on http://perl.apache.org/. 
Here is a good starting point:

http://perl.apache.org/docs/1.0/guide/porting.html#Name_collisions_with_Modules_and_libs

Cheers,

Cees

--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Help requested with CGI.pm/Data::FormValidator/modperl bug

[Cees Hek]

Hi Mark,

What version of CGI.pm are you testing with?  There are some known 
problems with using CGI.pm and mod_perl in older versions of CGI.pm. 
Upgrade to the latest version of CGI.pm and my guess is your problem 
will go away.

Cheers,

Cees

Mark Stosberg wrote:
Hello,

I maintain the popular Data::FormValidator module, and am just starting
to use modperl myself. A couple of my users spotted a modperl-related
bug in the module. I've read the "CGI porting" document about basic
modperl traps, but I can't figure this out. 

I have a test script for the issue below. When run with "-X", it gives a
different result on the second load. However, I'm not aware of global
variables in use, and I'm not getting the "won't stay shared warning".

Any pointers to help debug this will be appreciated by myself and the
other DFV/modperl users.
BTW, the issue only happens with a CGI.pm object as input. Using a regular hashref 
doesn't trigger it.

Thanks!

	Mark



--
Report problems: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html
List etiquette: http://perl.apache.org/maillist/email-etiquette.html

Re: Jumping out of Apache/mod_perl..

[Cees Hek]

Stas Bekman wrote:
Cees Hek wrote:

Using fork is expensive.  It will use up as much memory as the current 
child is already using, so you might as well just use the current 
child to finished the processing.
That will work only if you care to wait for all processes to finish 
untill you can restart apache. forking and detaching the process allows 
you shutdown your httpd servers without affecting your long term processes.
I guess it depends on how long the process is going to take.  I should 
have mentioned that I would only use this for something that is going to 
run for a few minutes.  Long enough for a user to get anoyed and be 
tempted to press stop or refresh in the browser.

If it is truely a long term process, then it will definately be better 
to fork (or to use the other suggestion of a daemon process looking for 
new work in a specified location)

Cheers,

Cees

--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Jumping out of Apache/mod_perl..

[Cees Hek]

Jim Morrison [Mailing-Lists] wrote:
Hello,

Not sure if this isn't slightly OT, but wonder if someone can help..
It seems on topic to me...

I have a piece of one of my mod_perl apps that potentially takes quite a
while to complete.  What I would like to do is to get Apache/mod_perl to
start a second process which would do the work, return a page to the
user, and get on with the next thing.. 
Using fork is expensive.  It will use up as much memory as the current 
child is already using, so you might as well just use the current child 
to finished the processing.

What I usually do in this situation is to register a cleanup handler 
that does the actual processing.  This means the child is locked up 
until the processing is complete, but the client is free to continue 
browsing since the cleanup phase runs after the request phase has 
already finished.

Just add something like the following to your code.

$request->register_cleanup(sub { # Do your heavy processing here });

If you are going to have a lot of clients using this page 
simultaneously, then you will need to make sure that all your child 
processes aren't taken up by these long running programs.  Otherwise any 
new requests will block until a child process is avaliable.

Along with the other suggestions that have already been made, you should 
have some options to look into now...

Cheers,

Cees



--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache2 prefork children dying with WebGUI/modperl 1.99_11

[Cees Hek]

Jay R. Ashworth wrote:
Jay, you know the drill, to start with please get the core stack
backtrace and post the bug report here... http://perl.apache.org/bugs/


Well, you know, I'm hearing that a lot this month, and no, I actually
am *not* familiar with y'all's particular version of 'the drill'.
And, not being especially familar yet with either apache2 *or*
mod_perl, I'm not sure which items are important.
The link that Stas provided above explains what to do to provide a bug 
report to the mod_perl list, and it has a section on segfauls and how to 
get a stack trace.

Check it out, as there is a tonne of helpful information available 
there.  If afterwards you still have questions or problems, come back 
here and well try to help out.

All the items that are asked for in the bug report are potentially 
important, so try to include as much as possible.  A well written bug 
report that includes all info asked for generally gets answered very 
quickly on this list.  I'll admit that it requires some work on your 
part, but the payoff is generally worth...

Cheers,

Cees

--
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: yes/no questions regarding preloading Perl modules

[Cees Hek]

Quoting Bryn Dyment <[EMAIL PROTECTED]>:

> I've been reading the mod_perl performance docs, and have a few yes/no-style
> (I hope) questions.
> 
> Questions (using DBI as an example*):
> 
> 1. If my preloaded (via startup.pl) "my.pm" module uses DBI, should I
> explicitly "use DBI ()" in startup.pl as well?

You don't have to, as DBI will be loaded already by your own module.

> 2. Related to that, is it then kosher for my (non-preloaded Mason) "my.html"
> component to call a DBI method directly (e.g., "$dbH->disconnect")?  Or...

Yes.  All the code during the request cycle will be handled by the same perl
interpreter.  So since DBI will be preloaded at startup, no other module will
have to load it to use it.  However, you should still put a 'use DBI ();' at the
top of each file that uses DBI.  This will ensure that it is loaded if in the
future you remove the startup stuff.  The call to 'use DBI ();' will check %INC
to see if DBI is already loaded, and it won't do it again.

> 3. Should all calls to DBI from my ".html" components always be made
> indirectly, via (for example) the preloaded "my.pm" module (e.g. calling
> "$myH->myDisconnect")?

They can be, but don't have to be (see answer 2). 

> 4. I read about "use DBI" vs. "use DBI ()".  Does this hold true for my own
> modules, too?  (I'm asking, because I'm looking at someone's startup.pl
> file, and they're only using "()" for the CPAN modules, not their own.)

The difference between the two has to do with copying functions and/or variables
into your namespace.  The command 'use DBI;' will load DBI if necesary, and then
call the 'import' method of DBI.  It is up to DBI to decide if it wants to
'export' any of its functions into your namespace.  To see what a module
exports, you can search for EXPORT in the source code of the module or read the
module docs.

If in your own modules you do not inherit from 'Exporter', and you don't have
your own 'import' subroutine, then the () will become optional, as there is
nothing there to import into your namespace.  Most people when they write their
own modules have no need of exporting functions, and hence you doing need to
worry about the ().  It is always safe to include though.


I hope that helps.

Cheers,

Cees

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: Apache::DBI issue ...

[Cees Hek]

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, firstname, lastname)
> *  values ('Bob', 'abc123', 'John', 'Doe')");
> *
> * $dbh->execute;
> * 
> 
> I get this error:
> 
> Can't locate object method "execute" via package "Apache::DBI::db" at
> /var/www/clients/remembering/users/new_user_submit.cmp line 8.

Just a simple little DBI mistake that you made.  execute gets called on $sth
(statement handle), not on $dbh (database handle).  Just think of it as wanting
to execute the SQL statement that you just prepared.

See the DBI docs for more info.

Cheers,

Cees

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: MP2 -> newbie question, virtual hosts

[Cees Hek]

Quoting Graeme Fowler <[EMAIL PROTECTED]>:
> I've searched, and searched, for a recipe and/or method for this; I can't
> find 
> one that works :(
> 
> Am using a home-rolled Apache 2.0.48 and mod_perl 1.99_10 setup.

I could very well be wrong, but I have a feeling that the  support in
mod_perl2 is not fully completed yet.

> ...I don't get the vhosts setup; equally I don't get any errors.
> I know the Perl section gets parsed correctly (I've straced it through) and 
> I've put some debug print statements in and have got out the expected data.

Can I make a recomendation that will work equally well, and will not depend on
 sections...  Flip your strategy around, and have a plain old perl script
generate the proper Apache config files for your VirtualHosts and place those
config files in a directory that Apache automatically parses.  Then you can
tweak apachectl to first re-generate your VirtualHost config files and then
start apache.

This method is much simpler, is just as flexible, and uses less 'magic' in the
conf files.

Cheers,

Cees

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

RE: please remove me from mailing list

[Cees Hek]

Quoting Lanny Derby <[EMAIL PROTECTED]>:
> Do you really think that I haven't sent an email in the proper format and to
> the proper email address requesting to be removed? Basically, I have asked
> nicely twice. Then I emailed the moderator directly. Neither effort did any
> good. 

Well, from the amount of information you provided us with, yes I did think you
failed to try the usual channels.  You have now sent two emails to the list, and
you still haven't explained what you have tried and what you think may have gone
wrong.

So I will have to guess at what you did and what may have gone wrong!

Do you have multiple email accounts?  Are you sure you are unsubscribing from
the correct account?  Sending an email to [EMAIL PROTECTED]
should have given you a response email asking for a confirmation, or an
explaination of what went wrong.  The instructions in that email give you
information on how to unsubscribe an account that may be forwarded to you that
you do not have control over.

Now, if you didn't receive any reply from the modperl-unsubscribe
 email that you sent, then either you sent it to the wrong email, or perhaps
your SPAM filter is a little overzealous...

Also, how much time did you give the list maintainer?  I'm, sure he is quite
busy and perhaps hasn't got around to your email yet!

It is difficult for anyone to help you if you don't provide any info...

Cees


> -Original Message-
> From: Cees Hek [mailto:[EMAIL PROTECTED]
> Sent: Thursday, November 06, 2003 10:31 AM
> To: Lanny Derby
> Cc: '[EMAIL PROTECTED]'
> Subject: Re: please remove me from mailing list
> 
> 
> Quoting Lanny Derby <[EMAIL PROTECTED]>:
> 
> > 
> > I have asked to be removed from this mailing list twice now without
> success.
> > I will continue to send this email dailing until I am removed.
> 
> It might help to do a little research first instead of resorting to threats.
> 
> 
> Firstly, when you signed up for this mailing list you were given clear
> instructions on how to get help, and how to remove yourself from the list. 
> Secondly, if you look at the headers from any message you receive from this
> list, you will see some addresses that may be of help to you:
> 
> list-help: <mailto:[EMAIL PROTECTED]>
> list-unsubscribe: <mailto:[EMAIL PROTECTED]>
> list-post: <mailto:[EMAIL PROTECTED]>
> 
> And thirdly, if you go to the mod_perl website at http://perl.apache.org/
> you
> will see a link on the first page labeled 'Mailing Lists', which will lead
> you
> to http://perl.apache.org/maillist/modperl.html.
> 
> And lastly, searching for 'unsubscribe from mod_perl mailing list' on Google
> gave me the loads of helpful links in getting unsubscribed from the mod_perl
> mailinglist...
> 
> Hopefully this will give you some ideas on how to help yourself...
> 
> Cees
> 
>   This e-mail and any files transmitted with it are confidential and are
> intended solely for the use of the individual or entity to whom it is
> addressed.  If you are not the intended recipient or the person responsible
> for delivering the e-mail to the intended recipient, be advised that you have
> received this e-mail in error, and that any use, dissemination, forwarding,
> printing, or copying of this e-mail is strictly prohibited.
> 
>  If you received this e-mail in error, please return the e-mail to the sender
> and delete it from your computer. Although our company attempts to sweep
> e-mail and attachments for viruses, it does not guarantee that either are
> virus-free and accepts no liability for any damage sustained as a result of
> viruses.
> 



-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: please remove me from mailing list

[Cees Hek]

Quoting Lanny Derby <[EMAIL PROTECTED]>:

> 
> I have asked to be removed from this mailing list twice now without success.
> I will continue to send this email dailing until I am removed.

It might help to do a little research first instead of resorting to threats.  

Firstly, when you signed up for this mailing list you were given clear
instructions on how to get help, and how to remove yourself from the list. 
Secondly, if you look at the headers from any message you receive from this
list, you will see some addresses that may be of help to you:

list-help: 
list-unsubscribe: 
list-post: 

And thirdly, if you go to the mod_perl website at http://perl.apache.org/ you
will see a link on the first page labeled 'Mailing Lists', which will lead you
to http://perl.apache.org/maillist/modperl.html.

And lastly, searching for 'unsubscribe from mod_perl mailing list' on Google
gave me the loads of helpful links in getting unsubscribed from the mod_perl
mailinglist...

Hopefully this will give you some ideas on how to help yourself...

Cees

-- 
Reporting bugs: http://perl.apache.org/bugs/
Mail list info: http://perl.apache.org/maillist/modperl.html

Re: [mp2] segfault using Time::Piece and mod_perl2 on Debian

[Cees Hek]

Quoting Stas Bekman <[EMAIL PROTECTED]>:

> Cees Hek wrote:
> Are you sure that both libtime-piece-perl and modperl were compiled with that
> 
> same perl. is it possible that libtime-piece-perl was compiled against 5.8.0?

Since it was a debian package, I am not sure which perl it was compiled against,
  but you are probably right.  I figured it was a debian problem, but I was
confused as to why the segfault was happening in mod_perl (mod_perl was
definately compiled against 5.8.1 by the way), and it wasn't occuring when using
it on the command line.

Anyway, I will check with the debian guys to make sure it gets resolved.

Cheers,

Cees

[mp2] segfault using Time::Piece and mod_perl2 on Debian

[Cees Hek]

I was getting segfaults with mod_perl2 (1.99_10 on 2.0.48) on my development box
today.  After a lot of searching, it turns out it was because of a problem with
Time::Piece.

I could recreate it by placing 'use Time::Piece::MySQL' in the startup.pl file.
 This would cause the server to segfault on startup.  Time::Piece::MySQL has a
BEGIN statement that calls 'strptime' in Time::Piece, and that was triggering
the Segfault.

I thought it had to be mod_perl2, because Time::Piece worked fine on it's own
and appeared to work under mod_perl1 as well, just not under mod_perl2.

However, it turns out that by re-compiling Time::Piece the problem went away.  I
was using a debian package libtime-piece-perl 1.08-2 and debian perl 5.8.1-4
(threaded).

By reinstalling and recompiling Time::Piece using CPAN (still version 1.08), the
problem went away.

So I guess the problem is in debians libtime-piece-perl package.  

But why was mod_perl2 segfaulting, and regular CGI usage worked fine?  The
backtrace shows it occurs when mod_perl is in the destruct phase.  I thought it
worthwhile to post this, since there might be an issue in the mod_perl2 code in
the cleanup routines that are triggering the problem...

Here is the backtrace:
Starting program: /root/httpd/prefork/bin/httpd -k start
[New Thread 16384 (LWP 25873)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 25873)]
0x4034ea57 in Perl_pregfree () from /usr/lib/libperl.so.5.8
(gdb) bt
#0  0x4034ea57 in Perl_pregfree () from /usr/lib/libperl.so.5.8
#1  0x40302b97 in perl_destruct () from /usr/lib/libperl.so.5.8
#2  0x402cbbb5 in modperl_perl_destruct (perl=0x816aca0) at modperl_perl.c:130
#3  0x402b9696 in modperl_interp_destroy (interp=0x817ff38) at modperl_interp.c:128
#4  0x402b9881 in modperl_interp_pool_destroy (data=0x81335a8) at
modperl_interp.c:184
#5  0x400ad10d in run_cleanups (cref=0x8168cc0) at apr_pools.c:1994
#6  0x400ac84d in apr_pool_destroy (pool=0x8168cb0) at apr_pools.c:763
#7  0x400ac808 in apr_pool_clear (pool=0x80d7c18) at apr_pools.c:723
#8  0x08098a82 in main (argc=3, argv=0xbe14) at main.c:617
(gdb)


# perl -V
Summary of my perl5 (revision 5.0 version 8 subversion 1) configuration:
  Platform:
osname=linux, osvers=2.4.22-xfs+ti1211, archname=i386-linux-thread-multi
uname='linux kosh 2.4.22-xfs+ti1211 #1 sun oct 12 12:47:45 est 2003 i686
gnulinux '
config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN
-Dcccdlflags=-fPIC -Darchname=i386-linux -Dprefix=/usr
-Dprivlib=/usr/share/perl/5.8.1 -Darchlib=/usr/lib/perl/5.8.1
-Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5
-Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.8.1
-Dsitearch=/usr/local/lib/perl/5.8.1 -Dman1dir=/usr/share/man/man1
-Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1
-Dsiteman3dir=/usr/local/man/man3 -Dman1ext=1 -Dman3ext=3perl
-Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Uusesfio -Uusenm -Duseshrplib
-Dlibperl=libperl.so.5.8.1 -Dd_dosuid -des'
hint=recommended, useposix=true, d_sigaction=define
usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
use64bitint=undef use64bitall=undef uselongdouble=undef
usemymalloc=n, bincompat5005=undef
  Compiler:
cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64',
optimize='-O3',
cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBIAN
-fno-strict-aliasing -I/usr/local/include'
ccversion='', gccversion='3.3.2 (Debian)', gccosandvers=''
intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
alignbytes=4, prototype=define
  Linker and Libraries:
ld='cc', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
perllibs=-ldl -lm -lpthread -lc -lcrypt
libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so.5.8.1
gnulibc_version='2.3.2'
  Dynamic Linking:
dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Characteristics of this binary (from libperl):
  Compile-time options: MULTIPLICITY USE_ITHREADS USE_LARGE_FILES
PERL_IMPLICIT_CONTEXT
  Built under linux
  Compiled at Oct 24 2003 21:37:39
  @INC:
/etc/perl
/usr/local/lib/perl/5.8.1
/usr/local/share/perl/5.8.1
/usr/lib/perl5
/usr/share/perl5
/usr/lib/perl/5.8.1
/usr/share/perl/5.8.1
/usr/local/lib/site_perl
/usr/local/lib/perl/5.8.0
/usr/local/share/perl/5.8.0



Cheers,

Cees