You will also find that using git to track your apache config files cleans up those directories, since you won't be needing those old-fashioned. Once you've figured that out, then reset the repo back to its original state, and only enable that one module that needs to remain enabled. If enabling all modules succeeds, then try disabling them again one-by-one and restarting apache in between, until you find which module it is that needs to remain enabled.
That way I can do these sorts of global search-and-replace operations in my apache config working directory, as a troubleshooting step. So, please understand, I am merely suggesting this as a troubleshooting step, not a final solution.Īlso, please note: I use a special git project to track all of my local machine's apache config files. While you could theoretically do that without necessarily breaking anything, it's obviously not a best practice solution. Note: this answer has received some down-votes due to the fact that my initial answer seemed to suggest leaving all the modules enabled, forever. Having a module enabled does not mean it will get used, but having one disabled does mean that it can't get used, and therefore, anything that depends on it will necessarily fail. Since that solved the problem for me, therefore I knew that my problem was not a missing "KeepAlive" directive argument, but rather, my problem was a missing dependency.īecause, remember. If the above solutions don't work, one thing you can try is to enable all your apache modules to make sure that there isn't some module you need that somehow got accidentally disabled.įor example, how I found the cause of my problem was to replace all instances of #LoadModule with LoadModule in all my Apache config files. If, however, the responses without the proxy are consistently something much less than the five minutes see here as the cut-off limit, then there might really be some odd interference between the proxy and app server, but you're not providing anything of value for identifying what it might be. If the same proxy also serves other backends, it would be better to keep the current ProxyTimeout, and configure the timeout in the ProxyPass directive (see mod_proxy documentation). If the five minutes really is within possible response times, you might try tweaking the ProxyTimeout configuration directive.ĭepending on your network set-up, it might well be that there's no reason to even try to use any keepalive system (is there a firewall between the app server and proxy which might be configured to drop sessions that are idle for too long?), but the ProxyTimeout would affect the behaviour of the proxy itself. When you access the Jetty server directly, does this resource really take that long to produce a response? That's a pretty long time to wait for a response. Looking at the log, there's something that times out at 5 minutes (=300 seconds). proxy: Error reading from remote server returned by /, referer: ::: proxy: error reading status line from remote server referer: ::: # Possible values include: debug, info, notice, warn, error, crit,ĬustomLog /var/log/apache2/access.log combined ProxyPass / retry=1 acquire=3000 timeout=600
ServerAdmin ServerAlias mydomain.fi mydomain ProxyRequests On ProxyTimeout 600 # I have tried this, does not help KeepAliveTimeout 600 # I have tried this, does not help KeepAlive 20 # I have tried this, does not help #SetEnv proxy-initial-not-pooled 1 # I have tried this, does not help #SetEnv proxy-nokeepalive 1 # I have tried this, does not help #SetEnv force-proxy-request-1.0 1 # I have tried this, does not help Here is my current configuration, any suggestions? #keepalive Off # I have tried this, does not help I have already tried some "tricks" related to KeepAlive settings, without luck. So problem is likely to sit somewhere between Apache and Jetty where I am using mod_proxy. If I issue request instead directly to Jetty at port :8080 the request is processed OK. Problems occur when request processing takes long (few minutes?).
My dilemma: Everything works fine normally (fast requests, few seconds or few tens of seconds long requests are processed ok). The proxy server could not handle the request GET /. Apache is receiving requests at port :80 and proxying them to Jetty at port :8080 The proxy server received an invalid response from an upstream server
0 kommentar(er)
