how to restart apache?
Hi, Need help regarding restarting the apache server. How can I restart the apache server (so that it reread the httpd.conf file) on Linux, Unix and Windows? I tried to send SIGUSR1 in Linux but it looks that server is not handling the signal. I put a breakpoing in "restart" in mpm/threaded/threaded.c, but it does not stop there! Could anybody give me clue(s)!! Thanks, Rohan __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1
Re: Concatenation of small buckets in core_output_filter
On Mon, Nov 26, 2001 at 09:28:03AM -0800, Brian Pane wrote: >... > * Rather than creating a temporary brigade for concatenation, > create a heap bucket. Make it big enough to hold 8KB. Pop > the small buckets from the brigade, concatenate their contents > into the heap bucket, and push the heap bucket onto the brigade. > > * If we end up in the concatenation again during the foreach loop > through the brigade, add the small buckets to the end of the > previously allocated heap bucket. If the heap bucket size is > about to exceed 8KB, stop. > > Comments? You could actually scan the whole brigade and replace small buckets with a large heap bucket. For example: compress the first 20 5-byte buckets into a single 100-byte bucket, skip the 10k file bucket, then compress the next 50 10-byte buckets into a 500-byte bucket. The rule of thumb is simply "stop concatenating if you find a bucket bigger than your threshold." Whether you skip over those looking for more is a different question. Note that apr_brigade_write() is fine if you're writing to the "end" of a brigade. It doesn't work well "within", and it could also pose problems if you trigger its flushing behavior. That said, if you're concatenating and *moving* buckets (i.e. from the input brigade to a holding brigade), then you're always writing at the end. Also: why would this ever "exceed 8KB" ?? If that was the case, then you'd just send the brigade to the network rather than try to hold onto it. Finally: since you probably know the size of your concat-buffer, then you can allocate the heap bucket to be the proper size, rather than use a default 8k heap bucket. Cheers, -g -- Greg Stein, http://www.lyra.org/
Re: 64 bit solaris
On Tue, 27 Nov 2001, Gigi Sebastian Alapatt wrote: | | | Is there a 64 bit solaris working port for Apache. unless one of your apache processes require >2GB of RAM, why would you need a 64bit port? /dale
Re: cvs commit: httpd-2.0 ROADMAP STATUS
On Tuesday 27 November 2001 08:31 pm, Justin Erenkrantz wrote: > On Tue, Nov 27, 2001 at 07:45:38PM -0800, Ryan Bloom wrote: > > My guess is that once 2.0 goes GA, we'll all be busy fixing bugs and > > working on more fun stuff for a while. Also, take a look at everything > > in the ROADMAP file. 99% of it can be done as a dot release in the 2.0 > > tree. Most of it doesn't require large portions of the code to be > > re-written. > > Well, that's an issue of the contents in ROADMAP not its location. =) > > My original concern about ROADMAP being separated from a versioned > source repository still stands. -- justin > > P.S. IMHO, the idea is that when we go GA, we're pretty damn > certain there aren't a lot of bugs in it. When we say 2.0 is GA, > we MUST mean that we 100% recommend switching from 1.3 to 2.0. > I haven't seen any major showstoppers from 2.0.28, so we're on the > right track. 2.0.29 should have performance improvements, but may > have some bugs due to that... I think you are kidding yourself. Take a look at 1.3. That was supposed to be an interim release, in between 1.2 and 2.0. The real bugs won't really start to come out of 2.0 until it hits GA and millions of sites start to migrate to it. Also, remember that most sites aren't going to migrate to 2.0 until it has been out for a very long time. I'm all for starting to look at 2.1 and 3.0, but let's not jump the gun too much. I would thoroughly expect at least 22 2.0 GA releases, just like we had with 1.3, and I would expect that a lot of the advancements people want to make can be done very easily in a 2.0 framework. Even the async work can be done inside of 2.0. It won't be fully async, but we can do a lot of the low hanging fruit. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0 ROADMAP STATUS
On Tue, Nov 27, 2001 at 07:45:38PM -0800, Ryan Bloom wrote: > My guess is that once 2.0 goes GA, we'll all be busy fixing bugs and > working on more fun stuff for a while. Also, take a look at everything in > the ROADMAP file. 99% of it can be done as a dot release in the 2.0 > tree. Most of it doesn't require large portions of the code to be re-written. Well, that's an issue of the contents in ROADMAP not its location. =) My original concern about ROADMAP being separated from a versioned source repository still stands. -- justin P.S. IMHO, the idea is that when we go GA, we're pretty damn certain there aren't a lot of bugs in it. When we say 2.0 is GA, we MUST mean that we 100% recommend switching from 1.3 to 2.0. I haven't seen any major showstoppers from 2.0.28, so we're on the right track. 2.0.29 should have performance improvements, but may have some bugs due to that...
Re: cvs commit: httpd-2.0 ROADMAP STATUS
From: "Ryan Bloom" <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 9:45 PM > My guess is that once 2.0 goes GA, we'll all be busy fixing bugs and > working on more fun stuff for a while. Also, take a look at everything in > the ROADMAP file. 99% of it can be done as a dot release in the 2.0 > tree. Most of it doesn't require large portions of the code to be re-written. The only bit that causes problems is introducing/rearchitecting modules, such as the auth stuff. Yes, incremental changes could go into 2.0.x, but dropping out a module [such as splitting mod_auth in two] or the apr_file_t member of the request rec are really significant enough to warrent the 2.1 bump. The splitting-a-module means their old config files are [probably] broken. For the user's sanity, a 2.1 bump makes sense. The apr_file_t member means modules must be recrafted to pay attention to this open file handle. I think the _real_ benefit is to split out the filesystem as it's own module, much like mod_dav_fs. In any case, plenty of folks regularly complain that their suggestions are ignored, or are discussed and just drop. That isn't a good way to attract contributors. ROADMAP allows us to do some planing/architecting into the future, beyond the event horizion. I'm really beginning to believe that nayoga's bugzilla might be [part of] the answer to the headaches. Bill
Re: cvs commit: httpd-2.0 ROADMAP STATUS
On Tuesday 27 November 2001 07:37 pm, Justin Erenkrantz wrote: > On Tue, Nov 27, 2001 at 05:19:40AM -, [EMAIL PROTECTED] wrote: > > wrowe 01/11/26 21:19:39 > > > > Modified:.STATUS > > Added: .ROADMAP > > Log: > > OK... we keep deferring these issues, it's time for a ROADMAP. > > > > Jump in everyone. > > I think the ROADMAP file should be on the website. It shouldn't > be tied in with any specific httpd version (i.e. living in the > httpd-2.0 repository). > > See httpd-site/xdocs/dev/project-plan.html > > (That file could/should be migrated over to the new XML format...) > > My guess is once 2.0 goes GA, we'll open up httpd-2.1. -- justin My guess is that once 2.0 goes GA, we'll all be busy fixing bugs and working on more fun stuff for a while. Also, take a look at everything in the ROADMAP file. 99% of it can be done as a dot release in the 2.0 tree. Most of it doesn't require large portions of the code to be re-written. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: cvs commit: httpd-2.0 ROADMAP STATUS
On Tue, Nov 27, 2001 at 05:19:40AM -, [EMAIL PROTECTED] wrote: > wrowe 01/11/26 21:19:39 > > Modified:.STATUS > Added: .ROADMAP > Log: > OK... we keep deferring these issues, it's time for a ROADMAP. > > Jump in everyone. I think the ROADMAP file should be on the website. It shouldn't be tied in with any specific httpd version (i.e. living in the httpd-2.0 repository). See httpd-site/xdocs/dev/project-plan.html (That file could/should be migrated over to the new XML format...) My guess is once 2.0 goes GA, we'll open up httpd-2.1. -- justin
Re: Please help with this Snake Oil problem
On Tue, Nov 27, 2001 at 09:24:36PM -0600, William A. Rowe, Jr. wrote: > this is a perception problem for end users [much like the "It Worked! > Apache is successfully installed." message] that should be avoided when > Apache 2.0's final SSL components are put in place. Which is why we don't enable SSL by default and instead point them at the docs for mod_ssl. However, I believe this runs contrary to how httpd-2.0 will be packaged by third-parties - I think Henri mentioned that he is enabling mod_ssl by default in his RPM builds. I'm not sure if he is including a "Snake Oil" certificate or not. -- justin
Re: Please help with this Snake Oil problem
Apache doesn't currently distribute any SSL certificates whatsoever. And the only issue with your 'snake oil' certificates is that they are effectively invalid, only demonstrating that the communications are encrypted, but there is no trust provider. The "Someone in control" would be the administrators of the specific websites you are visiting. Suing Microsoft because users don't replace the IIS default page is as absurd as your suggestion in re. this cert. Just like spam, badly administered web sites are something you simply have to cope with. The serenity prayer might come in handy here. I am forwarding this to the httpd list, just to point out to the httpd authors that, in spite of your silly and overly dramatic message, that this is a perception problem for end users [much like the "It Worked! Apache is successfully installed." message] that should be avoided when Apache 2.0's final SSL components are put in place. Bill - Original Message - From: "V. Wolfe" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 27, 2001 8:20 PM Subject: Please help with this Snake Oil problem > Hello! > I am really getting tired of the Snake Oil certificate > coming > up when I try to visit new sites, or even sites I design. > It's beyond frustrating. I've wasted tons of time trying > to track down contact people - find them - they don't > reply. I am about to set out a lawsuit. > Someone at Apache or the Snakey Oil people need > to reply to me by December first with a solution. > The certificate presents in a ridiculously sneaky mode, > with no options to get beyond it... > > Please relay this to someone in control of this > situation. > > Thanks. > > V. Wolfe > Seattle > >
64 bit solaris
Is there a 64 bit solaris working port for Apache. Thanx Gigi _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
[PATCH] log error when unable to note auth failure
hi -
When AuthType is not set, but Requirements are - apache gracefully fails
to note the auth failure (since its dependent on the AuthType). This
patch adds that error logging in.
sterling
Index: server//protocol.c
===
RCS file: /home/cvspublic/httpd-2.0/server/protocol.c,v
retrieving revision 1.54
diff -u -r1.54 protocol.c
--- server//protocol.c 2001/11/21 03:46:22 1.54
+++ server//protocol.c 2001/11/27 23:55:50
@@ -761,9 +761,10 @@
else if (!strcasecmp(type, "Digest"))
ap_note_digest_auth_failure(r);
}
-/* XXX: else there is no AuthType configured
- * should we log an error or something ?
- */
+else {
+ap_log_rerror(APLOG_MARK, APLOG_NOERRNO|APLOG_ERR,
+ 0, r, "need AuthType to note auth failure: %s", r->uri);
+}
}
AP_DECLARE(void) ap_note_basic_auth_failure(request_rec *r)
Re: Tagging a release
> > You can always tag a release at any time. > > > Great. > Hope I did it right Now what do we do, announce it here, let it sit for a couple days, and then get someone to put it up on daedalus? A couple days after that if all goes well we vote on alpha/beta? "RTFM, Aaron." is a viable answer. :) -aaron
Re: Tagging a release
On Tue, 2001-11-27 at 14:49, Ian Holsman wrote: > On Tue, 2001-11-27 at 14:06, Ryan Bloom wrote: > > On Tuesday 27 November 2001 01:56 pm, Ian Holsman wrote: > > > > You can always tag a release at any time. > > > Great. > Hope I did it right OK.. I need to put my key into the KEYS file. not knowing anything about GPG I follow the instructions but it doesn't seem to generate the header part eg Type bits keyID Date User ID RSA 2048 0x423FF2F1 2001/03/16 *** DEFAULT SIGNING KEY *** Paul J. Reder .. any clues? -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 344-2608
Re: Tagging a release
On Tue, 2001-11-27 at 14:06, Ryan Bloom wrote: > On Tuesday 27 November 2001 01:56 pm, Ian Holsman wrote: > > You can always tag a release at any time. > Great. Hope I did it right > Ryan > > > is there any policy about tagging a alpha? > > I'd like to tag .29 now if no one objects > > > > TIA > > Ian > > -- > > __ > Ryan Bloom[EMAIL PROTECTED] > Covalent Technologies [EMAIL PROTECTED] > -- -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 344-2608
Re: [RFC] InodeEtag option
> Can/will do. I assume you also want a 'Size' keyword? Yes, forgot that one. > Should the directive be renamed to FileETagValue to make it more clear > that it only applies to file-based documents and has no effect > on dynamic content? Good idea -- I was trying to keep the most relevant part of the name at the front so that it is easy to find in the documentation, but FileETagValue is better than the alternatives. Actually, just FileETag (with one option being "none") would be best. Roy
Re: Tagging a release
On Tuesday 27 November 2001 01:56 pm, Ian Holsman wrote: You can always tag a release at any time. Ryan > is there any policy about tagging a alpha? > I'd like to tag .29 now if no one objects > > TIA > Ian -- __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Tagging a release
is there any policy about tagging a alpha? I'd like to tag .29 now if no one objects TIA Ian -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 344-2608
Re: [RFC] InodeEtag option
* On 2001-11-27 at 16:24, Roy T. Fielding <[EMAIL PROTECTED]> excited the electrons to say: > > For the sake of future extensibility, I suggest a directive like > >EtagValue Inode LMDate > > even if it doesn't include more than those two keywords as possible > values right now. Can/will do. I assume you also want a 'Size' keyword? Should the directive be renamed to FileETagValue to make it more clear that it only applies to file-based documents and has no effect on dynamic content? -- #kenP-)} Ken Coar, Sanagendamgagwedweinini http://Golux.Com/coar/ Author, developer, opinionist http://Apache-Server.Com/ "All right everyone! Step away from the glowing hamburger!"
Re: [RFC] InodeEtag option
For the sake of future extensibility, I suggest a directive like EtagValue Inode LMDate even if it doesn't include more than those two keywords as possible values right now. All it would do is set a mask of options for what to include. I considered an EtagFormat option, but that would slow down the server for no good reason. Roy
Re: [RFC] InodeEtag option
'Way back in May 2001, Phil Dietz proposed adding the ability
to control whether the file inode should be included in the
formulation of a document's ETag. He originally proposed it
as an extension to the Options directive, but said he'd re-do
it as its own directive. I can't find any record of that
actually happening, though, so here's a patch to do it.
Reason: Systems that fan out their content onto multiple back-end
servers with identical filesystem contents would nevertheless
produce cache-hammering responses because the same content would
have a different inode on each back-end server. Taking the inode
out of the equation allows their content to be cached as identical.
The reduced ETag is based on only the last-modified time and the
file size, rather than those plus the inode.
The directive added by this patch is a FLAG UseInodesInETags.
It can be used wherever FileInfo directives can appear. The
core per-dir config structure is extended by an int at the end,
used only by http_core.c and http_protocol.c.
If no-one has any complaints about this in the next couple of days,
I'll commit to 1.3 and then bring it forward to 2.0. The concept
has already received the necessary +1s, so any issues *should*
only relate to implementation or names..
Index: src/CHANGES
===
RCS file: /home/cvs/apache-1.3/src/CHANGES,v
retrieving revision 1.1742
diff -u -r1.1742 CHANGES
--- src/CHANGES 2001/11/26 17:26:53 1.1742
+++ src/CHANGES 2001/11/27 20:46:29
@@ -1,4 +1,13 @@
Changes with Apache 1.3.23
+ *) Add UseInodesInETags directive to control whether a file's
+ inode number can be used when constructing an ETag. We
+ always have in the past, but it breaks caching for systems
+ with content fan-out across multiple back-end servers.
+ 'UseInodesinETags Off' will result in only the last-modified
+ time and file size being used, which should allow such
+ fanned-out files to be cached.
+ [Ken Coar, from a patch by Phil Dietz]
+
*) Win32: Do not allow threads to continue handling keepalive
requests after a shutdown or restart has ben signaled.
[Bill Stoddard]
Index: src/include/http_core.h
===
RCS file: /home/cvs/apache-1.3/src/include/http_core.h,v
retrieving revision 1.64
diff -u -r1.64 http_core.h
--- src/include/http_core.h 2001/03/09 10:10:20 1.64
+++ src/include/http_core.h 2001/11/27 20:46:29
@@ -309,6 +309,12 @@
#endif
#endif /* CHARSET_EBCDIC */
+/*
+ * Should file inodes be included in ETag generation? Doing so
+ * can defeat caching of back-end fanned-out content.
+ */
+int inode_etag;
+
} core_dir_config;
/* Per-server core configuration */
Index: src/main/http_core.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v
retrieving revision 1.299
diff -u -r1.299 http_core.c
--- src/main/http_core.c2001/11/16 01:32:20 1.299
+++ src/main/http_core.c2001/11/27 20:46:29
@@ -170,6 +170,11 @@
#endif
#endif /* CHARSET_EBCDIC */
+/*
+ * Flag for use of inodes in ETags.
+ */
+conf->inode_etag = OPT_UNSET;
+
return (void *)conf;
}
@@ -319,6 +324,13 @@
#endif
#endif /* CHARSET_EBCDIC */
+/*
+ * Use the closer setting if it was explicit.
+ */
+conf->inode_etag = (new->inode_etag == OPT_UNSET)
+? base->inode_etag
+: new->inode_etag;
+
return (void*)conf;
}
@@ -2985,6 +2997,18 @@
#endif
#endif /* CHARSET_EBCDIC */
+/*
+ * Note whether file inodes may be used when forming ETag values.
+ */
+static const char *set_inode_etag(cmd_parms *cmd, void *mconfig, int bool)
+{
+core_dir_config *cfg;
+
+cfg = (core_dir_config *) mconfig;
+cfg->inode_etag = bool;
+return NULL;
+}
+
/* Note --- ErrorDocument will now work from .htaccess files.
* The AllowOverride of Fileinfo allows webmasters to turn it off
*/
@@ -3276,6 +3300,8 @@
#endif
#endif /* CHARSET_EBCDIC */
+{ "UseInodesInETags", set_inode_etag, NULL, OR_FILEINFO, FLAG,
+ "Use file number (inode) when generating ETag values"},
{ NULL }
};
Index: src/main/http_protocol.c
===
RCS file: /home/cvs/apache-1.3/src/main/http_protocol.c,v
retrieving revision 1.301
diff -u -r1.301 http_protocol.c
--- src/main/http_protocol.c2001/06/22 12:43:54 1.301
+++ src/main/http_protocol.c2001/11/27 20:46:29
@@ -649,7 +649,10 @@
{
char *etag;
char *weak;
+core_dir_config *cfg;
+cfg = (core_dir_config *)ap_get_module_config(r->per_dir_config,
+ &core_module);
/*
* Make an ETag header out of various pieces of information. We use
* the last-modified date and, if we have a real file, the
@@ -666,11 +669,24 @@
weak = ((r->request
Re: 2 modules
On Tue, Nov 27, 2001 at 08:42:45AM -0800, Ian Holsman wrote: > On Mon, 2001-11-26 at 21:09, Justin Erenkrantz wrote: > > On Mon, Nov 26, 2001 at 02:49:20PM -0800, Ian Holsman wrote: > > > 1. mod_ssi_stub is of interest to module developers. It allows people to > > > stub out custom SSI tags with a bit HTML code. This has helped us when > > > other developers haven't had their modules ready in time. > > > > Can you give an example of its usage? > > > SSI Stub SSIcmd "TBD" > > this way when you have a team of developers they don't need to wait on > each other, and you can benchmark/debug/perf test using the same HTML. > It isn't meant for production use, just for development I'm still missing something. What does the file look like before this module and what does it look like after? -- justin
Re: 2 modules
On Mon, 2001-11-26 at 21:17, William A. Rowe, Jr. wrote: > From: "Justin Erenkrantz" <[EMAIL PROTECTED]> > Sent: Monday, November 26, 2001 11:09 PM > > > > On Mon, Nov 26, 2001 at 02:49:20PM -0800, Ian Holsman wrote: > > > > > 2. mod_sentinel (bad name) skips the file/directory walk and does a > > > open/fstat instead of stat/open to read the file, resulting in a > > > performance win when the file is on NFS, and you don't need to check > > > file permissions etc > > > > Wouldn't it be better to have this as an option in the core > > than as a separate module? -- justin > > ++1 on integrating an apr_file_t * right into the request_rec. This would > be an enormous advantage to everyone. > > But don't suggest it's a user option - it's not. And in fairness to our > module authors, lets please table it till 2.1. Simply, we try a direct hit > on the file. If we succeed with open/fstat, great, if not, we do the usual > stat [must be a dir, or access was denied.] > > Other modules will win, too. A file permanantly opened [cached] becomes > nothing but a dup2. mod_mime_magic doesn't have to add an extra open/close > to the mix, it's nothing but a read/seek(0). This is generally goodness. > > But I'm guessing it's 3 months before everything is optimized and settles > out from this [very worthwhile] change. Do we make everyone wait three more > months? No, IMHO we offer a savory performance enhancement with 2.1. > agreed I'd rather get 2.0 than wait 3 months.. so this will be a 2.1 mod. > Bill -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 344-2608
Re: 2 modules
On Mon, 2001-11-26 at 21:09, Justin Erenkrantz wrote: > On Mon, Nov 26, 2001 at 02:49:20PM -0800, Ian Holsman wrote: > > 1. mod_ssi_stub is of interest to module developers. It allows people to > > stub out custom SSI tags with a bit HTML code. This has helped us when > > other developers haven't had their modules ready in time. > > Can you give an example of its usage? > SSI Stub SSIcmd "TBD" this way when you have a team of developers they don't need to wait on each other, and you can benchmark/debug/perf test using the same HTML. It isn't meant for production use, just for development -- Ian Holsman [EMAIL PROTECTED] Performance Measurement & Analysis CNET Networks - (415) 344-2608
Re: Some Benchmark Numbers
On Tue, 27 Nov 2001, Ryan Bloom wrote: > > * mallocs in the bucket code > > What ever happened to the bucket free list code? He got sidetracked. :) I'm back on it today [finally]. --Cliff -- Cliff Woolley [EMAIL PROTECTED] Charlottesville, VA
Re: support for multiple tcp/udp ports
On Tuesday 27 November 2001 02:08 am, Michal Szymaniak wrote: > Hello, > > One question about the support for udp in Apache 2.0. Is it now > possible to make A. listen on multiple tcp and udp ports, and then > call appropriate hooks for each incoming connection/datagram? > > Especially, is such functionality available for module? Or there > are Apache internals that should be modified to achieve this? It is now possible to write a module that will make Apache listen on UDP ports. However, as somebody who has done this in the past, it's not a good idea. You lose too much data on every request. Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: Some Benchmark Numbers
While we're on the subject of benchmarks any numbers from the Covalent Apache 2.0 version. I.e. how does it perform against the PD version and or Apache 1.3.x Peter -Original Message- From: Ryan Bloom [mailto:[EMAIL PROTECTED]] Sent: Tuesday, November 27, 2001 7:46 AM To: [EMAIL PROTECTED]; Brian Pane Subject: Re: Some Benchmark Numbers On Monday 26 November 2001 06:25 pm, Brian Pane wrote: > Ian Holsman wrote: > [...] > > >Summary: > >2.0 HEAD is approaching (and in some cases exceeeding) the performance > >of Apache 1.3, but there still is some work needed to reduce the CPU > >utilization, and locking of the pools. > > Notably, there are just two things that stand out as big > performance problems in 2.0 right now: > > * mutexes in the pools > > * mallocs in the bucket code What ever happened to the bucket free list code? Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
Re: Some Benchmark Numbers
On Monday 26 November 2001 06:25 pm, Brian Pane wrote: > Ian Holsman wrote: > [...] > > >Summary: > >2.0 HEAD is approaching (and in some cases exceeeding) the performance > >of Apache 1.3, but there still is some work needed to reduce the CPU > >utilization, and locking of the pools. > > Notably, there are just two things that stand out as big > performance problems in 2.0 right now: > > * mutexes in the pools > > * mallocs in the bucket code What ever happened to the bucket free list code? Ryan __ Ryan Bloom [EMAIL PROTECTED] Covalent Technologies [EMAIL PROTECTED] --
RE: Some patches to start supporting AS/400 (iSeries)
>GOMEZ Henri <[EMAIL PROTECTED]> writes: > >> What about the patches sent by IBM iSeries folks ? >> Could you send them back to the list to let iSeries >> developpers take a look at them ? > >They aren't my patches... I don't feel free to redistribute. I >imagine that you'll have to get them from the iSeries folks (or >hopefully get some updated ones). That's why I send a mail to the list, knowing IBM people are tracking it. I hope someone could also forward the request to apr list ;) I CCed this email to RCHAPACH in Rochester which is the only IBM Fellow who reply to my post about iSeries Patches. Regards
Re: Some patches to start supporting AS/400 (iSeries)
GOMEZ Henri <[EMAIL PROTECTED]> writes: > What about the patches sent by IBM iSeries folks ? > Could you send them back to the list to let iSeries > developpers take a look at them ? They aren't my patches... I don't feel free to redistribute. I imagine that you'll have to get them from the iSeries folks (or hopefully get some updated ones). -- Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site: http://www.geocities.com/SiliconValley/Park/9289/ Born in Roswell... married an alien...
support for multiple tcp/udp ports
Hello, One question about the support for udp in Apache 2.0. Is it now possible to make A. listen on multiple tcp and udp ports, and then call appropriate hooks for each incoming connection/datagram? Especially, is such functionality available for module? Or there are Apache internals that should be modified to achieve this? Kind regards, -- : Michal Szymaniak | mailto:[EMAIL PROTECTED]
