Forum OpenACS Development: Calls to server itself are ok on command line, but hang in /ds/shell

I have succeded on other instances with simpler configuration. This instance is particular because the server hosts different websites on different hostnames. The request is forwarded to the actual nsd instance by a nginx proxy.

I have used the actual address and port to try calling the server (e.g. 192.168.10.10, the address in the internal subnet). I am puzzled because curl is working from bash using the very same user as nsd.

Specifying -ignorestderr doesn't change the situation for me.

Tcl version is 8.5. I am using ns_proxy on Naviserver 4.99.5

Thanks

This must be something specific to nsd/nginx in that particular environment, because curl on the very same server works as expected, using exactly the same command in bash as in /ds/shell, except for the "exec" part of course.

There is a case where nsd will not actually spawn a new thread for a new connection even if there is no thread available, and this can lead to a blocking http call to the server itself hanging everything until it times out.

In naviserver, you can fix this by setting


ns_section "ns/server/${servername}"
ns_param lowwatermark 0 ;# eager thread creation at low concurrency


I don't recall the corresponding setting for AOLserver without checking, but the thread creation behavior is a bit different so it might not have the same issue.

In your test, you have one connection currently running (the ds request), and a second waiting (the loopback request), so only 2 connections is not busy enough to warrant spawning a new thread, and the server doesn't (AFAIR) have any logic to specify that a thread should be created if connections have simply been queued for a certain amount of time without progressing. (The benefit of such logic would be dubious IMO; connections are generally expected to complete quickly unless there is a specific reason they should be acting differently).

So changing the lowwatermark setting to 0 will make the server always create a new thread on a new request if there's not already a thread for it, so the loopback request will be handled.

Alternately, you could set minthreads to something more than 1, or while waiting for the loopback request to time out hit the server 10 or more times using curl to queue up connections and get it to create a new thread, and then things will progress (until a restart, at least).

Thanks Jeff and Gustaf!