RE: [Patch] non blocking writes in core
Some comments:
@@ -581,6 +564,33 @@
eor_buckets_in_brigade, morphing_bucket_in_brigade);
}
+/* Handle non blocking writes. If we saw a non blocking bucket, attempt
+ * a non blocking write. If the non blocking write would have returned
+ * APR_EGAIN, set aside the remainder and return APR_EAGAIN.
+ */
+if (nonblock_bucket_in_brigade) {
+if (loglevel = APLOG_TRACE6) {
+ap_log_cerror(APLOG_MARK, APLOG_TRACE8, APR_SUCCESS, c,
+ core_output_filter: non blocking write
+ to the network);
+}
+rv = send_brigade_nonblocking(net-client_socket, bb,
+ (ctx-bytes_written), c);
+if (APR_STATUS_IS_EAGAIN(rv)) {
+setaside_remaining_output(f, ctx, bb, c);
+}
+else if (rv != APR_EAGAIN) {
What if rv is APR_SUCCESS?
+/* The client has aborted the connection */
+ap_log_cerror(APLOG_MARK, APLOG_TRACE1, rv, c,
+ core_output_filter: writing data to the network);
+c-aborted = 1;
+}
+return rv;
+}
+
+/* Otherwise handle a normal write. A non blocking write will be attempted,
+ * but we don't return APR_EAGAIN, we return APR_SUCCESS instead.
+ */
if (bytes_in_brigade = THRESHOLD_MIN_WRITE) {
rv = send_brigade_nonblocking(net-client_socket, bb,
(ctx-bytes_written), c);
+AP_DECLARE_DATA const apr_bucket_type_t ap_bucket_type_nonblock = {
+EOC, 5, APR_BUCKET_METADATA,
+apr_bucket_destroy_noop,
I guess this should be something like NBB instead of EOC (copy and paste
error?)
Otherwise looks sensible from a brief look.
Regards
Rüdiger
-Original Message-
From: Graham Leggett
Sent: Sonntag, 17. November 2013 20:41
To: dev@httpd.apache.org
Subject: [Patch] non blocking writes in core
Hi all,
Continuing on from the discussion about how we might support write
completion in mod_ssl, I have come up with the following patch below.
I started by changing the event MPM to call all protocol filters instead
of just the hard coded write filter:
rv = ap_pass_brigade(c-output_filters, cs-bb);
The first thing that this revealed was that we need to pass a non-empty
brigade down the stack. I needed a metadata bucket to pass down the stack
to make the brigade not-empty, and so chose to create a metadata bucket
for this purpose (more on this below).
The second thing that we needed to support for mod_ssl to have any hope of
taking advantage of write completion was non-blocking writes to the core
output filter. This would give mod_ssl the option to setaside any large
buckets (example: file buckets) and allow the core to enter write
completion as soon as it saw EAGAIN.
We can't change the API for ap_pass_brigade() to add a nonblock flag like
an input filter, but we can pass a NONBLOCK metadata bucket down the
stack, and this dovetails nicely with our need for a metadata bucket
above.
So, this patch does the following:
- Takes out the pass NULL to the core output filter hack that supported
write completion previously in the event MPM (other MPMs to follow).
- Add the nonblock bucket, and pass this bucket down the protocol stack
during write completion.
- Teach the core output filter how to react to the NONBLOCK bucket,
returning APR_EAGAIN appropriately when the NONBLOCK bucket is present
(and APR_SUCCESS when not, as per previous behaviour).
In theory, this opens the door for us to support asynchronous filters that
know about NONBLOCK buckets and nonblocking behaviour. In the case of
naive filters, we may end up with existing blocking behaviour during write
completion, but this is no worse than we have now.
Also in theory, all of this can be backported to v2.4.
Regards,
Graham
--
[ANNOUNCEMENT] Apache HTTP Server (httpd) 2.2.26 Released
Apache HTTP Server 2.2.26 Released The Apache Software Foundation and the Apache HTTP Server Project are pleased to announce the release of version 2.2.26 of the Apache HTTP Server (Apache). This version of Apache is principally a bug fix maintenance release. We consider the Apache HTTP Server 2.4 release to be the best version of Apache available, and encourage users of 2.2 and all prior versions to upgrade. This 2.2 maintenance release is offered for those unable to upgrade at this time. For further details, see: http://www.apache.org/dist/httpd/Announcement2.4.txt Apache HTTP Server 2.4 and 2.2.26 are available for download from: http://httpd.apache.org/download.cgi Please see the CHANGES_2.2 file, linked from the download page, for a full list of changes. A condensed list, CHANGES_2.2.26 includes only those changes introduced since the prior 2.2 release. A summary of all of the security vulnerabilities addressed in this and earlier releases is available: http://httpd.apache.org/security/vulnerabilities_22.html This release includes the Apache Portable Runtime (APR) version 1.4.8 and APR Utility Library (APR-util) version 1.5.2, bundled with the tar and zip distributions. The APR libraries libapr and libaprutil (and on Win32, libapriconv version 1.2.1) must all be updated to ensure binary compatibility and address many known security and platform bugs. APR-util version 1.5 represents a minor version upgrade from earlier httpd 2.2 source distributions. This release builds on and extends the Apache 2.0 API and is superceeded by the Apache 2.4 API. Modules written for Apache 2.0 or 2.4 will need to be recompiled in order to run with Apache 2.2, and most will require minimal or no source code changes. When upgrading or installing this version of Apache, please bear in mind that if you intend to use Apache with one of the threaded MPMs (other than the Prefork MPM), you must ensure that any modules you will be using (and the libraries they depend on) are thread-safe.
ssl_die() and pool cleanup
Has anyone looked at making ssl_die() clean up pools on the way out (presumably by calling some function besides exit())? It is rather easy to end up with a bunch of stranded IPC objects while debugging your SSL config. Commentary in ssl_die() suggests a great goal, but that's essentially boiling the ocean at this point. /* * This is used for fatal errors and here * it is common module practice to really * exit from the complete program. * XXX: The config hooks should return errors instead of calling exit(). */ exit(1); -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: svn commit: r1541029 - in /httpd/httpd/trunk: CHANGES include/ap_mmn.h include/http_core.h modules/loggers/mod_syslog.c server/core.c
On Tue, Nov 12, 2013 at 7:14 AM, jkal...@apache.org wrote: Author: jkaluza Date: Tue Nov 12 12:14:50 2013 New Revision: 1541029 URL: http://svn.apache.org/r1541029 Log: Add parse_errorlog_arg callback to ap_errorlog_provider to allow providers to check the ErrorLog argument. Implement this check in mod_syslog. Modified: httpd/httpd/trunk/CHANGES (and other files) IMO it is best to collect CHANGES information for new features under a single, comprehensive entry until the feature is already in a public release and deltas need to be described. That makes it easier for users to digest what features and fixes they pick up with a new release. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 17/11/2013 15:25, Dr Stephen Henson wrote: Evil hack workaround: create a temporary SSL structure from the SSL_CTX of interest after you call SSL_CTX_get_certificate, call SSL_get_certificate on it and then free up the temp SSL structure. That *should* work on all the versions of OpenSSL of interest. That's not very efficient and makes me cringe a bit but you'd only go through it once on start up. Erk typo.. I of course meant ...after you call SSL_CTX_use_certificate_file or SSL_CTX_use_certificate_chain_file... A point to note about SSL_CTX_use_certificate_chain_file, at least in its current form. If the certificate file contains additional certificates this will end up adding them to the SSL_CTX using SSL_CTX_add_extra_chain_cert. That is more efficient as it doesn't have to try and build the chain on each call. Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only have one chain for the SSL_CTX shared by all certificate types and all SSL structures created from it. That means if you have more than one certificate configured and they have different chains the second will replace the first in the SSL_CTX and it will end up sending the wrong chain in some cases. For OpenSSL 1.0.2 this limitation is removed and you can have different chains for each certificate type (and for SSL structures too) and it just uses the right one. This uses the function SSL_CTX_add1_chain_cert which adds a certificate to the chain for the current certificate. I *could* change SSL_CTX_use_certificate_chain_file to use SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps have a different function. I'm always cautious about changing the behaviour of existing functions though as the most innocent change will usually break *something*, though I can't see how it can in this case. Steve. -- Dr Stephen Henson. OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 +1 877-673-6775 shen...@opensslfoundation.com
Re: Intent to TR 2.4.7
Okey dokey... I plan to TR 2.4.7 this Tuesday (tomorrow). This allows 72 hours of voting and pushing to mirrors over the weekend. On Nov 13, 2013, at 11:39 AM, Jim Jagielski j...@jagunet.com wrote: Now that APR 1.5 is soon-to-be released, we are good for a release of 2.4.7. I propose a TR next week (I'll RM) and would request that people look thru STATUS for some remaining backports.
Re: svn commit: r1539988 - /httpd/httpd/trunk/server/log.c
On Fri, Nov 8, 2013 at 6:41 AM, jkal...@apache.org wrote:
Author: jkaluza
Date: Fri Nov 8 11:41:08 2013
New Revision: 1539988
URL: http://svn.apache.org/r1539988
Log:
Do not lose log messages with NULL server_rec when error log provider is
used.
- set stderr_log to NULL after it is redirected to /dev/null
- use log provider of ap_server_conf in log_error_core when no server_rec
is provided and std_err_log is NULL
I think this is resulting in a crash in my provider when ap_log_error() is
called before open-logs (i.e., before my provider has had a chance to set
up a destination for logging).
This is the original 2.4 expectation regarding NULL server_rec IIUC: NULL
is okay until logs are opened, at which point a NULL server_rec is a bug in
the caller. But just pass ap_server_conf when you don't have a
context-specific server_rec and core httpd will make sure it is always set
when logging requires a server_rec.
If at all practical, a NULL server_rec prior to setting up a configured
provider shouldn't be treated differently than a NULL server_rec prior to
setting a configured error log file/piped logger.
My provider is getting a call on this path:
#1 0x71531a7b in elprov_error_log (info=0x7fffb340,
handle=0x0,
errstr=0x7fffb390 AH00558: httpd: Could not reliably determine the
server's fully qualified domain name, using 127.0.1.1. Set the 'ServerName'
directive globally to suppress this message\n,
len=169) at mod_elprov.c:38
#2 0x0046a3f9 in log_error_core (file=0x488f00 util.c,
line=2201, module_index=0,
level=65, status=0, s=0x0, c=0x0, r=0x0, pool=0x6b6138,
fmt=0x489618 AH00558: %s: Could not reliably determine the server's
fully qualified domain name, using %s. Set the 'ServerName' directive
globally to suppress this message, args=0x7fffd408)
at log.c:1259
#3 0x0046a709 in ap_log_perror_ (file=0x488f00 util.c,
line=2201, module_index=0,
level=65, status=0, p=0x6b6138,
fmt=0x489618 AH00558: %s: Could not reliably determine the server's
fully qualified domain name, using %s. Set the 'ServerName' directive
globally to suppress this message) at log.c:1311
#4 0x004335e7 in ap_get_local_host (a=0x6b6138) at util.c:2201
#5 0x0042d9f9 in ap_fini_vhost_config (p=0x6b6138,
main_s=0x6df320) at vhost.c:565
#6 0x0042cac5 in main (argc=2, argv=0x7fffe0e8) at main.c:758
Maybe the handle should be checked (!= NULL) to see if there is a provider
AND we've passed the critical point in the open-logs hook where the
provider becomes usable. The call to the provider's init function in
open-logs will abort startup if NULL is returned for the handle, so handle
will never be NULL if the provider is initialized.
Modified:
httpd/httpd/trunk/server/log.c
Modified: httpd/httpd/trunk/server/log.c
URL:
http://svn.apache.org/viewvc/httpd/httpd/trunk/server/log.c?rev=1539988r1=1539987r2=1539988view=diff
==
--- httpd/httpd/trunk/server/log.c (original)
+++ httpd/httpd/trunk/server/log.c Fri Nov 8 11:41:08 2013
@@ -437,9 +437,12 @@ int ap_open_logs(apr_pool_t *pconf, apr_
#define NULL_DEVICE /dev/null
#endif
-if (replace_stderr freopen(NULL_DEVICE, w, stderr) == NULL) {
-ap_log_error(APLOG_MARK, APLOG_CRIT, errno, s_main, APLOGNO(00093)
- unable to replace stderr with %s, NULL_DEVICE);
+if (replace_stderr) {
+if (freopen(NULL_DEVICE, w, stderr) == NULL) {
+ap_log_error(APLOG_MARK, APLOG_CRIT, errno, s_main,
APLOGNO(00093)
+unable to replace stderr with %s, NULL_DEVICE);
+}
+stderr_log = NULL;
}
for (virt = s_main-next; virt; virt = virt-next) {
@@ -1034,6 +1037,8 @@ static void log_error_core(const char *f
const request_rec *rmain = NULL;
core_server_config *sconf = NULL;
ap_errorlog_info info;
+ap_errorlog_provider *errorlog_provider = NULL;
+void *errorlog_provider_handle = NULL;
/* do we need to log once-per-req or once-per-conn info? */
int log_conn_info = 0, log_req_info = 0;
@@ -1060,6 +1065,10 @@ static void log_error_core(const char *f
#endif
logf = stderr_log;
+if (!logf ap_server_conf ap_server_conf-errorlog_provider)
{
+errorlog_provider = ap_server_conf-errorlog_provider;
+errorlog_provider_handle =
ap_server_conf-errorlog_provider_handle;
+}
}
else {
int configured_level = r ? ap_get_request_module_loglevel(r,
module_index):
@@ -1078,6 +1087,9 @@ static void log_error_core(const char *f
logf = s-error_log;
}
+errorlog_provider = s-errorlog_provider;
+errorlog_provider_handle = s-errorlog_provider_handle;
+
/* the faked server_rec from mod_cgid does not have
s-module_config */
if (s-module_config)
Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
For the mod_perl crash with Event that I posted at the URL below, I would suspect that there's some affinity with the original worker thread. Can anyone in mod_perl land confirm? http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E I'm also aware of a third-party diagnostic module that could use a hint, and in general I wonder if anyone knows of specific interface requirements that would need to be provided by a new hook for indicating when a connection or request leaves the original thread or is handled by a new one. -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@gmail.com wrote: For the mod_perl crash with Event that I posted at the URL below, I would suspect that there's some affinity with the original worker thread. Can anyone in mod_perl land confirm? http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E I'm also aware of a third-party diagnostic module that could use a hint, and in general I wonder if anyone knows of specific interface requirements that would need to be provided by a new hook for indicating when a connection or request leaves the original thread or is handled by a new one. I can't see any need for more than request_rec on both ends.
Re: http_filter.c r1524770 open issue?
On Thu, 14 Nov 2013 00:22:55 +0100 Yann Ylavic ylavic@gmail.com wrote: On Thu, Nov 14, 2013 at 12:05 AM, William A. Rowe Jr. wr...@rowe-clan.netwrote: On Wed, 13 Nov 2013 17:14:15 -0500 Jim Jagielski j...@jagunet.com wrote: On Nov 13, 2013, at 2:25 AM, William A. Rowe Jr. wr...@rowe-clan.net wrote: Here we've unset C-L and T-E. but it makes no sense to wait if the origin server has no immediate plan to close the connection. I cannot grok the above. The RFC itself does not make the differentiation between keepalive connections or not. So what exactly is the issue? Are you saying we should handle keepalive connections in this path differently? How is that supported by the spec? Keep-alive (implicit in HTTP/1.1 absent a Connection: close header) is orthogonal to an unknown message body. Think about it :) Regarding the connection persistance, http://tools.ietf.org/id/draft-ietf-httpbis-p1-messaging-24.html#rfc.section.6.3states : In order to remain persistent, all messages on a connection MUST have a self-defined message length (i.e., one not defined by closure of the connection), as described in Section 3.3. So no keepalive is possible if the message length (content-coding) is undefined. Correct. It is NOT kept alive by the client (httpd) in this proxy case. But (to Jim's statement) the next-hop server claims it *is* kept alive and will handle the socket as kept-alive... That could be a valid HTTP response : HTTP/1.1 200 OK Transfer-Encoding: x-cleverness Content-Length: 1000 but still the C-L must be ignored by the receiver, and a read-until-close be used by it. [Thank you for correcting me, the issue at hand is strictly with proxy response body processing in the first place.] Because the server claims it is keep-alive. It will send its thousand bytes (decorated by whatever x-cleverness might frame it with), and will then enter a keepalive loop. WE won't enter a keepalive loop, because we won't reuse the connection. But the next-hop server is keeping it alive for whatever duration it believes it should be waiting for the next request from the client (httpd). And in the interim, we are hung and holding our client's response open. At best you can describe this as a waste of worker requests, and at worst, as a mild DoS. We need to perform a lingering close (reading until our read end was closed by the next-hop server). The question is whether we tolerate the forwarding of keep-alive, other-than-'chunked' T-E proxy responses? By closing our write-end of the connection, we can signal to the server that we can't efficiently forward their response to the client (owing to the fact that the server believes this to be a keep-alive connection, and that we can't know where this specific response ends, until the server has given up on receiving another keep-alive request). My vote on this patch right now is -0. I don't believe it must be applied to 2.4.x this moment for this coming release and would prefer that we alter the behavior as of a specific release, not incrementally across several different releases (e.g. 2.4.6 w/ old behavior, 2.4.7 with an interim behavior and 2.4.8 with yet a third behavior). But I won't block the patch further if it has the votes for backport now.
Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
On Nov 18, 2013, at 12:15 PM, Eric Covener cove...@gmail.com wrote: On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@gmail.com wrote: For the mod_perl crash with Event that I posted at the URL below, I would suspect that there's some affinity with the original worker thread. Can anyone in mod_perl land confirm? http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E I'm also aware of a third-party diagnostic module that could use a hint, and in general I wonder if anyone knows of specific interface requirements that would need to be provided by a new hook for indicating when a connection or request leaves the original thread or is handled by a new one. I can't see any need for more than request_rec on both ends. mod_spdy uses a fake conn_rec, well, more like a sub-conn_rec ala a subrequest, which is also sometimes called a slave connection... I'm thinking that maybe having such an entity here would be best, long term.
Playing with cmake: LONG_NAME= problems
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will be
common for everybody using project files for Visual Studio 2005 and later:
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all the
'' escaping problems by using the APR_STRINGIFY() macro. That allows simply
passing the value.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName, http://subversion.apache.org/\0;
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE FileVersion, SVN_VER_NUMBER \0
VALUE InternalName, SVN\0
VALUE LegalCopyright, Copyright (c) The Apache Software
Foundation\0
VALUE OriginalFilename, APR_STRINGIFY(SVN_FILE_NAME) \0
VALUE ProductName, Subversion\0
VALUE ProductVersion, SVN_VERSION \0
#ifdef SVN_SPECIALBUILD
VALUE SpecialBuild, SVN_SPECIALBUILD \0
#endif
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
I've fixed the problem for me with a local hack, but I think many future
users of the cmake build scripts would be very happy if this problem could
be fixed in the standard scripts.
In my case that would allow me to reduce my own patches, to cmake specific
things. (E.g. I like to have .pdb files even for the fully optimized builds,
and cmake doesn't support that scenario)
Bert
Re: Does mod_perl/mod_??? need a hook called when a request/conn leaves the original worker thread?
Ouch, I meant to sent this to dev@perl instead of dev@apr... On Mon, Nov 18, 2013 at 10:58 AM, Jeff Trawick traw...@gmail.com wrote: For the mod_perl crash with Event that I posted at the URL below, I would suspect that there's some affinity with the original worker thread. Can anyone in mod_perl land confirm? http://mail-archives.apache.org/mod_mbox/perl-dev/201311.mbox/%3CCAKUrXK6C3R_F3NdA%2BJUGYOqppvnoQJLTGQ9%2BA916vuMb0g9dig%40mail.gmail.com%3E I'm also aware of a third-party diagnostic module that could use a hint, and in general I wonder if anyone knows of specific interface requirements that would need to be provided by a new hook for indicating when a connection or request leaves the original thread or is handled by a new one. -- Born in Roswell... married an alien... http://emptyhammock.com/ -- Born in Roswell... married an alien... http://emptyhammock.com/
Re: Deprecating (and eventually removing) encrypted private key support in mod_ssl?
On 18.11.2013 15:38, Dr Stephen Henson wrote:
Erk typo.. I of course meant ...after you call SSL_CTX_use_certificate_file
or
SSL_CTX_use_certificate_chain_file...
Yeah this was obvious... makes me cringe as well but here we go:
https://people.apache.org/~kbrand/mod_ssl_pkey_2013-11-18_wip.patch
(interdiff attached to this message)
For the SSL_CONF_cmd loop, I had to insert a call to
ssl_stapling_init_cert as well - currently I'm testing for the
Certificate parameter name being set, but if there's a better way to
figure out if we need to call ssl_stapling_init_cert, I'm all ears.
Unfortunately due to a limitation in OpenSSL 1.0.1 and earlier you can only
have
one chain for the SSL_CTX shared by all certificate types and all SSL
structures
created from it.
That means if you have more than one certificate configured and they have
different chains the second will replace the first in the SSL_CTX and it will
end up sending the wrong chain in some cases.
Right, that's essentially what the last paragraph of the
SSLCertificateChainFile is stating
(http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslcertificatechainfile),
so I wouldn't worry too much about the behavior with releases up to 1.0.1.
For OpenSSL 1.0.2 this limitation is removed and you can have different chains
for each certificate type (and for SSL structures too) and it just uses the
right one. This uses the function SSL_CTX_add1_chain_cert which adds a
certificate to the chain for the current certificate.
I *could* change SSL_CTX_use_certificate_chain_file to use
SSL_CTX_add1_chain_cert instead of SSL_CTX_add_extra_chain_cert or perhaps
have
a different function. I'm always cautious about changing the behaviour of
existing functions though as the most innocent change will usually break
*something*, though I can't see how it can in this case.
I would be in favor this change for 1.0.2 - to me that would be more
like a fix of SSL_CTX_use_certificate_chain_file than a change in
behavior, actually.
Kaspar
diff -u trunk/modules/ssl/ssl_engine_init.c trunk/modules/ssl/ssl_engine_init.c
--- trunk/modules/ssl/ssl_engine_init.c (working copy)
+++ trunk/modules/ssl/ssl_engine_init.c (working copy)
@@ -836,6 +836,8 @@
DH *dhparams;
ssl_asn1_t *asn1;
EVP_PKEY *pkey;
+SSL *ssl;
+X509 *cert;
SSLModConfigRec *mc = myModConfig(s);
const char *certfile, *keyfile;
@@ -889,31 +891,39 @@
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO()
Certificate and private key #%d for %s do not match,
i + 1, vhost_id);
-/*
- * XXX we can't call ssl_check_public_cert() here, currently,
- * as there's no way to get at the X509 * which was configured
- * by SSL_CTX_use_certificate_[chain_]file... eventually, we
- * would probably want to call:
- * ssl_check_public_cert(s, ptemp, cert, i + 1);
- */
break;
}
+/*
+ * workaround for those OpenSSL versions where SSL_CTX_get_certificate
+ * is not yet available: create an SSL * which we'll simply throw away
+ * a few lines further down
+ */
+if (!(ssl = SSL_new(mctx-ssl_ctx)) ||
+!(cert = SSL_get_certificate(ssl))) {
+ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO()
+ Unable to retrieve certificate #%d for %s,
+ i + 1, vhost_id);
+if (ssl)
+SSL_free(ssl);
+break;
+}
+
+/* warn about potential cert issues */
+ssl_check_public_cert(s, ptemp, cert, i + 1);
+
#ifdef HAVE_OCSP_STAPLING
if ((mctx-pkp == FALSE) (mctx-stapling_enabled == TRUE)) {
-/*
- * XXX can't call ssl_stapling_init_cert currently, for the
- * same reason as above with ssl_check_public_cert
- *
if (!ssl_stapling_init_cert(s, mctx, cert)) {
ap_log_error(APLOG_MARK, APLOG_ERR, 0, s, APLOGNO(02235)
Unable to configure certificate #%d for %s
for stapling, i + 1, vhost_id);
}
- */
}
#endif
+SSL_free(ssl);
+
ap_log_error(APLOG_MARK, APLOG_INFO, 0, s, APLOGNO()
Certificate and key #%d for %s configured from %s and
%s,
i + 1, vhost_id, certfile, keyfile);
@@ -1189,6 +1199,23 @@
ssl_log_ssl_error(SSLLOG_MARK, APLOG_EMERG, s);
ssl_die(s);
}
+#ifdef HAVE_OCSP_STAPLING
+if (!strcasecmp(param-name, Certificate)
+sc-server-stapling_enabled == TRUE) {
+SSL *ssl;
+X509 *cert;
+if (!(ssl = SSL_new(sc-server-ssl_ctx)) ||
+!(cert = SSL_get_certificate(ssl)) ||
+!ssl_stapling_init_cert(s, sc-server,
Re: RLIMIT_NPROC on Linux?
current apachectl: # # Set this variable to a command that increases the maximum # number of file descriptors allowed per child process. This is # critical for configurations that use many file descriptors, # such as mass vhosting, or a multithreaded server. ULIMIT_MAX_FILES=ulimit -S -n `ulimit -H -n` # # END CONFIGURATION SECTION # Set the maximum number of file descriptors allowed per child process. if [ x$ULIMIT_MAX_FILES != x ] ; then $ULIMIT_MAX_FILES fi Should we do the same for threads/processes? I was going to propose this for some kind of startup code, and realized there was some old precedent. The downside is that we don't yet know MaxClients is large, as we could in code. On Tue, Nov 12, 2013 at 3:00 PM, Eric Covener cove...@gmail.com wrote: IMHO this explains it as limits.conf is a configuration file for PAM. If you don't use any PAM methods (haven't worked out which would be needed) in the code the limits will not be applied after setuid. Of course pam_limits.so need to be configured for session for your app as well. Ah, that helps - -thanks! -- Eric Covener cove...@gmail.com
Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben b...@qqmail.nl wrote:
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will be
common for everybody using project files for Visual Studio 2005 and later:
I don't doubt it, but just for fun: Exactly which generator/studio version
were you using, in case I have a problem reproducing?
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all the
'' escaping problems by using the APR_STRINGIFY() macro. That allows
simply
passing the value.
We do that two, though with a little indirection:
#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)
#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)
VALUE FileDescription, LONG_NAME_STR \0
VALUE FileVersion, AP_SERVER_BASEREVISION \0
VALUE InternalName, BIN_NAME_STR \0
VALUE LegalCopyright, AP_SERVER_COPYRIGHT \0
VALUE OriginalFilename, BIN_NAME_STR \0
I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to try
to put literal quotes there.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName, http://subversion.apache.org/\0;
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE FileVersion, SVN_VER_NUMBER \0
VALUE InternalName, SVN\0
VALUE LegalCopyright, Copyright (c) The Apache Software
Foundation\0
VALUE OriginalFilename, APR_STRINGIFY(SVN_FILE_NAME) \0
VALUE ProductName, Subversion\0
VALUE ProductVersion, SVN_VERSION \0
#ifdef SVN_SPECIALBUILD
VALUE SpecialBuild, SVN_SPECIALBUILD \0
#endif
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
I've fixed the problem for me with a local hack, but I think many future
users of the cmake build scripts would be very happy if this problem could
be fixed in the standard scripts.
In my case that would allow me to reduce my own patches, to cmake specific
things. (E.g. I like to have .pdb files even for the fully optimized
builds,
and cmake doesn't support that scenario)
Bert
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: RLIMIT_NPROC on Linux?
On Mon, 18 Nov 2013 12:52:26 -0500 Eric Covener cove...@gmail.com wrote: # Set the maximum number of file descriptors allowed per child process. if [ x$ULIMIT_MAX_FILES != x ] ; then $ULIMIT_MAX_FILES fi Should we do the same for threads/processes? I was going to propose this for some kind of startup code, and realized there was some old precedent. The downside is that we don't yet know MaxClients is large, as we could in code. Keep in mind, we also don't know if we are launching one rotatelogs per log file, our cgi requirements, etc etc etc. There are too many variables to know what our actual process count requirement really is. We could go with a number such as current ulimit -Su + MaxClients, or we could go with the hardlimit (of root, or of the httpd User), or... ???
Re: Intent to TR 2.4.7
*Finally* ran this through my test cases with three poundings with wrk. Here are the requests/sec: httpd (2.4 + proposed UDS patch) Req/Sec 147.34 28.89 282.00 71.38% Req/Sec 147.48 27.18 250.00 67.75% Req/Sec 147.87 28.17 239.00 70.94% nginx Req/Sec 180.99 27.81 311.00 77.92% Req/Sec 183.46 32.59 369.00 72.44% Req/Sec 176.81 28.18 325.00 71.99% Three samples with 30 second tests is far from scientific, but I think illustrates general timings (and, more importantly, that it works!). -- Daniel Ruggeri On 11/14/2013 9:56 AM, Jim Jagielski wrote: What the heck. STATUS is updated w/ the backport proposal and the patch... On Nov 14, 2013, at 7:46 AM, Jim Jagielski j...@jagunet.com wrote: I'd like to yes, but I don't want to push 2.4.7 out much longer. There are other things in STATUS, like the event patches which have been running on ASF infra for quite awhile, that I'd like to see in 2.4.7 when we ship. We can save UDS for 2.4.8 and make that a(nother) reason for people to upgrade. On Nov 13, 2013, at 8:27 PM, Daniel Ruggeri drugg...@primary.net wrote: On 11/13/2013 10:39 AM, Jim Jagielski wrote: Now that APR 1.5 is soon-to-be released, we are good for a release of 2.4.7. I propose a TR next week (I'll RM) and would request that people look thru STATUS for some remaining backports. Are you hoping to push for UDS in 2.4.7? Seems like a great feature... (yes, I'm guilty in not testing out the latest trunk patches and providing feedback - I had planned to do that last week... and this week... and probably next week) -- Daniel Ruggeri
Re: Intent to TR 2.4.7
Oops - I copypasta'd the per-thread stats. Total stats for the test follow: httpd: Requests/sec: 4633.17 Requests/sec: 4664.49 Requests/sec: 4657.63 nginx: Requests/sec: 5701.16 Requests/sec: 5798.08 Requests/sec: 5584.60 -- Daniel Ruggeri On 11/18/2013 1:09 PM, Daniel Ruggeri wrote: httpd (2.4 + proposed UDS patch) Req/Sec 147.34 28.89 282.00 71.38% Req/Sec 147.48 27.18 250.00 67.75% Req/Sec 147.87 28.17 239.00 70.94% nginx Req/Sec 180.99 27.81 311.00 77.92% Req/Sec 183.46 32.59 369.00 72.44% Req/Sec 176.81 28.18 325.00 71.99%
Re: Intent to TR 2.4.7
And... this is a bit discouraging, but as a comparison to the older UDS patch 2.4.6 + original UDS patch: Requests/sec: 5347.17 Requests/sec: 5102.16 Requests/sec: 5074.15 This is a sizable difference... Note that the current 2.4 backport proposal was applied to 2.4.6 since that is what I tested the original patch with (to keep everything apples to apples). I'll jump in to take a look at this when time is available (next week?) but would like to fish for any immediate thoughts in the mean time. -- Daniel Ruggeri On 11/18/2013 1:11 PM, Daniel Ruggeri wrote: Oops - I copypasta'd the per-thread stats. Total stats for the test follow: httpd: Requests/sec: 4633.17 Requests/sec: 4664.49 Requests/sec: 4657.63 nginx: Requests/sec: 5701.16 Requests/sec: 5798.08 Requests/sec: 5584.60
Re: Intent to TR 2.4.7
I can think or see anything in the actual request handling aspect that's any different from the original proposal, certainly nothing that would result in any sort of performance issue. What MPM? Have you tried w/ 2.4.6? On Nov 18, 2013, at 2:39 PM, Daniel Ruggeri drugg...@primary.net wrote: And... this is a bit discouraging, but as a comparison to the older UDS patch 2.4.6 + original UDS patch: Requests/sec: 5347.17 Requests/sec: 5102.16 Requests/sec: 5074.15 This is a sizable difference... Note that the current 2.4 backport proposal was applied to 2.4.6 since that is what I tested the original patch with (to keep everything apples to apples). I'll jump in to take a look at this when time is available (next week?) but would like to fish for any immediate thoughts in the mean time. -- Daniel Ruggeri On 11/18/2013 1:11 PM, Daniel Ruggeri wrote: Oops - I copypasta'd the per-thread stats. Total stats for the test follow: httpd: Requests/sec: 4633.17 Requests/sec: 4664.49 Requests/sec: 4657.63 nginx: Requests/sec: 5701.16 Requests/sec: 5798.08 Requests/sec: 5584.60
Re: Intent to TR 2.4.7
Hmm... maybe a re-use issue? Let me look. On Nov 18, 2013, at 3:36 PM, Jim Jagielski j...@jagunet.com wrote: I can think or see anything in the actual request handling aspect that's any different from the original proposal, certainly nothing that would result in any sort of performance issue. What MPM? Have you tried w/ 2.4.6? On Nov 18, 2013, at 2:39 PM, Daniel Ruggeri drugg...@primary.net wrote: And... this is a bit discouraging, but as a comparison to the older UDS patch 2.4.6 + original UDS patch: Requests/sec: 5347.17 Requests/sec: 5102.16 Requests/sec: 5074.15 This is a sizable difference... Note that the current 2.4 backport proposal was applied to 2.4.6 since that is what I tested the original patch with (to keep everything apples to apples). I'll jump in to take a look at this when time is available (next week?) but would like to fish for any immediate thoughts in the mean time. -- Daniel Ruggeri On 11/18/2013 1:11 PM, Daniel Ruggeri wrote: Oops - I copypasta'd the per-thread stats. Total stats for the test follow: httpd: Requests/sec: 4633.17 Requests/sec: 4664.49 Requests/sec: 4657.63 nginx: Requests/sec: 5701.16 Requests/sec: 5798.08 Requests/sec: 5584.60
RE: Playing with cmake: LONG_NAME= problems
Hi Jeff,
Thanks for looking into this.
I tried the Visual Studio 9 and Visual Studio 11 generators in both standard
Win32 and x64 forms. Both of these have similar problems even though the
first uses .vcproj files and the late .vcxproj files.
The cmake generated code is accepted by the resource compiler argument
parser but then fails during the resource compile stage.
It appears that the code does work for some cases where the long name only
contains a single word, but it always fails when there are multiple words.
Bert
From: Jeff Trawick [mailto:traw...@gmail.com]
Sent: maandag 18 november 2013 19:22
To: Apache HTTP Server Development List
Subject: Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben b...@qqmail.nl
mailto:b...@qqmail.nl wrote:
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will be
common for everybody using project files for Visual Studio 2005 and later:
I don't doubt it, but just for fun: Exactly which generator/studio version
were you using, in case I have a problem reproducing?
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all the
'' escaping problems by using the APR_STRINGIFY() macro. That allows simply
passing the value.
We do that two, though with a little indirection:
#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)
#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)
VALUE FileDescription, LONG_NAME_STR \0
VALUE FileVersion, AP_SERVER_BASEREVISION \0
VALUE InternalName, BIN_NAME_STR \0
VALUE LegalCopyright, AP_SERVER_COPYRIGHT \0
VALUE OriginalFilename, BIN_NAME_STR \0
I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to try
to put literal quotes there.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName, http://subversion.apache.org/\0
http://subversion.apache.org/0
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE FileVersion, SVN_VER_NUMBER \0
VALUE InternalName, SVN\0
VALUE LegalCopyright, Copyright (c) The Apache Software
Foundation\0
VALUE OriginalFilename, APR_STRINGIFY(SVN_FILE_NAME) \0
VALUE ProductName, Subversion\0
VALUE ProductVersion, SVN_VERSION \0
#ifdef SVN_SPECIALBUILD
VALUE SpecialBuild, SVN_SPECIALBUILD \0
#endif
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
I've fixed the problem for me with a local hack, but I think many future
users of the cmake build scripts would be very happy if this problem could
be fixed in the standard scripts.
In my case that would allow me to reduce my own patches, to cmake specific
things. (E.g. I like to have .pdb files even for the fully optimized builds,
and cmake doesn't support that scenario)
Bert
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Intent to TR 2.4.7
yeah, I'm thinking
/*
* Figure out if our passed in proxy_conn_rec has a usable
* address cached.
*
* TODO: Handle this much better...
*
* XXX: If generic workers are ever address-reusable, we need
* to check host and port on the conn and be careful about
* spilling the cached addr from the worker.
*/
if (!conn-hostname || !worker-s-is_address_reusable ||
worker-s-disablereuse || *worker-s-uds_path) {
if (proxyname) {
conn-hostname = apr_pstrdup(conn-pool, proxyname);
conn-port = proxyport;
isn't right...
On Nov 18, 2013, at 3:43 PM, Jim Jagielski j...@jagunet.com wrote:
Hmm... maybe a re-use issue? Let me look.
On Nov 18, 2013, at 3:36 PM, Jim Jagielski j...@jagunet.com wrote:
I can think or see anything in the actual request handling
aspect that's any different from the original proposal,
certainly nothing that would result in any sort of
performance issue.
What MPM? Have you tried w/ 2.4.6?
On Nov 18, 2013, at 2:39 PM, Daniel Ruggeri drugg...@primary.net wrote:
And... this is a bit discouraging, but as a comparison to the older UDS
patch
2.4.6 + original UDS patch:
Requests/sec: 5347.17
Requests/sec: 5102.16
Requests/sec: 5074.15
This is a sizable difference... Note that the current 2.4 backport
proposal was applied to 2.4.6 since that is what I tested the original
patch with (to keep everything apples to apples).
I'll jump in to take a look at this when time is available (next week?)
but would like to fish for any immediate thoughts in the mean time.
--
Daniel Ruggeri
On 11/18/2013 1:11 PM, Daniel Ruggeri wrote:
Oops - I copypasta'd the per-thread stats. Total stats for the test follow:
httpd:
Requests/sec: 4633.17
Requests/sec: 4664.49
Requests/sec: 4657.63
nginx:
Requests/sec: 5701.16
Requests/sec: 5798.08
Requests/sec: 5584.60
Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben b...@qqmail.nl wrote:
Hi Jeff,
Thanks for looking into this.
I tried the Visual Studio 9 and Visual Studio 11 generators in both
standard Win32 and x64 forms. Both of these have similar problems even
though the first uses .vcproj files and the late .vcxproj files.
The cmake generated code is accepted by the resource compiler argument
parser but then fails during the resource compile stage.
It appears that the code does work for some cases where the long name only
contains a single word, but it always fails when there are multiple words.
Bert
Cool... In the meantime, I have a fix in trunk (r1543149) and am building
the 2.4.x fix with Visual Studio 2010 currently. (Luckily exiftool makes
it easy to quickly check File Description.)
*From:* Jeff Trawick [mailto:traw...@gmail.com]
*Sent:* maandag 18 november 2013 19:22
*To:* Apache HTTP Server Development List
*Subject:* Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben b...@qqmail.nl wrote:
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will be
common for everybody using project files for Visual Studio 2005 and later:
I don't doubt it, but just for fun: Exactly which generator/studio version
were you using, in case I have a problem reproducing?
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all the
'' escaping problems by using the APR_STRINGIFY() macro. That allows
simply
passing the value.
We do that two, though with a little indirection:
#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)
#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)
VALUE FileDescription, LONG_NAME_STR \0
VALUE FileVersion, AP_SERVER_BASEREVISION \0
VALUE InternalName, BIN_NAME_STR \0
VALUE LegalCopyright, AP_SERVER_COPYRIGHT \0
VALUE OriginalFilename, BIN_NAME_STR \0
I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to try
to put literal quotes there.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName,
http://subversion.apache.org/\0http://subversion.apache.org/0
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE FileVersion, SVN_VER_NUMBER \0
VALUE InternalName, SVN\0
VALUE LegalCopyright, Copyright (c) The Apache Software
Foundation\0
VALUE OriginalFilename, APR_STRINGIFY(SVN_FILE_NAME) \0
VALUE ProductName, Subversion\0
VALUE ProductVersion, SVN_VERSION \0
#ifdef SVN_SPECIALBUILD
VALUE SpecialBuild, SVN_SPECIALBUILD \0
#endif
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
I've fixed the problem for me with a local hack, but I think many future
users of the cmake build scripts would be very happy if this problem could
be fixed in the standard scripts.
In my case that would allow me to reduce my own patches, to cmake specific
things. (E.g. I like to have .pdb files even for the fully optimized
builds,
and cmake doesn't support that scenario)
Bert
--
Born in Roswell... married an alien...
http://emptyhammock.com/
--
Born in Roswell... married an alien...
http://emptyhammock.com/
Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick traw...@gmail.com wrote:
On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben b...@qqmail.nl wrote:
Hi Jeff,
Thanks for looking into this.
I tried the Visual Studio 9 and Visual Studio 11 generators in both
standard Win32 and x64 forms. Both of these have similar problems even
though the first uses .vcproj files and the late .vcxproj files.
The cmake generated code is accepted by the resource compiler argument
parser but then fails during the resource compile stage.
It appears that the code does work for some cases where the long name
only contains a single word, but it always fails when there are multiple
words.
Bert
Cool... In the meantime, I have a fix in trunk (r1543149) and am building
the 2.4.x fix with Visual Studio 2010 currently. (Luckily exiftool makes
it easy to quickly check File Description.)
r1543165 is the 2.4.x fix
*From:* Jeff Trawick [mailto:traw...@gmail.com]
*Sent:* maandag 18 november 2013 19:22
*To:* Apache HTTP Server Development List
*Subject:* Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben b...@qqmail.nl wrote:
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using
the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will
be
common for everybody using project files for Visual Studio 2005 and later:
I don't doubt it, but just for fun: Exactly which generator/studio
version were you using, in case I have a problem reproducing?
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all
the
'' escaping problems by using the APR_STRINGIFY() macro. That allows
simply
passing the value.
We do that two, though with a little indirection:
#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)
#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)
VALUE FileDescription, LONG_NAME_STR \0
VALUE FileVersion, AP_SERVER_BASEREVISION \0
VALUE InternalName, BIN_NAME_STR \0
VALUE LegalCopyright, AP_SERVER_COPYRIGHT \0
VALUE OriginalFilename, BIN_NAME_STR \0
I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to
try to put literal quotes there.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName,
http://subversion.apache.org/\0http://subversion.apache.org/0
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE FileVersion, SVN_VER_NUMBER \0
VALUE InternalName, SVN\0
VALUE LegalCopyright, Copyright (c) The Apache Software
Foundation\0
VALUE OriginalFilename, APR_STRINGIFY(SVN_FILE_NAME) \0
VALUE ProductName, Subversion\0
VALUE ProductVersion, SVN_VERSION \0
#ifdef SVN_SPECIALBUILD
VALUE SpecialBuild, SVN_SPECIALBUILD \0
#endif
END
END
BLOCK VarFileInfo
BEGIN
VALUE Translation, 0x409, 1200
END
END
I've fixed the problem for me with a local hack, but I think many future
users of the cmake build scripts would be very happy if this problem could
be fixed in the standard scripts.
In my case that would allow me to reduce my own patches, to cmake specific
things. (E.g. I like to have .pdb files even for the fully optimized
builds,
and cmake doesn't support that scenario)
Bert
--
Born in Roswell... married an alien...
http://emptyhammock.com/
--
Born in Roswell... married an alien...
http://emptyhammock.com/
--
Born in Roswell... married an alien...
http://emptyhammock.com/
UDS Patch
Can you retry with this applied: https://svn.apache.org/viewvc?view=revisionrevision=1543174 On Nov 18, 2013, at 2:39 PM, Daniel Ruggeri drugg...@primary.net wrote: And... this is a bit discouraging, but as a comparison to the older UDS patch 2.4.6 + original UDS patch: Requests/sec: 5347.17 Requests/sec: 5102.16 Requests/sec: 5074.15 This is a sizable difference... Note that the current 2.4 backport proposal was applied to 2.4.6 since that is what I tested the original patch with (to keep everything apples to apples). I'll jump in to take a look at this when time is available (next week?) but would like to fish for any immediate thoughts in the mean time. -- Daniel Ruggeri On 11/18/2013 1:11 PM, Daniel Ruggeri wrote: Oops - I copypasta'd the per-thread stats. Total stats for the test follow: httpd: Requests/sec: 4633.17 Requests/sec: 4664.49 Requests/sec: 4657.63 nginx: Requests/sec: 5701.16 Requests/sec: 5798.08 Requests/sec: 5584.60
Re: UDS Patch
On 11/18/2013 3:38 PM, Jim Jagielski wrote:
Can you retry with this applied:
https://svn.apache.org/viewvc?view=revisionrevision=1543174
Definitely. I'll report back tomorrow so long as the universe wills
it... but one last note
I failed to mention in my original notes that there were two hunks that
didn't apply cleanly to 2.4.6 - these appear to be from this change:
https://svn.apache.org/viewvc/httpd/httpd/branches/2.4.x/modules/proxy/proxy_util.c?r1=1511313r2=1511312pathrev=1511313
... which is in the neighborhood of what you adjusted in r1543174... but
doesn't appear to conflict directly.
I'm thinking I should also apply r1511313 to 2.4.6 as a prereq to
r1543174 in order to remove ambiguity... I'm frankly not sure if the
machine was performing DNS lookups during the test or not (and I have
only given this a cursory review), but that would *definitely* account
for a measurable slowdown.
The context of what was rejected:
--- modules/proxy/proxy_util.c
+++ modules/proxy/proxy_util.c
@@ -2228,7 +2324,8 @@
conn-port = uri-port;
}
socket_cleanup(conn);
-if (!worker-s-is_address_reusable || worker-s-disablereuse) {
+if (!(*worker-s-uds_path)
+(!worker-s-is_address_reusable ||
worker-s-disablereuse)) {
/*
* Only do a lookup if we should not reuse the backend
address.
* Otherwise we will look it up once for the worker.
@@ -2239,7 +2336,7 @@
conn-pool);
}
}
-if (worker-s-is_address_reusable !worker-s-disablereuse) {
+if (!(*worker-s-uds_path) worker-s-is_address_reusable
!worker-s-disablereuse) {
/*
* Looking up the backend address for the worker only makes
sense if
* we can reuse the address.
I'll have to see what the delta with both patches applied turns out to be...
--
Daniel Ruggeri
RE: Playing with cmake: LONG_NAME= problems
Hi Jeff,
I can confirm that this fixes the LONG_NAME problems :)
I have one remaining problem, that I hoped would be fixed by the same fix
you applied, but it wasn't.
If the httpd build directory contains a '-', such as in my case
'F:\svn-dev\build\httpd', then the ICON_FILE argument doesn't get through as
a valid token.
[[
build\win32\httpd.rc(34): error RC2135: file not found: F:/svn
[F:\svn-dev\build\httpd\httpd.vcxproj]
build\win32\httpd.rc(40): error RC2135: file not found: VERSIONINFO
[F:\svn-dev\build\httpd\httpd.vcxproj]
build\win32\httpd.rc(41): error RC2135: file not found: 4
[F:\svn-dev\build\httpd\httpd.vcxproj]
build\win32\httpd.rc(42): error RC2135: file not found: PRODUCTVERSION
[F:\svn-dev\build\httpd\httpd.vcxproj]
]]
The generated line in httpd.vcxproj is now:
PreprocessorDefinitionsWIN32;_WINDOWS;NDEBUG;APP_FILE;LONG_NAME=Apache
HTTP
Server;BIN_NAME=httpd.exe;ICON_FILE=F:/svn-dev/build/httpd/build/win32/apach
e.ico;CMAKE_INTDIR=\Release\;%(PreprocessorDefinitions)/PreprocessorDefin
itions
I can fix this by updating the relevant lines in build/win32/httpd.rc from
[[
#ifdef ICON_FILE
1 ICON DISCARDABLE ICON_FILE
#endif
]]
to
#ifdef ICON_FILE
1 ICON DISCARDABLE APR_STRINGIFY(ICON_FILE)
#endif
Bert
From: Jeff Trawick [mailto:traw...@gmail.com]
Sent: maandag 18 november 2013 22:19
To: Apache HTTP Server Development List
Subject: Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick traw...@gmail.com
mailto:traw...@gmail.com wrote:
On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben b...@qqmail.nl
mailto:b...@qqmail.nl wrote:
Hi Jeff,
Thanks for looking into this.
I tried the Visual Studio 9 and Visual Studio 11 generators in both standard
Win32 and x64 forms. Both of these have similar problems even though the
first uses .vcproj files and the late .vcxproj files.
The cmake generated code is accepted by the resource compiler argument
parser but then fails during the resource compile stage.
It appears that the code does work for some cases where the long name only
contains a single word, but it always fails when there are multiple words.
Bert
Cool... In the meantime, I have a fix in trunk (r1543149) and am building
the 2.4.x fix with Visual Studio 2010 currently. (Luckily exiftool makes it
easy to quickly check File Description.)
r1543165 is the 2.4.x fix
From: Jeff Trawick [mailto:traw...@gmail.com mailto:traw...@gmail.com ]
Sent: maandag 18 november 2013 19:22
To: Apache HTTP Server Development List
Subject: Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben b...@qqmail.nl
mailto:b...@qqmail.nl wrote:
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will be
common for everybody using project files for Visual Studio 2005 and later:
I don't doubt it, but just for fun: Exactly which generator/studio version
were you using, in case I have a problem reproducing?
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all the
'' escaping problems by using the APR_STRINGIFY() macro. That allows simply
passing the value.
We do that two, though with a little indirection:
#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)
#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)
VALUE FileDescription, LONG_NAME_STR \0
VALUE FileVersion, AP_SERVER_BASEREVISION \0
VALUE InternalName, BIN_NAME_STR \0
VALUE LegalCopyright, AP_SERVER_COPYRIGHT \0
VALUE OriginalFilename, BIN_NAME_STR \0
I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to try
to put literal quotes there.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName, http://subversion.apache.org/\0
http://subversion.apache.org/0
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE FileVersion, SVN_VER_NUMBER \0
VALUE InternalName, SVN\0
VALUE LegalCopyright, Copyright (c) The Apache Software
Foundation\0
VALUE OriginalFilename, APR_STRINGIFY(SVN_FILE_NAME) \0
VALUE ProductName, Subversion\0
VALUE ProductVersion, SVN_VERSION \0
#ifdef
Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 7:42 PM, Bert Huijben b...@qqmail.nl wrote:
Hi Jeff,
I can confirm that this fixes the LONG_NAME problems J
Great!
I have one remaining problem, that I hoped would be fixed by the same fix
you applied, but it wasn’t.
If the httpd build directory contains a ‘-‘, such as in my case
‘F:\svn-dev\build\httpd’, then the ICON_FILE argument doesn’t get through
as a valid token.
[[
build\win32\httpd.rc(34): error RC2135: file not found: F:/svn
[F:\svn-dev\build\httpd\httpd.vcxproj]
build\win32\httpd.rc(40): error RC2135: file not found: VERSIONINFO
[F:\svn-dev\build\httpd\httpd.vcxproj]
build\win32\httpd.rc(41): error RC2135: file not found: 4
[F:\svn-dev\build\httpd\httpd.vcxproj]
build\win32\httpd.rc(42): error RC2135: file not found: PRODUCTVERSION
[F:\svn-dev\build\httpd\httpd.vcxproj]
]]
The generated line in httpd.vcxproj is now:
PreprocessorDefinitionsWIN32;_WINDOWS;NDEBUG;APP_FILE;LONG_NAME=Apache
HTTP
Server;BIN_NAME=httpd.exe;ICON_FILE=F:/svn-dev/build/httpd/build/win32/apache.ico;CMAKE_INTDIR=\Release\;%(PreprocessorDefinitions)/PreprocessorDefinitions
I can fix this by updating the relevant lines in build/win32/httpd.rc from
[[
#ifdef ICON_FILE
1 ICON DISCARDABLE ICON_FILE
#endif
]]
to
#ifdef ICON_FILE
1 ICON DISCARDABLE APR_STRINGIFY(ICON_FILE)
#endif
Bert
Thanks!
Trunk: r1543282
2.4.x: r1543283
This should be safe with the old build system too. ICON_FILE was passed in
with the same syntax (quoting) as other values that were already
APR_STRINGIFY-ed in the .rc file.
*From:* Jeff Trawick [mailto:traw...@gmail.com]
*Sent:* maandag 18 november 2013 22:19
*To:* Apache HTTP Server Development List
*Subject:* Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 4:14 PM, Jeff Trawick traw...@gmail.com wrote:
On Mon, Nov 18, 2013 at 4:10 PM, Bert Huijben b...@qqmail.nl wrote:
Hi Jeff,
Thanks for looking into this.
I tried the Visual Studio 9 and Visual Studio 11 generators in both
standard Win32 and x64 forms. Both of these have similar problems even
though the first uses .vcproj files and the late .vcxproj files.
The cmake generated code is accepted by the resource compiler argument
parser but then fails during the resource compile stage.
It appears that the code does work for some cases where the long name only
contains a single word, but it always fails when there are multiple words.
Bert
Cool... In the meantime, I have a fix in trunk (r1543149) and am building
the 2.4.x fix with Visual Studio 2010 currently. (Luckily exiftool makes
it easy to quickly check File Description.)
r1543165 is the 2.4.x fix
*From:* Jeff Trawick [mailto:traw...@gmail.com]
*Sent:* maandag 18 november 2013 19:22
*To:* Apache HTTP Server Development List
*Subject:* Re: Playing with cmake: LONG_NAME= problems
On Mon, Nov 18, 2013 at 12:37 PM, Bert Huijben b...@qqmail.nl wrote:
Hi,
As I already mentioned I'm re-scripting my build of httpd to work using the
new cmake generator.
It looks like I have things working now, with about half as many local
patches as before..., but I think one problem I had to patch around will be
common for everybody using project files for Visual Studio 2005 and later:
I don't doubt it, but just for fun: Exactly which generator/studio version
were you using, in case I have a problem reproducing?
The very ugly escaping of the LONG_NAME= argument.
E.g. CMakeLists.txt contains:
SET_TARGET_PROPERTIES(${mod_name} PROPERTIES COMPILE_FLAGS
-DLONG_NAME=${mod_name} for Apache HTTP Server
-DBIN_NAME=${mod_name}.so ${EXTRA_COMPILE_FLAGS})
The long name value is then later generated in project files, but
differently for the C compiler and the RC (=resource) compiler. This
resource compiler doesn't like the way the value is generated, and just
handles the value literally... And then generates parser errors.
In Subversion where we used this same pattern for years, we avoided all the
'' escaping problems by using the APR_STRINGIFY() macro. That allows
simply
passing the value.
We do that two, though with a little indirection:
#define LONG_NAME_STR APR_STRINGIFY(LONG_NAME)
#define BIN_NAME_STR APR_STRINGIFY(BIN_NAME)
VALUE FileDescription, LONG_NAME_STR \0
VALUE FileVersion, AP_SERVER_BASEREVISION \0
VALUE InternalName, BIN_NAME_STR \0
VALUE LegalCopyright, AP_SERVER_COPYRIGHT \0
VALUE OriginalFilename, BIN_NAME_STR \0
I guess the LONG_NAME definition set in CMakeLists.txt doesn't need to try
to put literal quotes there.
E.g.
BEGIN
BLOCK StringFileInfo
BEGIN
BLOCK 040904B0
BEGIN
VALUE CompanyName,
http://subversion.apache.org/\0http://subversion.apache.org/0
VALUE FileDescription, APR_STRINGIFY(SVN_FILE_DESCRIPTION) \0
VALUE
