Yes! Glassfish is listening on 127.0.0.1 and it works most of the time. I guess it may be related to timeout. When Glassfish is processing a "heavy" request it may take quite some time for it to respond back to apache. My theory now is that the default timeout of 300 isn't sufficient enough. I'm going to define ProxyTimeout (currently not used and therefore defaults to the value of the Timeout directive which is 300) and set it to at least 600. -----Original Message----- From: Alex Samad - Yieldbroker [mailto:Alex.Samad@xxxxxxxxxxxxxxx] Sent: 15. november 2011 23:19 To: users@xxxxxxxxxxxxxxxx Subject: RE: Apache, mod_proxy and Glassfish Hi Is glashfish listening on 127.0.0.1 ? Alex -----Original Message----- From: Øyvind Lode - Forums [mailto:forums@xxxxxxx] Sent: Wednesday, 16 November 2011 3:24 AM To: Apache Users List (users@xxxxxxxxxxxxxxxx) Subject: Apache, mod_proxy and Glassfish Hi: I'm struggling with some Apache error messages. I'm not 100% sure it's Apache which is faulty but it looks like it. I'm using mod_proxy / mod_proxy_http to forward requests to Glassfish. In apache's ssl error log I can see the following: [Tue Nov 15 04:38:02 2011] [error] (103)Software caused connection abort: proxy: pass request body failed to 127.0.0.1:8181 (localhost) [Tue Nov 15 04:38:02 2011] [error] proxy: pass request body failed to 127.0.0.1:8181 (localhost) from x.x.x.x () I have removed the client ip from the error message above. I'm using ip-based virtual hosts in apache and here's the config: <VirtualHost myip:443> ... SSLEngine on # certificates ... # SSL Engine Options: # Set various options for the SSL engine. # o FakeBasicAuth: # Translate the client X.509 into a Basic Authorisation. This means that # the standard Auth/DBMAuth methods can be used for access control. The # user name is the `one line' version of the client's X.509 certificate. # Note that no password is obtained from the user. Every entry in the user # file needs this password: `xxj31ZMTZzkVA'. # o ExportCertData: # This exports two additional environment variables: SSL_CLIENT_CERT and # SSL_SERVER_CERT. These contain the PEM-encoded certificates of the # server (always existing) and the client (only existing when client # authentication is used). This can be used to import the certificates # into CGI scripts. # o StdEnvVars: # This exports the standard SSL/TLS related `SSL_*' environment variables. # Per default this exportation is switched off for performance reasons, # because the extraction step is an expensive operation and is usually # useless for serving static content. So one usually enables the # exportation for CGI and SSI requests only. # o StrictRequire: # This denies access when "SSLRequireSSL" or "SSLRequire" applied even # under a "Satisfy any" situation, i.e. when it applies access is denied # and no other module can change it. # o OptRenegotiate: # This enables optimized SSL connection renegotiation handling when SSL # directives are used in per-directory context. #SSLOptions +FakeBasicAuth +ExportCertData +StrictRequire <FilesMatch "\.(cgi|shtml|phtml|php)$"> SSLOptions +StdEnvVars </FilesMatch> <Directory /usr/lib/cgi-bin> SSLOptions +StdEnvVars </Directory> # SSL Protocol Adjustments: # The safe and default but still SSL/TLS standard compliant shutdown # approach is that mod_ssl sends the close notify alert but doesn't wait for # the close notify alert from client. When you need a different shutdown # approach you can use one of the following variables: # o ssl-unclean-shutdown: # This forces an unclean shutdown when the connection is closed, i.e. no # SSL close notify alert is send or allowed to received. This violates # the SSL/TLS standard but is needed for some brain-dead browsers. Use # this when you receive I/O errors because of the standard approach where # mod_ssl sends the close notify alert. # o ssl-accurate-shutdown: # This forces an accurate shutdown when the connection is closed, i.e. a # SSL close notify alert is send and mod_ssl waits for the close notify # alert of the client. This is 100% SSL/TLS standard compliant, but in # practice often causes hanging connections with brain-dead browsers. Use # this only for browsers where you know that their SSL implementation # works correctly. # Notice: Most problems of broken clients are also related to the HTTP # keep-alive facility, so you usually additionally want to disable # keep-alive for those clients, too. Use variable "nokeepalive" for this. # Similarly, one has to force some clients to use HTTP/1.0 to workaround # their broken HTTP/1.1 implementation. Use variables "downgrade-1.0" and # "force-response-1.0" for this. BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 # MSIE 7 and newer should be able to use keepalive BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown # forward requests to Glassfish ProxyRequests Off ProxyPreserveHost On SSLProxyEngine on <Proxy *> Order deny,allow Allow from all </Proxy> ProxyPass / https://localhost:8181/ ProxyPassReverse / https://localhost:8181/ <Location /> Order allow,deny Allow from all </Location> </VirtualHost> OS = Ubuntu Linux 10.04 LTS Apache version = 2.2.14 I tried Google to search for the proxy error but couldn't find anything particularly helpful. Please help! --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|