Monday, September 5, 2011

Name resolution testing with your APR app

Consider a typical network client or server which takes a server name as parameter, converts it to a list of socket addresses using apr_sockaddr_info_get(), and then proceeds by either listening on all of the returned addresses or attempting to connect to them in succession until arriving at one which works.

While developing this program logic to process the list of returned addresses it may be useful to carefully control the apr_sockaddr_info_get() results without having to muck with host files, resolver configuration files, or (shudder) the DNS server, especially if the test scenarios need to be replicated on multiple platforms.

I developed a small patch to APR to control resolution with an envvar. (The patch applies to r1165471 or so of the 1.4.x branch, and presumably to the recent 1.4.5 release.) With a build of APR which includes the patch, the environment variable APR_S_I_G can be set to a list of semicolon-delimited host definitions, each of which is a list of comma-delimited IPv4 or IPv6 numeric address strings, with square brackets around the IPv6 strings.

$ APR_S_I_G="myhost1=[::1],;myhost2=[fe80::deadbeef]," ./myproggie

A declaration of mixed IPv4 and IPv6 addresses will work only if the application passes APR_UNSPEC to apr_sockaddr_info_get(). If it passes a specific address family, declare a list of one or more addresses in that single address family.

Resolution proceeds normally if the hostname being resolved is not defined in the envvar.

Monday, August 15, 2011

google("unable to infer tagged configuration")

This is one of those fun errors for which you can find lots of search hits that won't bring any happiness. You've seen the error before but the reason you saw it three years ago while building the same open source package may not be the reason you're seeing it today.

Anyhow, here's my current blunder: I'm compiling an httpd tarball using icc on Linux, I forgot to add --with-included-apr, the system APR is picked up by default, it wasn't built with the same CC, and libtool is confused about the CC setting. As I intended to use the httpd-bundled apr, my fix is to add the extra configure option --with-included-apr.

Wednesday, February 2, 2011

google("pthread_create ENOMEM Linux")

Here's one cause which doesn't show up in most explanations on the 'net: The configurable kernel limit kernel.pid_max has been reached. (The default is 32K, at least on my CentOS 5 box.)

With threaded Apache httpd on Linux/Unix, the pthread_create() failure can be logged as

Cannot allocate memory: apr_thread_create: unable to create worker thread

The most common cause of this failure is still the thread stack size, but if you're creating thousands of threads and shrinking the stack size doesn't help, see if increasing kernel.pid_max allows more threads to be created.

Hats off to a colleague at &bigco; for finding this solution.