I discovered that when Apache sits in front of Hudson as a reverse proxy, it...
I discovered that when Apache sits in front of Hudson as a reverse proxy, it blocks the traffic in such a way that breaks tunneling of the remoting. The issue is that the CLI initiates the upload side of the connection and sends some small chunk, yet Apache never forwads that to Hudson, presumably because it's trying to buffer more contents from CLI, which never arrives. A similar problem seems to exist for the download side, although various reports (like http://mail-archives.apache.org/mod_mbox/httpd-users/200509.mbox/%3C20050927152742.GA8726@redhat.com%3E) suggests that this is fixed in a relatively recent version of Apache. Other pages, like http://httpd.apache.org/docs/2.2/mod/mod_proxy.html , seems to suggest that Apache can be configured not to do this buffering, but my attempt to configure them failed, both on Ubuntu and OpenSolaris. It could be my mistake, but the lesson for me is that even if Apache can be configured not to interfere, it's still rather error prone. On top of that, it's not hard to imagine that other forward/reverse proxy have similar problems --- IIRC, Dean Yu reported a similar problem. So I decided to let CLI talk to Hudson via a conventional TCP/IP connection, if possible. An extra bonus is that this is more resource efficient on the server side (which was tying 2 request handling for pushing and pulling before this change.) The downside of this change is that if the client is behind the proxy, or if the server is behind a reverse proxy, this needs an extra set up. I thought this is a lesser evil, as Hudson tends to run inside a corporate network, and this issue is already better understood since JNLP slaves have the same issue. git-svn-id: https://hudson.dev.java.net/svn/hudson/trunk/hudson/main@19378 71c3de6d-444a-0410-be80-ed276b4c234a
Showing
想要评论请 注册 或 登录