Re: Apache2::Request appears to not capture the full POST:ed value

[McCarrell, Jeff]

Andre is correct.  Semi-colon is a valid query string separator,
in addition to ampersand &.
HTTP 1.x being so widely deployed, it is very hard to change the spec.
So supporting semi-colon is a W3C recommendation.

C.f. http://en.wikipedia.org/wiki/Query_string

-- jeff

On 10/10/11 2:11 PM, "André Warnier"  wrote:

>I believe that at some point, a bare semi-colon was/is considered as an
>alternative to
>"&", to separate post parameters.
>

Re: ModPerl::RegistryLoader

[McCarrell, Jeff]

I am not sure if this directly applies to your issue, but I got segfaults
in DBI when I just opened the DB handle once in the parent, reusing the
DBH in child processes (a bug).  The issue went away when I ensured that
every child process did its own DBI->connect.
HTH


On 7/22/11 11:17 AM, "Jiří Pavlovský"  wrote:

>I use Apache::DBI and initialize the db connection in startup.pl like so
>

Re: Best approach to store Application Configuration

[McCarrell, Jeff]

Naming the path to the config file in an httpd conf will certainly work.
In my case, the path the config file is hard coded in the method that reads the 
config as it is not something that changes.

Here is on of my httpd conf file (a separate file loaded in the http 
configuration directory so your install process doesn't have to change the 
actual httpd.conf):
PerlModuleYour::App
PerlPostConfigHandler Your::App::httpd_start


SetHandler modperl
PerlResponseHandler   +Your::App

# Apache::DBI needs GlobalRequest
PerlOptions +GlobalRequest


The httpd_start method gets called at apache startup time, and reads the config 
in once.

Also, one other possible advantage to YAML is that YAML is not perl, so if you 
have a mixed language env,
it is easy to share/move/port your config to the language of your choice.
YAML has pretty good support across the common languages you will find in the 
LAMP world.

BTW, if you haven't already done so, I recommend becoming familiar with the 
handlers and their life cycles:
http://perl.apache.org/docs/2.0/user/handlers/server.html
http://perl.apache.org/docs/2.0/user/handlers/http.html#HTTP_Request_Cycle_Phases

Have fun,

-- jeff

From: Jerry Pereira mailto:online.je...@gmail.com>>
Date: Mon, 11 Jul 2011 16:41:13 -0500
To: Jeff McCarrell mailto:jmcca...@akamai.com>>
Cc: "modperl@perl.apache.org" 
mailto:modperl@perl.apache.org>>
Subject: Re: Best approach to store Application Configuration

please correct me if I am wrong, I should be using tool like 
YAML/Config::General for application configuration storage and reteieval, and 
load them on startup using startup.pl script? That would 
mean i will have to store the name of configuration file some where (probabaly 
in mod_perl configuration block in httpd.conf).

Re: Best approach to store Application Configuration

[McCarrell, Jeff]

Hi Jerry.

I went through a couple of different approaches before settling on using YAML 
files to describe configuration.
There are several nice properties of YAML IMO, not least of which is arbitrary 
nesting so the config can closely match the software being configured.
Here is a sanitized example of my production config:

# -*- mode: perl -*-
# configuration file for XXX
config: { version: 1 }

# XYZ configuration
#  across the entire XXX tier
xyz: {
  # enable / disable all ...
  feature_X_enabled: true,

  # name of cookie(s) to emit: [xx, yy, zz]
  emit_cookies: [ xx ]

  # substructure configuration
  sub_structures: {
disabled: {
  foo: [],
  bar: [],
  baz: [],
}
  }
}

There are several YAML readers available; I preferred YAML::XS because of its 
speed and correctness.
My apps need to run a long time, so they poll the configuration file every n 
seconds, and reload it if needed.
Overall, I was pretty happy with this approach, and so were the operations 
folks who have to configure the settings in production.

HTH,
-- jeff

From: Jerry Pereira mailto:online.je...@gmail.com>>
Date: Mon, 11 Jul 2011 16:07:58 -0500
To: "modperl@perl.apache.org" 
mailto:modperl@perl.apache.org>>
Subject: Best approach to store Application Configuration

Hi All,

I am new to mod_perl (a java developer). I would like to know the best approach 
to store and retrieve Applicaiton configurations that is accessible to all 
packages in my mod_perl application.

My application configuration includes - Database details, Template mapping, 
LDAP configuration details etc. I would like my to load all these 
configuratoins when my application starts and then on, i should be able to 
access these configuration from anywhere.

For Example:
my $dbDetails = ConfigUtil->getDBDetails(); //returns reference to hash
my dbUser = dbDetails->user;

I belive PerlSetVar only allows strings variables. I would like to get some 
suggestions on how configuration management in mod_perl applications.

Thanks,
Jerry

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

[McCarrell, Jeff]

On 6/27/11 11:44 AM, "McCarrell, Jeff"  wrote:

>While this may not be the last word on this subject of DBIx::Class Db conn
>caching,
>a cursory glance at the documentation shows:
>(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Class/Manual/Int
>r
>o.pod#Connecting)
>
>   Note that DBIx::Class::Schema does not cache connections for
>you. If you use multiple connections, you need to do this
>manually.

Poking a little bit further,
(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Class/Storage/DBI
.pm#connect_info)
it looks like DBIx::Class caches statement handles via DBI
(see disable_sth_caching which explicitly disables this caching)
and that the design is oriented toward re-connecting to the DB
transparently,
as long as AutoCommit is turned on; which Apache::DBI also does.
I believe that DBIx::Class is not as well suited for interleaving
different SQL statements on the same connection as Apache::DBI because of
its
deeper assumptions about error handling and the state it assumes
across SQL statements.

So it appears that DBIx::Class does do its own connection handling,
but aimed at a different design center than Apache::DBI.

HTH,

-- jeff

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

[McCarrell, Jeff]

On 6/27/11 8:37 AM, "Fred Moyer"  wrote:

>>DBIx::Class just does its own persistent connection and this is why it
>>doesn't need Apache::DBI.
>
>Do you have any evidence for this claim?  I've been using DBIx::Class
>with Apache::DBI for several years and have never seen anything to
>this effect.
>

While this may not be the last word on this subject of DBIx::Class Db conn
caching,
a cursory glance at the documentation shows:
(http://search.cpan.org/~frew/DBIx-Class-0.08192/lib/DBIx/Class/Manual/Intr
o.pod#Connecting)

Note that DBIx::Class::Schema does not cache connections for
you. If you use multiple connections, you need to do this
manually.

Re: Debugging a long process

[McCarrell, Jeff]

Hey Tosh

>From my experience, I would guess you may seeing interactions between the
major components of your system as load grows.
If my hunch is true, then following a single request may not show the
issue.
You may need a way to load your system to the point where it shows the
issue.
If all these guesses are true, NYTProf, while an excellent tool, didn't
really help me and may not be much help to you.

You mention you may be running in an EC2 instance, which adds another
layer at which your code may be getting suspended.

When I faced a similar problem, I resolved it by:

- create a test environment that I could push to show the problem
- instrument major blocks of the code with markers and tv_interval() calls
so I could see where time was being spent.
- write a row of timing data for each request
- post process the timing data spread over, in my case, many many
individual requests so I could see how response time changed as load
increased

This took me a few days to get worked out, but once I had it in place, I
was able to tune my system more effectively.
I could 'see' where the bottlenecks were occurring as load increased.
In my case, it pointed to a single component in my stack which was the
bottleneck.
So I fixed that one, then fixed the next hot spot ... you get the picture.

There are a lot of assumptions here that may or may not actually be true
in your case...
HTH,

-- jeff


On 6/15/11 1:29 PM, "Tosh Cooey"  wrote:

>Hi Fred, I like the idea of "Apache may be blocking on other processes"
>but the Devel::NYTProf docs don't seem to indicate if it would be
>helpful in tracking down the reason for a 30 second execution under
>mod_perl versus a 9 second execution from the shell.  Also there seems
>to be some issues WRT Devel::NYTProf and virtual machines, which I
>believe my EC2 instance is one of.
>
>Is there anywhere to point me to find out more about the blocking issue
>and how to resolve it?

Re: ModPerl handler

[McCarrell, Jeff]

http://perl.apache.org/docs/2.0/user/intro/start_fast.html

There are a wealth of good (maybe even great) docs here that explain the 
request life cycle, configuration … pretty much everything you need to know.
Happy reading!

From: marco mailto:marcodis...@gmail.com>>
Date: Wed, 18 May 2011 14:43:57 -0500
To: Mod_perl users mailto:modperl@perl.apache.org>>
Subject: ModPerl handler

Hi,
I'm writing an handler to execute with mod_perl.
I want to associate an handler of type PerlPostConfigHandler.
I write this code (filename=StartupLog.pm):

#file:Apache/StartupLog.pm
  package Apache::StartupLog;

  use strict;
  use warnings;
  use Apache();

  use Apache::Constants qw(OK);

  sub funzione {

my $r=shift;
$r->content_type('text/html');
my $remote_ip = $r->connection->remote_ip;
$r->print("
mod_perl test",
"hello ", $remote_ip , "",
"");

 return OK;
  }
  1;

My questions are:
1. I don't know what is the code I must put in httpd.conf file.
2. Where must I put the file StartupLog.pm in the filesystem?

Can someone help me?

Thanks