I recently upgraded to 10.10 Yosemite.
After that it wiped out a lot of work I had done for apache and mod_perl.
I also install perlbrew to install everything in my home.
I’m trying to reinstall mod perl but cannot get the configure to work.
I’m reinstalling because some of the modules in perl
Your understanding is correct. It’s what I am looking for. However, due to the
apache forking child nature, I don’t feel comfortable using SIGALARM.
We use Apache::DBI. I would prefer having enhancement in this module. Currently
the module is implementing apache process wide global cache for db
Hi,
Can you explain what problem you're trying to solve? Apache processes don't
have the option of doing things when there is no request to serve, so you
can't easily have them disconnect. It may be possible with alarms or cron
jobs or something, but it's probably not a good idea.
If you tune
We use PGBouncer on the web server(which handles keep-alive to the
database) and then we use Apache::DBI across localhost to talk to PGBouncer.
On Thu, Nov 13, 2014 at 9:56 AM, Perrin Harkins phark...@gmail.com wrote:
Hi,
Can you explain what problem you're trying to solve? Apache processes
We don’t have any front end proxy. We don’t use DBD::Gofer nor PGBouncer.
However, we do use Apache::DBI. The mod_perl application on our servers connect
to database when they need to. The database connection can be idle for a long
time if there is no more requests then we’ll get TCP/IP
On Thu, Nov 13, 2014 at 10:29 AM, Xinhuan Zheng xzh...@christianbook.com
wrote:
We don’t have any front end proxy.
I think I see the problem... ;)
If you use a front-end proxy so that your mod_perl servers are only
handling mod_perl requests, and tune your configuration so that idle
mod_perl
On 13/11/2014 15:43, Perrin Harkins wrote:
On Thu, Nov 13, 2014 at 10:29 AM, Xinhuan Zheng
xzh...@christianbook.com mailto:xzh...@christianbook.com wrote:
We don’t have any front end proxy.
I think I see the problem... ;)
If you use a front-end proxy so that your mod_perl servers are
On Thu, Nov 13, 2014 at 11:29 AM, Dr James Smith j...@sanger.ac.uk wrote:
From experience - and having chatted with our DBAs at work, with modern
Oracle and with MySQL keeping persistent connections around is no real gain
and usually lots of risks
It's certainly good to know how long it
I guess we do need connection caching and have persistent connections. It is
good in our situation. But I would feel oracle 11g connection pooling might be
more appropriate option to handle idle connection time out issue. Having
another tier (like DBD::Gofer) looks like really messy in
On Thu, 13 Nov 2014 10:43:35 -0500
Perrin Harkins phark...@gmail.com wrote:
Apache::DBI should also re-connect with no problems if a request comes in
after a connection has timed out. If that isn't happening, make sure you
are using Apache::DBI properly.
Hi Perrin,
Nobody suggested using
On Thu, Nov 13, 2014 at 12:21 PM, Vincent Veyron vv.li...@wanadoo.fr
wrote:
Nobody suggested using connect_cached, where the documentations says :
The cached database handle is replaced with a new
connection if it has been disconnected or if the ping method fails
Would that not solve
On Thu, Nov 13, 2014 at 12:19 PM, Xinhuan Zheng xzh...@christianbook.com
wrote:
Having another tier (like DBD::Gofer) looks like really messy in
infrastructure plus it’s not certain who is going to maintain that module’s
quality.
I'd only recommend trying it after you set up a front-end
Hi Perrin,
I don’t quite understand what you mean by setting up a front-end proxy. What
would you expect this “proxy” do? Does it take HTTP request?
Thanks,
- xinhuan
From: Perrin Harkins phark...@gmail.commailto:phark...@gmail.com
Date: Thursday, November 13, 2014 at 12:50 PM
To: Xinhuan
Yes, it's an HTTP proxy. It handles sending out the bytes to remote
clients, so that your mod_perl server doesn't have to. A popular
high-performance choice these days is nginx.
There's some discussion of why to use a front-end proxy here:
http://perl.apache.org/docs/1.0/guide/strategy.html
-
That link is from the mod_perl 1.x documentation. Is this information still
valid in mod_perl 2.x?
On Thu, Nov 13, 2014 at 2:23 PM, Perrin Harkins phark...@gmail.com wrote:
Yes, it's an HTTP proxy. It handles sending out the bytes to remote
clients, so that your mod_perl server doesn't have
Yes, it has nothing to do with the version of mod_perl. It's a general
technique for any HTTP application server.
- Perrin
On Thu, Nov 13, 2014 at 2:33 PM, John Dunlap j...@lariat.co wrote:
That link is from the mod_perl 1.x documentation. Is this information
still valid in mod_perl 2.x?
On
Hi Perrin,
Thanks for pointing out the document. We are using mod_perl enabled apache
server for dynamic content. From the description of the document, the “proxy”
server acts much like a memcache but it appears the difference is the “proxy”
understands the HTTP protocol while memcache does
On Thu, 13 Nov 2014 12:45:09 -0500
Perrin Harkins phark...@gmail.com wrote:
Well, Apache::DBI should already be doing a ping and a successful
re-connect if needed.
Haha, thanks for your answer. I have so much to learn...
But then, what is the point of using connect_cached?
--
On Thu, Nov 13, 2014 at 2:48 PM, Vincent Veyron vv.li...@wanadoo.fr wrote:
But then, what is the point of using connect_cached?
You can use it outside of mod_perl. You can also use instead of Apache::DBI
if you don't want the connection to be more explicit (instead of magically
overriding the
On Thu, Nov 13, 2014 at 2:41 PM, Xinhuan Zheng xzh...@christianbook.com
wrote:
From the description of the document, the “proxy” server acts much like a
memcache but it appears the difference is the “proxy” understands the HTTP
protocol while memcache does not.
Not exactly. While it is
On Thu, 13 Nov 2014 16:35:59 -0500
Perrin Harkins phark...@gmail.com wrote:
Keep in mind, neither of these work unless you call
DBI-connect()/connect_cached() at the beginning of every request. You
can't just keep a DBI handle stashed somewhere and expect that to work.
h... you're
On Thu, Nov 13, 2014 at 5:29 PM, Vincent Veyron vv.li...@wanadoo.fr wrote:
I stash a reference to a DBI handle in pnotes during the HeaderParser
phase of my requests; I then refer to this handle for every request in my
PerlResponseHandlers.
This seems to have been working fine for several
On Thu, Nov 13, 2014 at 5:38 PM, Xinhuan Zheng xzh...@christianbook.com
wrote:
We have load balancer cache that can cache images and JavaScripts. This
functions seems a bit duplicate.
It's not about caching. Here's a quote from that link I sent earlier:
Another drawback of this approach is
23 matches
Mail list logo
