Re: [JOB] Crack OOP Perl whitebox tester wanted
I think *all* job postings and offers should be forked to another list. This should be mod_perl only! Per Einar Ellefsen wrote: At 11:46 22.06.2002, Ged Haywood wrote: Hi all, On Fri, 21 Jun 2002, Zac Morris wrote: Old fashioned is right, Can we decide whether this kind of post is or is not welcome on the List? My 0.02 is that if someone has decided on the terms of reference for an offer of employment which he is making then if it's legal, that's the way it has to be and we don't need to discuss it here - especially not at such length. I agree with you Ged; Job announcements are ok, any discussion is way OT.
Re: Porting to OS X [OT] OS X
I think it is relatively an easy move, IMHO. Just beaware that the Mac OS filesystem is NOT case-sensitive. Which can cause problems with certain applications. . .and we hope (Apple, you listening?) that they will fix this gross over-sight. I agree it's a problem, and it's caused me some heartache, but Apple, and many of my Apple zealot friends definitely consider it a feature, not a bug. Another annoying thing that may happen while migrating directory structures is: if you have two directorie with /dir_this/dir_that/[lotsof.pl] /dir_dir/dir_this/dir_the_other/[lotsmore.pl] and you're in / cp|mv dir_this dir_dir will cp|mv dir_that to /dir_dir/dir_this/dir_that BUT dir_the_other will be gone. Another feature Dvaid
Re: Cheap and unique
Good morning.
Ken is correct - I am not looking for random, I am looking for unique.
Unique and sequenced would be ideal, but it's tricky because if I use
$i++.$IP_address.$parameter.$PID
{$i is global, $IP_address is the server address, $parameter is a
parameter that was just passed in, $PID is the apache process ID.}
That's a decent solution, but it's not quite sequential because one
Apache process could handle far more many requests than another, and so
a later request could have a lower $i.
Are there any code examples out there that use mod_unique_id.c ? I am
new to mod_perl and couldn't quite get that. Looking at the code, it
looks like mod_unique_id does basically the same thing but with a shared
counter between the different servers.
Also what is the cheapest way to get a datestamp? (I'm assuming it's not
`date %Y%M%D%H%S`)
--
I'm sorry to be such a noob, but when I've got a little more mod_perl
under my belt I'll be answering questions up a storm!
David
Re: Many requests per page
I'm running into a possible related problem. I'm using http_load to load test a simple hander (the aforementioned unique number generator). When I keep the load low (10-30 requests for 3-5 seconds) it works lovely. When I stry anything more stressful (say 50 requests for 5 seconds or 30r/10s) I get a cavalcade of byte count wrong errors. I wonder if: a) the $i global variable i'm using to increment (in concert with Timestamp/random (for now)) gets to big? b) the http_load program asks for too many ports and for some reason (apache, tcpstack?) linux (rh 7.2) doesn't like this any ideas? tia David (btw - I just picked up the mod_perl Developer's cookbook yesterday, and I'm eager to get into it) Geoffrey Young wrote: I thought $r-content_type was used for the server to set the content type for a response, not discover it from the request. $r-content_type is just a get/set routine for the request record, giving you the option to either peek at it or set it yourself. So it should I think be empty till set. yup. typically mod_mime does this, so by the fixup stage it's typically available for comparisons. HTH --Geoff
Cheap and unique
I'm converting a few CGI scripts that used the PID as a cyclical unique number (in concert with TIMESTAMP - so it was TIMESTAMP.PID). Our goal is to find a replacement function that is extremely cheap (cheaper than say, random(100)) and will never repeat. Any ideas? Has anyone else faced this problem? tia David
[Fwd: Re: Cheap and unique]
I'm just curious - what's wrong with the function you're already using? Steve Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_) mod_unique_id looks like a good solution, pending performance. Thanks for your help so far, everyone! David
Re: [Fwd: Re: Cheap and unique]
Mod_Perl hangs on to it's PID, so it's no longer unique. (I _believe_ But the timestamp will make it unique - as long as you're not serving several requests per second. I'm building the system so I can be confident up to thousands of requests/second. Looks like unique_id_module is good for around 65K requests, which is fine ;) A global counter hanging around is a good solution, but not perfect if we deploy on multiple servers. It appears the mod_unique module uses timestamp, a PID, a counter and the IP address, which is fine. David
