That's something to report via http://nagoya.apache.org/bugzilla/
As far as the --enable-proxy-httpd thing... Apache doesn't look for configure options it doesn't understand and instead assumes that they are for apr or apr-util or libtool or expat or anything else that might be configured under the covers.
Please open a PR at http://nagoya.apache.org/bugzilla/
It apparently doesn't matter how many boxes we build it on, somebody's build is always going to break:(
(if it makes you feel any better/worse, I built 2.0.46's mod_proxy on a bunch of different boxes today... hopefully we can figure out why it won't build on yours)
Lots of active connections handled by the same process can result in lots of mmaps. If these are large you can start getting worried about running out of address space with a 32-bit process.
Also, perhaps sendfile works with large file support on Linux in 64-bit mode:) that would be a nice improvement
For most situations a 64-bit Apache process isn't going to solve any problems right now. I imagine it will just use more memory.
Yes, I've run Apache 2 as a 64-bit process on AIX and Tru64 as well. And Apache 2 has run as 64-bit process on HP-UX for ia64 for some time.
There have been a few assume-32-bit bugs found here and there and there probably are a few more still out there, but in general people should expect Apache 2 to already work in 64-bit mode with the caveat that it hasn't been tested as much as in 32-bit mode.
>From looking at the code, we can see this is the >case, with the Apache code having an assumption >of kernel threads, which you are not permitted >by the POSIX standard to assume. >Although I have not yet verified it, an >examination of the code *seems* to indicate that >it has "the Netscape problem", which is an >assumption about scheduling coming back to a >given thread in a group of threads after >involuntary preemption by the kernel when the >process quantum has expired.
I'm not aware of such an assumption, but maybe I'm blind for having looked at the code so much.
Please send details of this aspect of your review to dev@httpd.apache.org or trawick@apache.org (I'll forward to the mailing list). A fair amount of effort has been spent trying to get Apache 2.0 to work with thread support on various levels of FreeBSD; any knowledge you have of problems in Apache 2.0 which keep it from supporting threads on FreeBSD will be most welcome. There is a lot of interest in having it work.
The current released production tree is still currently the 1.2 tree.
That should be "the currently retired and forgotten-about
production tree is 1.2." Nothing is happening
with the 1.2 series. Apache has no such even/odd numbering system like Linux. 1.3.latest is the release that
the Apache folks recommend for a production
machine. Call 1.2 what you want; just don't
use it.
FYI... "-brtl" does more than just tell the
linker to look in *.a and *.so. If you just
want to tell the linker to look in *.a and *.so,
"-brtl -bnortllib" is much safer. See the ld
documentation on -brtl where it talks about the
enablement of run-time linking.
painful question:( various folks have tried running threaded on FreeBSD... we got weird symptoms that nobody has had time/skills to track down... sadly, I think a FreeBSD pthreads guru is going to need to build a threaded Apache 2.0 and debug it... maybe we're just tickling FreeBSD pthreads the wrong way and a small change would take care of it... maybe current FreeBSD pthreads just can't support threaded Apache... I dunno
even prefork (non-threaded) MPM with a thread-safe APR doesn't work right on FreeBSD... if I recall correctly, the parent process was eating lots of CPU in some sort of signal code...
You don't have to use the threaded model with
Apache 2.0 on Unix. There is a 1.3-style processing model available.
However, a module for Apache 2.0 probably would
want to be thread-aware to avoid requiring that
the admin use the 1.3-style processing model.
On some platforms threads won't beat fork for
speed, but certainly the total virtual memory
usage for a threaded Apache deployment should be
less than for a non-threaded deployment on any platform. For most people this is a non-issue, but in some environments Apache 1.3 is a big problem because of the memory footprint required by the zillions of processes required.
>There are several thousand supported >instructions on IBM's assembler for OS/390. Are you talking directives provided by the assembler or S/390 instructions? You can write an S/390 disassembler in less than several thousand lines including tables. Maybe you're talking about assembly language macros which interface with operating system services (e.g., STORAGE, WTO, ATTACH, etc.)?
Slashdot Mirror
That's something to report via http://nagoya.apache.org/bugzilla/
As far as the --enable-proxy-httpd thing... Apache doesn't look for configure options it doesn't understand and instead assumes that they are for apr or apr-util or libtool or expat or anything else that might be configured under the covers.
Please open a PR at http://nagoya.apache.org/bugzilla/
:(
It apparently doesn't matter how many boxes we build it on, somebody's build is always going to break
(if it makes you feel any better/worse, I built 2.0.46's mod_proxy on a bunch of different boxes today... hopefully we can figure out why it won't build on yours)
What is "companies' subvertion of Apache"? Which companies have done what to Apache httpd, in your opinion?
Lots of active connections handled by the same process can result in lots of mmaps. If these
:) that would be a nice improvement
are large you can start getting worried about
running out of address space with a 32-bit process.
Also, perhaps sendfile works with large file support on Linux in 64-bit mode
For most situations a 64-bit Apache process isn't going to solve any problems right now. I imagine
it will just use more memory.
Yes, I've run Apache 2 as a 64-bit process on AIX and Tru64 as well. And Apache 2 has run as 64-bit process on HP-UX for ia64 for some time.
There have been a few assume-32-bit bugs found here and there and there probably are a few more still out there, but in general people should expect Apache 2 to already work in 64-bit mode with the caveat that it hasn't been tested as much as in 32-bit mode.
My LCD iMac has a fan which is quite loud when it runs. But it rarely runs.
>From looking at the code, we can see this is the >case, with the Apache code having an assumption >of kernel threads, which you are not permitted >by the POSIX standard to assume.
>Although I have not yet verified it, an >examination of the code *seems* to indicate that >it has "the Netscape problem", which is an >assumption about scheduling coming back to a >given thread in a group of threads after >involuntary preemption by the kernel when the >process quantum has expired.
I'm not aware of such an assumption, but maybe
I'm blind for having looked at the code so much.
Please send details of this aspect of your
review to dev@httpd.apache.org or trawick@apache.org (I'll forward to the mailing
list). A fair amount of effort has been spent trying to get Apache 2.0 to work with thread support on various levels of FreeBSD; any
knowledge you have of problems in Apache 2.0 which
keep it from supporting threads on FreeBSD will
be most welcome. There is a lot of interest in
having it work.
That should be "the currently retired and forgotten-about production tree is 1.2." Nothing is happening with the 1.2 series. Apache has no such even/odd numbering system like Linux. 1.3.latest is the release that the Apache folks recommend for a production machine. Call 1.2 what you want; just don't use it.
FYI... "-brtl" does more than just tell the
linker to look in *.a and *.so. If you just
want to tell the linker to look in *.a and *.so,
"-brtl -bnortllib" is much safer. See the ld
documentation on -brtl where it talks about the
enablement of run-time linking.
even prefork (non-threaded) MPM with a thread-safe APR doesn't work right on FreeBSD... if I recall correctly, the parent process was eating lots of CPU in some sort of signal code...
However, a module for Apache 2.0 probably would want to be thread-aware to avoid requiring that the admin use the 1.3-style processing model.
On some platforms threads won't beat fork for speed, but certainly the total virtual memory usage for a threaded Apache deployment should be less than for a non-threaded deployment on any platform. For most people this is a non-issue, but in some environments Apache 1.3 is a big problem because of the memory footprint required by the zillions of processes required.
>There are several thousand supported >instructions on IBM's assembler for OS/390. Are you talking directives provided by the assembler or S/390 instructions? You can write an S/390 disassembler in less than several thousand lines including tables. Maybe you're talking about assembly language macros which interface with operating system services (e.g., STORAGE, WTO, ATTACH, etc.)?