Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS

2001-11-08 Thread SubbaReddy M
Hello Gurus, please help me to get update for mod_perl. I have good run apache 1.3, which has got by default on Installing the Linux 6.2 (Redhat) Now I install perl 5.6.1 and To extend an already installed Apache with mod_perl I followed the steps in http://perl.apache.org/guide/install.html#Bu

Proble by Build mod_perl as a DSO outside the Apache Source Tree via APXS

2001-11-08 Thread SubbaReddy M
Hello Gurus, please help me to get update for mod_perl.   I have good run apache 1.3, which has got by default on Installing the Linux 6.2 (Redhat) Now I install perl 5.6.1 and   To  extend an already installed Apache with mod_perl I followed the steps in http://perl.apache.org/guide/insta

Re: [OT] Data store options

2001-11-08 Thread Joachim Zobel
At 08:59 08.11.01 -0800, you wrote: >My specifics are that I have a need to permanently store tens of thousands >of smallish (5K) items. I'm currently using a simple file system store, >one file per record, all in the same directory. Clearly, I need to move >into a directory tree for better perf

mod_dir DirectoryIndex vs. $r->uri() manipulation

2001-11-08 Thread David Pisoni
Hello again modperlers, I am using perl 5.6.1 / Apache 1.3.20 / mod_perl 1.26. I have an interesting problem which maybe someone could shed some light on : I have an early phase handler (can be done as either a PerlPostReadRequestHandler or a PerlTransHandler) which manipulates the request URI

Re: [OT] Data store options

2001-11-08 Thread Joshua Chamas
Bill Moseley wrote: > > Hi, > > > I'm looking for a little discussion on selecting a data storage method, and > I'm posting here because Cache::Cache often is discussed here (along with > Apache::Session). And people here are smart, of course ;). > > Basically, I'm trying to understand when t

Mac OSX 10.1 - mod_perl build instructions

2001-11-08 Thread Randal L. Schwartz
Apparently, mod_perl wants to be built static into Apache on OSX, and yet wants to use mod_so to load any additional thingies like Apache::Request or Apache::Template. So after many hours of trying different combinations of things, I finally yelled out "Yippee Skippee" (a phrase my dad firmly in

Re: Cache::* and MD5 collisions [was: [OT] Data store options]

2001-11-08 Thread Barrie Slaymaker
On Thu, Nov 08, 2001 at 10:54:11AM -0800, Andrew Ho wrote: > Let me point out that if you are using MD5 hashes for directory spreading > (i.e. to spread a large number of files across a tree of directories so > that no one directory is filled with too many files for efficient > filesystem access),

Re: [OT] Data store options

2001-11-08 Thread Perrin Harkins
> Later versions of BerkeleyDB have a row-level lock available which works > pretty transparently. That's what I'm talking about. Multiple writers can cause deadlocks unless you run their deadlock daemon or implement their deadlock handling API yourself. > However, this works using mmap() so it

Re: Cache::* and MD5 collisions [was: [OT] Data store options]

2001-11-08 Thread Bill Moseley
At 10:54 AM 11/08/01 -0800, Andrew Ho wrote: >For example, say your keys are e-mail addresses and you just want to use >an MD5 hash to spread your data files over directories so that no one >directory has too many files in it. Say your original key is >[EMAIL PROTECTED] (hex encoded MD5 hash of th

Re: [OT] Data store options

2001-11-08 Thread Andrew Ho
Hello, PH>If you do use BerkeleyDB, I suggest you just use the simple PH>database-level lock. Otherwise, you have to think about deadlocks and I PH>found the deadlock daemon that comes with it kind of difficult to use. Later versions of BerkeleyDB have a row-level lock available which works pret

Re: Cache::* and MD5 collisions [was: [OT] Data store options]

2001-11-08 Thread Andrew Ho
Hello, DC>For example, file system caches fill their directories roughly equally DC>when their paths are created from MD5 hashed keys. Doing something DC>simple and unique like "URL-encoding" the key to make a legal identifier DC>(legal in the sense that it is a valid filename) wouldn't distribut

Re: Cache::* and MD5 collisions [was: [OT] Data store options]

2001-11-08 Thread DeWitt Clinton
On Thu, Nov 08, 2001 at 01:11:21PM -0500, Barrie Slaymaker wrote: > Even a bit more OT: one thing to watch out for, especially if you > plan on caching a *lot* of data, is that the Cache::* modules did > not do collision detection on MD5 collisions the last time I looked. > Forgive me if that's c

Re: Cache::* and MD5 collisions [was: [OT] Data store options]

2001-11-08 Thread Jeffrey W. Baker
On Thu, 2001-11-08 at 10:11, Barrie Slaymaker wrote: > On Thu, Nov 08, 2001 at 08:59:55AM -0800, Bill Moseley wrote: > > Hi, > > > > > > I'm looking for a little discussion on selecting a data storage method, and > > I'm posting here because Cache::Cache often is discussed here (along with > > A

Cache::* and MD5 collisions [was: [OT] Data store options]

2001-11-08 Thread Barrie Slaymaker
On Thu, Nov 08, 2001 at 08:59:55AM -0800, Bill Moseley wrote: > Hi, > > > I'm looking for a little discussion on selecting a data storage method, and > I'm posting here because Cache::Cache often is discussed here (along with > Apache::Session). And people here are smart, of course ;). > > Bas

Re: [OT] Data store options

2001-11-08 Thread Perrin Harkins
> Basically, I'm trying to understand when to use Cache::Cache, vs. Berkeley > DB, and locking issues. (Perrin, I've been curious why at etoys you used > Berkeley DB over other caching options, such as Cache::Cache). Cache::Cache didn't exist at the time. BerkeleyDB seemed easier than rolling o

[OT] Data store options

2001-11-08 Thread Bill Moseley
Hi, I'm looking for a little discussion on selecting a data storage method, and I'm posting here because Cache::Cache often is discussed here (along with Apache::Session). And people here are smart, of course ;). Basically, I'm trying to understand when to use Cache::Cache, vs. Berkeley DB, an

Re: [JOB] Red Hat Network Web Engineer positions open

2001-11-08 Thread Jon Robison
Jiminy Crickets Chip! Yer makin me drool! If it weren't for the "Move to NC" part, I'd be doing my best to be your new closest buddy ;-) --Jon Robison Uniphied Thought, LLC Dearborn, MI Chip Turner wrote: > > Hello all, > > We have a couple openings doing intense and interesting mod_perl wor