Re: error during make all
You shouldn't have to run buildconf. Start from a clean tarball again and just run ./configure with your args and then make. -aaron On Apr 4, 2004, at 9:41 PM, Navneetha wrote: am am new to apache flood.i have downloaded the copy of flood .after successful download i am able to successfully execute ./buildconf and ./configure --disable-shared .
Re: [PATCH] flood and content-type setting
On Mon, Mar 15, 2004 at 09:13:45AM +0100, Philippe Marzouk wrote: On Sun, Mar 14, 2004 at 05:27:16PM -0800, Aaron Bannert wrote: This sounds reasonable to me, did it ever get committed? I imagine you asked the flood developers but I just did a cvs diff and this patch was not committed. Nope, I was just catching up on old mailings and wanted to see if this was ever addressed. I've committed it, thanks for the patch. Could you provide an example xml input file that I could stick in the examples/ directory that shows usage of this new parameter? -aaron
Flood's --with-capath mandatory?
Could someone please remind me why --with-capath is mandatory when --enable-ssl is used? The default is only useful if you actually use --with-ssl=some/path. I have a patch that changes the default to $sysconfdir/certs, but in the long run I think this should be something configured through the XML input (eg. you enable CA checking for some set of URLs and you give the patch to the trusted certs). -aaron
Re: running on embedded devices
On Mon, Oct 06, 2003 at 03:06:26PM -0500, Wood, Bryan wrote: Has anyone used this on the arm platform? Used what? -aaron
Re: FLOOD_1_1_RC1 tagged.
On Tuesday, September 9, 2003, at 04:18 PM, Jacek Prucia wrote: I have just tagged the tree with FLOOD_1_1_RC1. Release tarballs (made with apr and apr-util HEAD) are available for testing here: http://cvs.apache.org/~jacekp/release/ RC1 builds cleanly on my Gentoo box (with openssl and without) and all example files report no errors at all. Will do few more builds (Solaris, FreeBSD) tomorrow before casting a vote. Anyway looks like a strong candidate for GA. I would like to ask other RM's to take a closer look at RC1 tarballs. I might goofed something up and have absolutelly no idea about it :) Did you mean to include the full source to apr and apr-util in the flood source tree? -aaron
Re: FLOOD_1_1_RC1 tagged.
On Tuesday, September 9, 2003, at 04:18 PM, Jacek Prucia wrote: I would like to ask other RM's to take a closer look at RC1 tarballs. I might goofed something up and have absolutelly no idea about it :) The tarball builds and runs great on Darwin 6.6 (Mac OS X 10.2.6), good work! Here's my +1 (I'm fine with distributing the apr and apr-util source until apr 1.0 gets released, but after that we should just say which officially released version of APR we depend on.) -aaron
Re: cvs commit: httpd-test/flood/build rules.mk.in
I think I wrote that stuff, and the first time you run make it will complain about a missing .deps file, but once that file is built you won't get the complaints any longer. I just didn't take the time to figure out how to do it in a way that didn't complain about the missing file. -aaron On Thursday, September 11, 2003, at 11:57 PM, [EMAIL PROTECTED] wrote: jerenkrantz2003/09/11 23:57:29 Modified:floodCHANGES flood/build rules.mk.in Log: Axe the .deps stuff for now. I can't figure out how I intended this to work. Revision ChangesPath 1.51 +2 -0 httpd-test/flood/CHANGES Index: CHANGES === RCS file: /home/cvs/httpd-test/flood/CHANGES,v retrieving revision 1.50 retrieving revision 1.51 diff -u -u -r1.50 -r1.51 --- CHANGES 8 Sep 2003 00:04:49 - 1.50 +++ CHANGES 12 Sep 2003 06:57:29 - 1.51 @@ -1,5 +1,7 @@ Changes since 1.0: +* Remove .deps code that is just broken for now. [Justin Erenkrantz] + * Added configversion attribute (root element flood) which ties config file structure with certain flood version and warns user if there is a conflict. [Jacek Prucia] 1.4 +2 -2 httpd-test/flood/build/rules.mk.in Index: rules.mk.in === RCS file: /home/cvs/httpd-test/flood/build/rules.mk.in,v retrieving revision 1.3 retrieving revision 1.4 diff -u -u -r1.3 -r1.4 --- rules.mk.in 3 Feb 2003 17:11:00 - 1.3 +++ rules.mk.in 12 Sep 2003 06:57:29 - 1.4 @@ -179,7 +179,7 @@ local-depend: x-local-depend if test `echo $(srcdir)/*.c` != $(srcdir)'/*.c'; then \ - $(CC) -MM $(ALL_CPPFLAGS) $(ALL_INCLUDES) $(srcdir)/*.c | sed 's/\.o:/.lo:/' $(builddir)/.deps || true; \ + $(CC) -MM $(ALL_CPPFLAGS) $(ALL_INCLUDES) $(srcdir)/*.c | sed 's/\.o:/.lo:/' $(top_builddir)/.deps || true; \ fi local-clean: x-local-clean @@ -252,7 +252,7 @@ # # Dependencies # -include $(builddir)/.deps +#include $(top_builddir)/.deps .PHONY: all all-recursive install-recursive local-all $(PHONY_TARGETS) \ shared-build shared-build-recursive local-shared-build \
Re: flood: responsescript patch
On Monday, August 11, 2003, at 04:26 PM, Justin Erenkrantz wrote: --On Sunday, August 10, 2003 23:24:04 +0200 Jacek Prucia [EMAIL PROTECTED] wrote: This probably belongs in contrib/patches. It is a quick'n'dirty hack I did few days ago, to simulate applet making network connection. Basically it allows for something like this: url responsescript=/path/to/script.pyhttp://www.example.com//url I wouldn't see an issue just placing this in the main code rather than as a separate patch. Just place in the documentation that the use of this attribute may distort the timings. I agree. +1 This patch looks cool, but there's one little problem. If the response body is bigger than the internal IO buffers on your system, you'll block trying to write. If the script fails to read or fails to read enough of the body, then flood and the script will deadlock. A better (but more complicated) way to do this is with a pollset, so flood can poll on reading and writing from the script's stdout and stdin. Hmm. If we did this *after* the close is done, would we still have a problem with the timing? I don't think we would, but I could be wrong. (Perhaps we're freeing the response buffer at that time. I forget.) There may be cases where we'd want to keep the connection to the server open while the script processes, but I can't think of any. We could have it default to run the script after close, and then later if someone comes up with a use case, we could add a flag or something. -aaron
Re: flood docs -- take 2
On Sunday, June 29, 2003, at 06:18 PM, Jacek Prucia wrote: Please have another look at: http://cvs.apache.org/~jacekp/manual/ This is actually what I'm going to commit tommorow. It has bugs, empty places, but at least mentions every element/attribute available (at least I hope so). Looks like it is a good starting point. From the parts I looked at, it looks great. :) while preparing documentation I was stuck with one simple thing: What is HTTP Server project policy with CHANGES file? Is it: a) hand edited by separate cvs commits (changed the code? edit CHANGES!) b) autogenerated from cvs log Some of my useful commits (auth support, baseurl) aren't in CHANGES. Gotta fix that before release. We hand edit the CHANGES file, so go ahead and add anything you feel the user should know about. (Big awesome doc additions like this definitely belong in there.) -aaron
Re: flood - Can it go faster?
On Tuesday, June 24, 2003, at 12:35 PM, Jeremy Brown wrote: [...] generators running FreeBSD 5.1 You might try other operating systems. I don't know how well FreeBSD compares, but I have had good luck on both Solaris (x86) and Linux 2.4. Are there any tips to get more throughput on flood? Depends on what you want to model. Do you want keepalive enabled? Do you want to simulate 7000 simultaneous connections, 7000 requests, or 7000 users (depending on your definition of a user)? Or any methods to optimize flood to run faster? There are probably many things in flood that could be better tuned. We'll happily accept patches if you have any. :) Also is there a way to turn off logging completely? The new server will have logging enable to catch all the information. My job is to hit it as hard as I possibly can with my resources. And to only show something if there is a failure? You could implement your own hooks in flood that simple disable output (or count and don't display the results until the end). I am using shell scripts of flood since megaconglomerate is not operating at this time from what I have tested. Are there any recommendations for doing this more effectively? Or is megaconglomerate really working? Getting megaconglomerate working will probably have to wait until someone who needs it implements it. -aaron
Re: flood proxy (was: [STATUS] (flood))
On Thursday, March 13, 2003, at 01:46 AM, Jacek Prucia wrote: * Write robust tool (using tethereal perhaps) to take network dumps and convert them to flood's XML format. Status: Justin volunteers. Aaron had a script somewhere that is a start. Wouldn't it be better, if we use proxy instead of all-purpose network software? I was thinking about mod_proxy_flood.so with some function attached to request forwarding and a simple response handler which could allow users to: 1. enable/disable flood proxy 2. edit gathered urls (only delete for now, later full edit) 3. dump flood file Not a bad idea. things like tethereal and tcptrace are definitately like you say all-purpose, but for just collecting URLs and timestamps, that's sounds like a good idea to me. -aaron
Re: [PATCH] (flood) Handle invalid handler name in assign_profile_event_handler()
committed, thanks! -aaron On Thursday, February 6, 2003, at 07:45 PM, [EMAIL PROTECTED] wrote: Summary: Fixed assign_profile_event_handler() to handle nonexistent names. This patch fixes a null dereference when you specify a profile event handler that does not exist in the profile_event_handlers[] table. Below is the smallest test case I was able to generate to trigger the crash. Note that the entry for profile_init is XXX. flood profile nameprofile/name profile_initXXX/profile_init /profile farmer namefarmer/name useprofileprofile/useprofile /farmer farm nameBingo/name usefarmerfarmer/usefarmer /farm /flood With this patch, flood generates the following message: Invalid implementation (XXX) for this handler (profile_init) Error running farmer 'farmer': This function has not been implemented on this platform.
Re: [PATCH] Use mutex locks in mod_specweb99.c
On Friday, December 13, 2002, at 10:05 AM, [EMAIL PROTECTED] wrote: They are in apr_private.h. Yes, but they are also in apr.h. pigmy:~/apr/include - 9:57AM% grep _IS_GLOBAL apr.h #define APR_PROCESS_LOCK_IS_GLOBAL0 #define APR_PROC_MUTEX_IS_GLOBAL 0 pigmy:~/apr/include - 9:57AM% cd arch/unix pigmy:~/apr/include/arch/unix - 9:57AM% grep _IS_GLOBAL apr_private.h /* #undef POSIXSEM_IS_GLOBAL */ /* #undef SYSVSEM_IS_GLOBAL */ /* #undef FCNTL_IS_GLOBAL */ /* #undef FLOCK_IS_GLOBAL */ pigmy:~/apr/include/arch/unix - 9:57AM% So, why are they in apr.h at all? Because they are used in public header files, and we don't want to pollute the public header files with symbols from the private headers. [EMAIL PROTECTED] grep -lr _IS_GLOBAL . | grep \.h\$ ./acconfig.h ./include/apr.h ./include/apr_global_mutex.h ./include/apr_portable.h ./include/arch/unix/apr_private.h ./include/arch/unix/proc_mutex.h -aaron
Re: library-ization
On Sun, Oct 13, 2002 at 09:21:23AM -0700, David N. Welton wrote: And I would like an HTTP tester library. I think that if done in this way, it would be versatile enough to replace ab, and it would also give people the freedom to experiment with other front ends. Like someting in Tk, gtk, or whatever... Ah, but that is precisely why we use XML input to control the behaviour of flood, so that someone can come along and write whatever fancy GUI app they wish and couple it only to our XMl schema. There is another reason why we chose XML that gives us greater flexibility than a library interface could ever give -- platform transparency. Since flood processes need not all run on the same machine, it is not a requirement that all machines where flood are running be of the same operating system or architecture. This also means that the GUI need not be on the same machine where the actual flood process is invoked. Try doing that with a library. One thing that might be useful would be if something like tcl were embedded in flood. In that case it might make sense for flood to export its high-level functions for use in an embedded scripting language. This would give us much greater power over test cases than would be possible in XML (it would be possible, but not trivially so.) Just some food for thought. -aaron
Re: Connection speed throttle
On Sun, Sep 29, 2002 at 10:48:09AM +0200, Jacek Prucia wrote: Correct, but this applies only to BSD. Linux doesn't have such feature out-of-the-box. I bet this is true for other operating systems (Solaris, IRIX, etc.). So this might be a good idea to implement such functionality in flood. However it looks like this feature will be at the bottom of (at least mine) TODO list. There are more important things to do first. I'm not so sure we could even implement something like this at such a high level. OTOH, aside from cost considerations, a standalone BSD box running dummynet inbetween one or more clients and one or more servers would be very effective. -aaron
Re: [PATCH] flood: baseurl support
On Fri, Sep 13, 2002 at 06:06:55PM +0200, Jacek Prucia wrote: Following patch makes such config possible: urllist baseurlhttp://www.site.com/baseurl url//url url/foo.html/url url/cgi-bin/bar.cgi/url /urllist Cool! Might be useful if you move/install your site/app around quite a lot. I'm not sure if I got everything right (apr_pstrcat with overleaping strings -- is it safe?), but if there are no objections I'll comit this patch later today. I believe it's safe, since apr_pstrcat basicly first makes a pass at counting the total string length, then allocates the whole thing at once and then makes a second pass a memcpy'ing each string into the final one. So yeah. -aaron
Re: [PATCH] flood: install target
On Thu, Sep 12, 2002 at 12:48:15AM +0200, Jacek Prucia wrote: Here's a snippet from 1.3 INSTALL file: Note: To reduce the pollution of shared installation locations (like /usr/local/ or /etc) with Apache files to a minimum the string ``/apache'' is automatically appended to 'libexecdir', 'sysconfdir', 'datadir', 'localstatedir' and 'includedir' if (and only if) the following points apply for each path individually: 1. the path doesn't already contain the word ``apache'' 2. the path was not directly customized by the user ...so it looks like it was intended to have all files under separate directory. That is for apache 1.3, which has many installation files. Flood has one binary, no man pages, and nothing else that needs to be installed (AFAICT). This list will grow over time, but will not ever be that large. Correct, but right now flood install means also APR/APR-util install. That way you just have all-purpose library installed system wide. What if that overwrites another set of APR/APR-util libs from other httpd-2.0/subversion instalation? Big suckage. We shouldn't ever be installing apr or apr-util as part of flood. Ideally we will depend on an already-installed version of flood, be that in some standard location or not. Some work has been done lately to make apr and apr-util able to be independently installable. I feel rather strongly that if we change the default install location from /usr/local to something else we will be violating the principle of least astonishment. It really is a pain for users when autoconf-based projects go and try to do their own thing. I think flood needs a nice and descriptive build doc (current doc is nice, but not descriptive :)). We could write why default PREFIX is separate directory, and how to link flood dynamically against external APR/APR-util and have only file for instalation (which fits /usr/local location quite nicely). I'm still playing with httpd-docs xml/xsl files, but looks like I'll have a flood-docs skeleton ready soon. I agree, but not with changing the default from /usr/local. People will expect it to work like that. People who don't want it in /usr/local typically know how to run ./configure --prefix=/foo/bar. It's the other people (and my own tendencies to assume /usr/local, admittedly) that I'm more concerned about. -aaron
Re: [PATCH] flood: install target
On Wed, Sep 11, 2002 at 07:30:24PM -0700, Justin Erenkrantz wrote: On Wed, Sep 11, 2002 at 07:16:26PM -0700, Aaron Bannert wrote: We shouldn't ever be installing apr or apr-util as part of flood. Ideally we will depend on an already-installed version of flood, be that in some standard location or not. Some work has been done lately to make apr and apr-util able to be independently installable. No, we will include apr and apr-util in flood releases and use them when the user doesn't specify an installed apr location. That seems to be the best strategy devised so far since apr and apr-util aren't wide-spread enough to not include them. We need to make the barrier to entry as low as we can make it. Yet, when apr and apr-util are widespread, people can use the --with-apr and --with-apr-util configure options. As the APR release strategy matures, we may finetune the process. But, I'd think the point when httpd-2.0 and SVN don't include apr and apr-util in their releases is when flood should. For now, we must bundle apr and apr-util with flood releases. Yes, *should* was the key word above. I'm fine with bundling it for now, but as soon as apr and apr-util can be installed on their own we stop bundling it. To me having bundled apr and apr-util just makes everything way more complicated. The threshold in my mind has nothing to do with when other projects switch. Anyway, this is a premature discussion, I'm still convinced that we must install by default in to /usr/local just like every other autoconf project*. *(except Apache httpd) Fine, remove the AC_PREFIX_DEFAULT line and then add config.layout support. =) -- justin config.layout support is completely unnecessary. autoconf already handles this, and IMHO apache goes overboard. All the stuff we need is already in autoconf, and we should stick to the same defaults as every other autoconf-based package just for the sake of our sanity and the sanity of our users. -aaron
Re: [PATCH] flood: install target
On Thu, Sep 12, 2002 at 12:08:00PM +0200, Jacek Prucia wrote:
So for now let us have /usr/local/flood as default prefix, but we will
change that to /usr/local as soon as we get rid of APR/APR-util. Makes
sense?
+1 :)
To me having bundled apr and apr-util just
makes everything way more complicated.
Yes, but we depend on rapidly changing libraries and this is a must.
Which is why I'm willing to compromise (for now). :)
OTOH, if APR guys would make an unstable APR/APR-util release (like
ap{r,u}-0.4.28.tar.gz), we could remove intree libs and put such
tarballs into build dependency list. Well... we could get rid of intree
libs right now and require people to do something like: cvs co -D 24
Sep 2002 20:32 {apr,apr-util}, but that's ugly :)
Yeah, I'm ok with waiting until at least an official beta is released.
Right now APR and APR-UTIL only each have an alpha.
-aaron
Re: [PATCH] flood: install target
On Wed, Sep 11, 2002 at 04:22:36AM -0700, Justin Erenkrantz wrote: if you really don't like /usr/local (why? :), then we could use ... /usr/local/flood +1 /usr/local/flood is fine with me. It fits with how httpd and APR are setup by default. -- justin I don't understand why this is an issue. I use --prefix to define where things should be installed. Typically that defaults to /usr/local. Any reason we shouldn't do the same? (I'm ok with our directory being called flood or flood-1) -aaron
Re: [PATCH] flood: install target
On Wed, Sep 11, 2002 at 12:29:56PM -0700, Justin Erenkrantz wrote:
httpd and APR both do not have their default prefix set to
/usr/local, but rather /usr/local/{apache2,apr}. I think it's
better to follow that strategy than /usr/local for the clueless
newbie who doesn't use --prefix. -- justin
I think that's because there is a very high chance that both httpd
and APR may have multiple installed versions in parallel. I doubt
that flood will be used in the same conditions, and if it is they
should use the same thing everyone else uses to install in a new
location: --prefix. It really is a pain for users when autoconf-based
projects go and try to do their own thing.
-aaron
Re: flood-1.0 TR (was: count one bug out...)
On Thu, Sep 05, 2002 at 05:29:26PM +0200, Jacek Prucia wrote: - fix install target so we can install flood amd examples off $SRCDIR - fix few more bugs from STATUS (I'm on it) - move tag on changed files and roll tarball I'm ok with whatever anyone else does, since the three of us are the primary consumers of flood-1.0, but in the future (as is my philosophy with the httpd project itself) we shouldn't be doing tag bumps if we can help it. An install target would be nice, but we really only have one file that needs to be installed. Besides that we really only have the examples, but no docs or man pages or anything like that. -aaron
Re: [PATCH] flood: basic user auth
On Wed, Sep 04, 2002 at 10:43:51AM -0700, Justin Erenkrantz wrote: ...and react to WWW-Authenticate header just like browsers and other tiny clients (like wget) do. And I think we want to mimic browser behaviour. OTOH this brings up other issue -- an url list where we can insert new urls in realtime (like is planned for 3xx responses), which needs a bit more work... *sigh* Yeah, that's one thing we've always thought about, but never really implemented (allowing following of 3xx). If you wish to take a stab at it, be our guest. Almost certainly, we'd have to discuss it on-list first before coding it up. -- justin I missed this part of the discussion the other day. I think it would be useful to allow for certain types of dynamic urllist manipulation, but I don't think in general we want to support automatic 302 redirection. Either you are checking for the 302 response and the next entry in your urllist is the same url that came back with the 302, or your app wasn't supposed to return 302. (I tend to think that gratuitous 302's are errors.) An even more complicated example is how flood should deal with the WWW-Authenticate stuff, as suggested above. I tend to think that flood should be able to both check that the auth was required, and that some supplied credentials were accepted. I guess in both cases as long as it can be controlled whether to do automatic 302s or supply auth information, then that's fine. I just tend to think that we don't need it to be automatic. -aaron
Re: where to start?
On Wed, Sep 04, 2002 at 02:01:15PM +0200, Jacek Prucia wrote: Right now flood starts always with Bingo farm. This is just simply hardcoded. I would like to change that and additionally add getopt parsing to flood. We could have arguments to run particular farmer (-f/--farmer), particular farm (-r/--farm) and so on (no collective/megaconglomerate yet). What if there's no command line options, but only plain config file? I think we schould do as listed: 1. check for first megaconglomerate, step 2 if not found 2. check for first collective, step 3 if not found 3. check for first farm, step 4 if not found 4. check for first farmer, step 5 if not found 5. bail out The hardcoded bingo farm was just because we hadn't implemented collectives or megaconglomerates yet. The way you have proposed it sounds good to me. :) The reason we want to avoid command-line args altogether is so that we remain portable. Ideally the entire input to flood can be a generated XML that works on windows and unix, and can be generated from generic UI's. -aaron
Re: count one bug out...
On Wed, Sep 04, 2002 at 10:29:54AM -0700, Justin Erenkrantz wrote: I think we actually tagged 1.0 when we were doing the OSCON presentation, but we never released it. Yeah, we already tagged FLOOD_1_0, so let's put up what we have. The install targets would be nice, but we already tagged 1.0. :) Besides, we don't need install targets for 1.0, it's just a number. -aaron
Re: [PATCH] some more URL tests
On Thu, Aug 29, 2002 at 01:27:47PM +0200, Jacek Prucia wrote: This patch is an addition to previous patch that fixed segfault with bad urls. This time it looks like we are catching anything that might possible be wrong with URL. To make things a bit easy there's badurls-test.xml file included. You can test this patch (as well as previous one) to see ho it behaves. As usual -- this baby needs RBC (Review/Bless/Commit). Especially review and especially in what I do with user:[EMAIL PROTECTED] style URLs. If there are objections, we can simply remove that if() block. Right now I'm going to pickup a few more issues from STATUS, and then I'll chew a bit on a build system :) Cool, keep 'em coming! :) -aaron
Re: flood round-robin-dynamic.xml problem
On Wed, Aug 21, 2002 at 11:06:02AM -0700, Justin Erenkrantz wrote: On Wed, Aug 21, 2002 at 11:04:06AM -0700, Aaron Bannert wrote: Are we throwing an exception when the regexp doesn't match? That's what is happening - we throw an assertion when the regexp fails. -- justin So we need to fix that, right? An unmatched regexp shouldn't be fatal. -aaron
Re: flood round-robin-dynamic.xml problem
Besides, if the user disables debugging, the assertions will be disabled. If this is a fatal error (and I'm still on the fence here) then we should detect that case and print a nice message. Since I don't plan on fixing this, and since we both seem to be in a mostly maintenance mode, I've added this to the STATUS in case anyone else wishes to contribute the fix. -aaron
Re: flood round-robin-dynamic.xml problem
On Wed, Aug 21, 2002 at 02:21:29PM -0700, Justin Erenkrantz wrote: I'm not saying that the error is informative (none of our errors are), but the exiting is correct. If the site changed on you and you were expecting something else, then it should stop. I'm fine with it being fatal for now. Yes, we should make our error messages nicer, this is hardly the only problem error message. :) Besides, if the user disables debugging, the assertions will be disabled. If this is a fatal error (and I'm still on the fence here) then we should detect that case and print a nice message. How can a user disable asserts? httpd-2.0 has that capability via AP_DEBUG_ASSERT, but flood doesn't. -- justin Here's a clip from assert.h: #ifdef NDEBUG #define assert(ignore) ((void) 0) #else -aaron
Re: cygwin notes: needs symlinks
On Tue, Jul 30, 2002 at 12:05:44PM +0100, Reini Urban wrote: just configured the latest CVS flood and arp for the latest cygwin (not from CVS) using autotool-devel: (there's also a new autotool-stable, which needs similar symlinks) cd /usr/share/aclocal for s in /usr/autotool/devel/share/aclocal/* ; do ln -s $s; done cd /usr/src/apache/httpd-test/flood ./buildconf cd apr ./buildconf cd .. ./configure --enable-ssl --with-capath=/usr/ssl/certs \ --disable-shared make all works okay. Awesome! Thanks for the feedback. Any idea why your version of autoconf looks for those files in /usr/share/aclocal instead of in the full path? Maybe a mismatched binary? Or is something in flood causing it? This patch below is a minor aesthetic fix for the cygwin /usr/bin/echo which doesn't print \t. Thanks, I'll apply this right away. (My shell doesn't interpolate \t either, so I don't know how that snuck in there... maybe we should just do literal ascii tabs?) -aaron
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache TestConfig.pm
The reason I don't like that is because if I need to restart the server I have to quit my gdb. I want my gdb to last longer than the process (so my breakpoints et al remain the same). I'm confused why this commit is an issue. None of the other MPMs start multiple processes - why should prefork? And, it's not like it won't start multiple processes when it needs to. -- justin Not that I'm that experienced with the perl-framework over here, it would seem to me that it's important to run the tests under typical environments (ie multiple processes). Imagine a deadlocking bug that we never hit in -X mode. just my 2c, -aaron
Re: flood parse error in urllist
On Wed, Apr 17, 2002 at 10:24:27PM +0100, Thom May wrote: url method=GEThttp://host/script.cgi?arg1=x\arg2=y/url Shouldn't this be amp; rather than \ : url method=GEThttp://host/script.cgi?arg1=xamp;arg2=y/url Yes, that is correct. Since flood accepts XML input, that input must be XML-encoded. It is kind of ugly, but it is consistent. -aaron
Re: cvs commit: httpd-test/perl-framework/Apache-Test/lib/Apache
On Sun, Apr 07, 2002 at 09:38:15AM -0400, Jim Jagielski wrote: Haven't seen the patch yet, but for some systems it's the waitpid() call that seems weird. Could it have something to do with how we're creating a new process group after forking and killing the parent? I don't remember this happening before my original -DNO_DETACH changes. -aaron
Re: cvs commit: httpd-test/flood/build apr_common.m4
On Tue, Mar 26, 2002 at 09:19:51AM -0800, Justin Erenkrantz wrote: If it's not installed as part of APR it should be. We shouldn't have it in our repository merely because we don't want to have to keep them in sync. It wouldn't make sense as part of the install as it is only needed to build configure. I disagree. You can't have it both ways. If flood, an application that depends on an already-installed version of APR, requires some autoconf macros provided by APR then those macros must be installed by APR. It's not a matter of keeping them out of sync - I don't want to require that apr must be checked out underneath the flood tree (like what httpd-2.0 requires). I think that's a bad idea and I don't want to further that if we don't have to. I don't think it's the worst thing in the world if the versions are out of sync. -- justin I don't want to require that either, which is why I'm saying we should be picking it up from an APR install. HTTPD uses those macros, so as soon as APR becomes a standalone library httpd will need a way to get the apr_common.m4 file also. -aaron
Re: cvs commit: httpd-test/flood CHANGES flood_net.c flood_net.h flood_socket_keepalive.c
On Wed, Mar 27, 2002 at 09:38:03PM -, [EMAIL PROTECTED] wrote: jerenkrantz02/03/27 13:38:03 Modified:floodCHANGES flood_net.c flood_net.h flood_socket_keepalive.c Log: Add check_socket call to flood_net.h. This attempts to determine if the other side has closed on us by doing a poll. From my observations on Solaris, it seems that when a FIN is received from the other side, a POLLIN event is generated. Odd. I'd think it should be POLLERR or POLLHUP, but that doesn't seem to be the case. That's because a passive close is not an error, it just means the server closed before the client (flood) did. If you're blocking in read() you'll get a return of 0 bytes (EOF). -aaron
Re: cvs commit: httpd-test/flood/build apr_common.m4
On Mon, Mar 25, 2002 at 03:34:27PM -0800, Justin Erenkrantz wrote: I don't like relying on people having apr checked out in order to build flood's configure - like what we require for httpd-2.0. I don't want to go down that road. -- justin If it's not installed as part of APR it should be. We shouldn't have it in our repository merely because we don't want to have to keep them in sync. -aaron
Re: cvs commit: httpd-test/flood/build apr_common.m4
Hmm..shouldn't we be using apr_common.m4 instead of checking it into our repository? I've changed things in APR's version of this file very recently, and I don't think we should be maintaining our own copy. -aaron On Mon, Mar 25, 2002 at 10:58:20PM -, [EMAIL PROTECTED] wrote: jerenkrantz02/03/25 14:58:20 Modified:floodCHANGES configure.in Added: flood/build apr_common.m4 Log: - Fix up building of source apr and apr-util directly by using the m4 macros from APR for calling APR_SUBDIR_CONFIG. - Add config.nice support. - Fix typo when we can not find OpenSSL.
Re: Silly question about flood and APR...
On Tue, Mar 05, 2002 at 04:55:54PM -0500, Bill Perkins wrote: building on a Slackware 8.0 machine, downloaded all the stuff (flood, apr, apr-util), can't seem to get it to configure properly- errors out with: checking for APR... reconfig configure: error: flood requires a libtool-enabled APR. Any ideas on why it should do this? I've gone into the apr/ and apr-util/ directories, run buildconf and configure in both of them, all with the same results. Help! I'm not exactly sure why it would do that, but you might try configuring and compiling apr/apr-util before running flood's configure. If you're still having problems after that I can look into it more. -aaron
Re: Can't get makefile to work
On Tue, Feb 12, 2002 at 01:18:43PM +, Brian Charlton wrote: After following the on-screen instructions to download, configure and make Flood I get the following error message when I run Make. Any ideas? [EMAIL PROTECTED] flood]$ make all Making all in apr make[1]: Entering directory `/home/bcharlton/flood/httpd-test/flood/apr' make[1]: *** No rule to make target `all'. Stop. make[1]: Leaving directory `/home/bcharlton/flood/httpd-test/flood/apr' make: *** [all-recursive] Error 1 For some reason the 'all' rule is picking up your apr subdirectory, and running 'cd apr; make all' in there. Move that directory out of the way and try again. BTW, you can just run 'make'. Where in the docs do you see 'make all'? -aaron
Re: Cookie Patch for Flood
On Thu, Jan 03, 2002 at 09:43:48AM -0500, Chris Williams wrote:
I found a bug in flood_round_robin.c. The apr_pstrcat on line 146 should
have NULL as the last argument. I am new to submitting patches so if
someone could let me know the correct way to do it, I will repost. Without
this, you get a bunch of garbage in the cookie string if there is more that
one cookie.
Thanks for the find! Typically patches are posted as context diffs. If
you can manage it with your mail, it's best to attach the patches inline
(as opposed to a mime/uuencoded attachment).
There's some good info on this site for developers: http://dev.apache.org/
You'll be particular interested in: http://dev.apache.org/patches.html
So is this what you meant?
Index: flood_round_robin.c
===
RCS file: /home/cvs/httpd-test/flood/flood_round_robin.c,v
retrieving revision 1.19
diff -u -u -r1.19 flood_round_robin.c
--- flood_round_robin.c 3 Oct 2001 01:24:01 - 1.19
+++ flood_round_robin.c 3 Jan 2002 14:55:43 -
@@ -143,7 +143,7 @@
while (cook)
{
if (cook != p-cookie)
-cookies = apr_pstrcat(p-pool, cookies, ;);
+cookies = apr_pstrcat(p-pool, cookies, ;, NULL);
cookies = apr_pstrcat(p-pool, cookies, cook-name, =,
cook-value, NULL);
flood's handling of pool lifetimes/data scoping
I've been thinking about how to handle data lifetime scoping in flood and have come up with a solution, but I want some feedback before I jump in and do it. Theoretically, one instance of flood might need data that is scoped at each of the following lifetimes: all farms each farm all farmers each farmer all profiles each profile and possibly also: each use of a urllist each url in a urllist and maybe even: each flood (global per-process level) Potentially, a lower-level iterator like a profile may want to store data at a higher level like a farm. I don't see it working the other way around, since farms don't know much about their farmers other than when they start and stop. So the question is: How do the lower-level iterators get access to the higher-level scopes (aka pools)? Since we'll always have this hierarchy, perhaps we can take advantage of that somehow to allow a lower level access to it's parent's pool? Ideas? -aaron
Re: Quick flood question...
On Wed, Jan 02, 2002 at 01:14:07PM -0500, Chris Williams wrote: I am hacking around in flood to change how it handles cookies. What I am trying to do is have the current cookie list freed once a farmer completes a round. I think I found where to do this in round_robin_loop_condition. My question is how to free the cookie struct since it is using the apr_pcalloc to get the memory. I could just NULL out rp-cookie but will that cause memory growth in the long run? Any suggestions would be great. Yes, it'll cause memory growth when rp-cookie gets repopulated. I've been meaning to rethink how we do memory cleanups in flood for awhile, but for now you might want to just call apr_pool_clear() after each round. Eventually we'll have a pool for each of the necessary lifetimes (farm, farmer, profile, urllist, url, etc...), and one for each iteration thereof, so we can have very fine grained memory control. -aaron
Re: A question
On Thu, Dec 06, 2001 at 07:10:40PM +, Isabella Pighi wrote: Does Flood reuse SSL session id's for ongoing connection requests to the same server? Or does Flood leave it empty for all new requests thus forcing regeneration and exchange of session keys and other related data? I am doing some test over here and we are desperately looking for a tool which does it (which keeps sessions I mean). If sessions are destroyed anytime the system is overloaded to much and the test is not significant at all (actually users keeps sessions during browsing) It's just and idea. Thank you for your help. To answer your question: No, flood has no session cache and will renegotiate SSL sessions for each new connection. However, multiple HTTP requests can be pipelined over one connection (aka keepalive). Having a client-side session cache may be something we will want to optionally include for flood, but it doesn't seem like something that is totally legitimate for what flood is trying to do. If one were trying to load test the capabilities of an SSL server to handle a number of simulated users, then reusing the same SSL session would inaccuratly skew those results. Consider this particular user profile: 1. open keepalive session to fetch foo.html 2. optionally open up to 3 other keepalive connections and service all subrequests (images, etc) from foo.html over those pipelines. 3. pause some random amount of time (representative of real user interactions on the particular website). 4. Repeat at step 1. with a new URL linked from foo.html Now run this in parllel 100 times with random staring times and maybe shuffle the URLs around a little bit, and you've got essentially 100 simulated users concurrently accessing the site. (One might point out that at one time only a few users may be simultanously transfering data, but from the user's standpoint they are all fully interacting with the website.) It would make sense, from the standpoint of properly emulating a real user, to cache the session used in one thread (aka farmer) as it iterates through the above loop. I'd like to see something like this added to flood, but I can't volunteer to do it right now. Of course, you or anyone else are welcome to submit patches. :) -aaron
Re: Question about Flood
On Thu, Nov 15, 2001 at 12:56:41PM -0500, Chris Williams wrote: I would like to add some functionality to Flood but I want to make sure you can't already do it. What I would like to do is have one urllist but have some portions of those URL's based on information from each farmer. An example would be to use the farmer name as part of a URL request. Is there any way to do this currently and if not, are there any plans. If this can't be done, can anyone give me some pointers of where to start looking in the code. I was thinking I could do something in the round_robin_get_net_url call but I don't see any pointers to the farmer data. Any suggestions would be great. It's been awhile since I wrote that stuff, but I think you'll probably want to write your own get_next_url handler that overrides the round robin one. It's really a form of polymorphism, and you can even call other get_next_url routines to do the dirty work for you. Take a look at round_robin_profile_init(). The profile_name parameter is used as a key to search for the root of that profile's XML subtree in the config. It then pulls out the name of the urllist, which is again used as the key to the XML subtree for that urllist. You'll want to write your own profile_init routine that parses the XML any way you want. In your case you could store the string that will be inserted into the URLs (the farmer name or any string you want really). The place where profile-specific opaque data is stored in the profile_t struct, which can be defined privately per-profile. Now you can go ahead and write you own get_next_url handler, which knows how to take that stored string and the urllist that we parsed up in profile_init, and produce the next URL to hit. Let us know if you need more details or any other help with this, Aaron
2.0.28 results, need interpretation
I'm fairly new to the perl-framework testing harness, and I'm getting some results I'm not sure how to interpret on my Solaris 8 build of the rolled 2.0.28 tarball. With the worker MPM (with --enable-cgid) I get: Failed Test Status Wstat Total Fail Failed List of Failed apache/limits.t 101 10.00% 9 modules/cgi.t 36 33 91.67% 1-4, 6, 8-27, 29-36 But on prefork with the same build parameters (s/cgid/cgi of course) I get only: Failed Test Status Wstat Total Fail Failed List of Failed apache/limits.t 101 10.00% 9 The limits failure has to with LimitRequestBody, and looks to be a known issue (see modules/http/http_protocol.c:1314, /* XXX shouldn't we enforce this for chunked encoding too? */). But you probably already knew this. :) As for the cgi error, is this the error that Cliff reported earlier? It looks like it's a simple error with how @CGI_MODULE@ is being replaced in t/conf/extra.conf.in on about line 175. In my setup, no matter what I do it gets replaced with mod_cgi.c, which means those directives are never included with worker's mod_cgid.c. Can someone with more experience with perl voodoo check this out and let me know what I'm doing wrong here? -aaron p.s. Solaris 8 intel (07/'01 update), perl 5.6.1
Re: 2.0.28 results, need interpretation
On Tue, Nov 13, 2001 at 10:34:35AM -0800, Doug MacEachern wrote: this is fixed now. Works great, thanks. -aaron
Re: checking for openssl 0.9.6a
On Wed, Oct 17, 2001 at 02:46:35PM -0700, hiten pandya wrote: hey all, i was going through the httpd-test , i went into the flood directory, it said in the STATUS file about asking autoconf to check for OpenSSL 0.9.6a, i found out that there is no way i could do it because i am new to the autoconf environment. But I have the information if someone was interested in fixing the problem: Installation directory: /usr/local/ssl Bin Directory: /usr/local/ssl/bin (openssl) Lib Directory: /usr/local/ssl/lib/ (libssl.a) I tried the following command and it did give me OpenSSL 0.9.6 but not the _a_ bit...but i think the date will be helpful... It was released on: # openssl version (OpenSSL 0.9.6 24 Sep 2000) I think that would prove helpful if someone wanted to code the macro or just a test for checking OpenSSL 0.9.6a, for autoconf, Actually, openssl provides a preprocessor symbol with the version embedded. Take a look at openssl/opensslv.h and you'll find this: #define OPENSSL_VERSION_NUMBER 0x0090602fL You can use the autoconf macro AC_TRY_COMPILE to write a little piece of code that #errors if the version is below 0x0090602fL (for openssl-0.9.6b). How's that sound? -aaron
Re: intro and question
On Wed, Oct 03, 2001 at 03:42:05PM -0700, clayton cottingham wrote: ok after i retried on my home machine i got as far as this: /bin/sh /home/drfrog/httpd-2.0//srclib/apr/libtool --silent --mode=link gcc -g -O2 -pthread-DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -I/home/drfrog/openssl-0.9.6b/include -I/home/drfrog/httpd-2.0//srclib/apr/include/arch/unix -DAP_HAVE_DESIGNATED_INITIALIZER -I. -I/home/drfrog/httpd-2.0//os/unix -I/home/drfrog/httpd-2.0//server/mpm/prefork -I/home/drfrog/httpd-2.0//modules/http -I/home/drfrog/httpd-2.0//include -I/home/drfrog/httpd-2.0//srclib/apr/include -I/home/drfrog/httpd-2.0//srclib/apr-util/include -I/home/drfrog/httpd-2.0//modules/dav/main -export-dynamic -L/home/drfrog/openssl-0.9.6b/lib -o flood flood.lo flood_round_robin.lo flood_profile.lo flood_config.lo flood_net.lo flood_net_ssl.lo flood_farmer.lo flood_simple_reports.lo flood_easy_reports.lo flood_farm.lo flood_socket_generic.lo flood_socket_keepalive.lo flood_report_relative_times.lo -L/home/drfrog/openssl-0.9.6b/lib /home/drfrog/httpd-2.0//srclib/apr-util/libaprutil.la /home/drfrog/httpd-2.0//srclib/apr/libapr.la /home/drfrog/httpd-2.0//srclib/apr-util/xml/expat/lib/libexpat.la -lm -lcrypt -lnsl -ldl flood_net_ssl.o: In function `ssl_init_socket': /home/drfrog/httpd-test/flood/flood_net_ssl.c:153: undefined reference to `SSL_library_init' [...lots of openssl undefined reference errors omitted...] make: *** [flood] Error 1 What version of openssl do you have installed? You must have 0.9.6 IIRC (but make sure you get the latest, which I think is 0.9.6b now). -aaron
Re: intro and question
[please keep these discussions on the public mailing list so others can help too :) ] On Wed, Oct 03, 2001 at 02:52:14PM -0700, clayton cottingham wrote: hey a prob: modules/dav/main -c flood_net.c touch flood_net.lo flood_net.c: In function `open_socket': flood_net.c:87: `EADDRNOTAVAIL' undeclared (first use in this function) flood_net.c:87: (Each undeclared identifier is reported only once flood_net.c:87: for each function it appears in.) flood_net.c:87: `EAGAIN' undeclared (first use in this function) make: *** [flood_net.lo] Error 1 On what platform/operating system are you seeing these errors? Are those symbols defined on your platform? -aaron
Re: intro and question [flood]
On Thu, Oct 04, 2001 at 12:39:45PM -0700, Justin Erenkrantz wrote: I remember noting that flood can't compile against the static openssl libs, and I may have put this in the STATUS or something... If not we should look into this at least. I thought it was the other way around. On Solaris, OpenSSL can't build shared libraries. I don't remember that (you could be right). I do recall that OpenSSL doesn't want to install shared libs by default, you have to do --enable-shared (if you compile it yourself). For the record, flood is *very experimental* and should only be used at this point by people who are willing to fix/maintain it. I will continue to make fixes if it suits me or if it'll help another developer, but other than that I don't forsee much flood development in the near future (at least until we have something significant for apr-serf). -aaron
Re: intro and question
On Wed, Oct 03, 2001 at 12:40:13PM -0700, clayton cottingham wrote: [...] unfortunately it doesnt compile! it looks for apr_uri.h and cant find it heck i cant find it either!! its no where to be found in the apr or httpd 2.0 tarballs include dir's am i missing something? Some interfaces have changed since that tarball was released, so you'll have to get the current HEAD from cvs of APR in order to get flood to compile. Let us know if you have problems at that point. -aaron
Re: My previous two commits
On Fri, Aug 31, 2001 at 02:47:58PM +0100, Gary Benson wrote: Since it seems that my previous two commit emails disappeared, so for your pleasure I have recreated them. Gary, They were probably caught by the moderator. This tends to happen with new committers, so the posts won't show up until the moderator sees the posts (and he is probably somewhere over the mid pacific right now). You did the right thing by manually subscribing. -aaron
Re: Anyone know what this means?
CVS has an extra layer of access permissions that are preventing you from doing a commit. You need to get added to the accel file for httpd-test. (I don't know who can do this for you, sorry). -aaron On Thu, Aug 30, 2001 at 07:34:56PM +0100, Gary Benson wrote: Access denied: Insufficient Karma (gbenson|httpd-test/perl-framework/t/php)cvs server: Pre-commit check failed Access denied: Insufficient Karma (gbenson|httpd-test/perl-framework/t/htdocs/php) cvs server: Pre-commit check failed cvs [server aborted]: correct above errors first! cvs commit: saving log message in /tmp/cvsS0ABZQ
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c flood_report_relative_times.c
On Thu, Aug 23, 2001 at 10:35:50PM -0700, Justin Erenkrantz wrote: On Fri, Aug 24, 2001 at 04:26:39AM -, [EMAIL PROTECTED] wrote: jerenkrantz01/08/23 21:26:39 Modified:floodconfig.h.in configure.in flood.c flood_easy_reports.c flood_farm.c flood_net.c flood_net_ssl.c flood_report_relative_times.c Log: Per Sander, Linux 2.4 returns EAGAIN when we run out of ports. This was a royal screw-up on my part. I only meant to commit flood_net.c, but all of the fork stuff slipped in. It wasn't really ready for commit. But, uh, yeah, it's there now. =) I'll test it some more (it works) and then I'll commit lines to CHANGES with what I really changed on this commit. *sigh* -- justin After looking through the changes I'm not so sure this is what we want. I'd rather not treat threads and forked processes the same, since we may want to mix the two. The fork()ed scenario was what we originally defined as a collective, which is basicly a bunch of farms with each farm running in a single process. I'm worried that we're losing flexibility here, at least in terms of properly emulating some real-world clients (like a browser that truely uses threads). This may just be invalid paranoia on my part, but at this time I see no good reason to restrict ourselves. I like using conditional compilation for things like optimizing OpenSSL usage, but I don't like it for deciding what a farmer does. Anyway, I realize that this was a premature commit, but I thought I'd voice my objections anyway ;) BTW, I'm glad to see we're going to support fork()ing soon :) -aaron
Re: cvs commit: httpd-test/flood CHANGES flood_farm.c
On Fri, Aug 24, 2001 at 05:59:58AM -, [EMAIL PROTECTED] wrote: jerenkrantz01/08/23 22:59:58 Modified:floodCHANGES flood_farm.c Log: Okay, here's the real commit log for the fork()-based implementation of flood. - Remove FLOOD_USE_THREADS as we have no way of determining if we have threads other than APR. (We'd say that threads were always enabled.) I feel comfortable using APR's thread detection rather than mucking with parameters ourselves. - Add strtoq conversion for FreeBSD that #defines it to strtoll. This is a tad cheesy. Thoughts? I don't want to have #ifdef HAVE_STRTOLL and #ifdef HAVE_STRTOQ all over the place. Smells like an APR function. does linux have strtoll? IIRC, we're just reading it into an 'int' anyway, so why the long long? - Remove forking stuff in flood.c as it doesn't make sense to fork() here anyway as this is only bootstrap code. - Make reports output either the current thread id or the pid I assume this is only temporary until we have a better GUID? We really shouldn't be calling apr_os_thread_id() and then trying to print it as an int. How about just a counter for each new thread/process? - Don't do OpenSSL locking when we aren't threaded cool. - Not all OpenSSL versions (FreeBSD 4.2 has 0.9.5a) has AUTO_RETRY. So, only set that option if we have that symbol. So, we now support FreeBSD. Go forth. very cool. -aaron
flood and fork(), and test reports
[continued from a recent discussion on new-httpd or [EMAIL PROTECTED] or whatever that list is called nowadays ;) ] It should be fairly trivial to add fork() support to flood. I've had something in mind for awhile, so I might be able to patch that up later today. The only lingering problems are how to do reporting. Right now, like you mentioned Justin, flood only has a couple reporting techniques, and pretty much outputs raw per-hit statistics. This requires us to to postprocessing on that data to calculate any aggregate statistcs (totals, averages, stddev, etc...). Although we have some neat awk scripts to do this (which we really should add to CVS), I forsee us wanting to do this on a much larger scale and at runtime. For example: 10 machines, each emulating 15 users simultaneously. Each machine emulates one user with one thread or fork()ed child process. A user is some recorded real-world interaction with the system, which typically amounts to: 1) a single hit to a page in keepalive mode, 2) 3 more keepalive hits in addition to the original to retrieve some static content associated with the page, and 3) some delay until we start over at step #1. Now, while all this is going on and we are slamming the hell out of the target system, each of these farmers (as we call them) are generating some amount of reporting statistics. We can't say what these reports will consist of, other than the timing metrics we have already defined, and the result of the verify step. I think we are going to want a way for each of these farmers to report back to the original parent flood process (the one that invoked ssh/rsh to start a bunch of remote floods) so that the parent process can do the data aggregation and spit out a final report. Originally I had proposed that whatever report mechanism we plugged in to flood would handle this, for example we would have an average times plugin that would spit out XML at the farmer level, which would get send back over rsh/ssh to the parent flood which would collect that junk back up and do the calculations. I'm not so sure this is as flexible as I want, so I'm looking for suggestions. Let's get some discussion going and maybe find out what kind of reports we'll want back from flood. I'm aiming for some intermediate format that can be pulled apart later, ala sar's binary format, but I want to get more feedback. -aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
On Fri, Aug 17, 2001 at 09:02:01AM -0700, Justin Erenkrantz wrote: On Fri, Aug 17, 2001 at 08:30:20AM -0700, Aaron Bannert wrote: Index: config.h.in === RCS file: /home/cvs/httpd-test/flood/config.h.in,v retrieving revision 1.13 retrieving revision 1.14 diff -u -r1.13 -r1.14 --- config.h.in 2001/08/14 20:14:50 1.13 +++ config.h.in 2001/08/17 07:44:02 1.14 @@ -57,4 +57,8 @@ #define RANDFILE @RANDFILE@ #define CAPATH @CAPATH@ +#define FLOOD_USE_RAND @prngrand@ +#define FLOOD_USE_RAND48@prngrand48@ +#define FLOOD_USE_RANDOM@prngrandom@ + #endif /* __config_h */ Shouldn't this just be FLOOD_HAS_* by the way you are deciding which one to use inside the #ifdef's? I'll post a patch later today. (I know I know, I'm being picky.) I dunno. I think it is a USE because you may have all three, but you only want to use one of them. I don't think this is a HAS/HAVE because you may not always use the ones you have. Confusing... -- justin Really this should be in APR, but I fear that PRNG is a touchy subject for portability. The problem is that when you're using a PRNG, you usually need to know the operating parameters of the PRNG, like what you ran in to: period, distribution, etc... If we put an abstraction into APR, we may end up with lowest-common-denominator-syndrome, where it becomes less than useful for cases that require specific amounts of entropy. What do you think? -aaron
Re: cvs commit: httpd-test/flood config.h.in configure.in flood.c flood_round_robin.c
On Fri, Aug 17, 2001 at 11:15:34AM -0700, Justin Erenkrantz wrote: On Fri, Aug 17, 2001 at 09:34:28AM -0700, Aaron Bannert wrote: This is all really NBD, I'm just pointing out that by what you were doing in code should have been done with USE instead of HAS, and that it would be no big deal to add HAS and USE. Please check the code again - it is using USE. =-) -- justin You are indeed correct. Nevermind my ramblings... ;) -aaron
flood and openssl
So, does openssl-0.9.5a just not work with flood? There is a particular preprocessor symbol, SSL_MODE_AUTO_RETRY, that does not appear in my 0.9.5a but works with 0.9.6. Should we have autoconf check for = openssl-0.9.6? -aaron
