For the past few months, we have been working with ITOPS people to get our Sun
ITOPS proxies moved to 4.0. Starting with 4.0, and then upgrading through 4.0.1,
4.0.2, 4.0.3, and finally onto the latest internal 4.0.4 build, it's been a good
learning experience on how to get proxy 4.0 working effectively in a real time,
high load, configuration. Im noting down some of the points we picked up along the
way, and if you are a user of Sun Java System Web Proxy Server 4.0, you might find
these helpful.
[1]
First of all, if you have moved from proxy 3.6 to 4.0, please note that 4.0 is
much stricter than proxy 3.6. For example, with proxy 3.6, you can get away with
the following request:
GET http://www.google.com/ HHHHHTTTP/1.one
But not with 4.0. You get a "Your browser sent a query this server could not understand." error. And there are clients who generate such wierd requests - so
do not be surprised if such wierdos stop working once you move to 4.0.
[2]
Along a similar line as above, there are clients who generate more saner looking - yet technically wrong - requests. For example, some clients specify a HTTP/1.1
protocol in a CONNECT request, but forget to mention a "host:" header. Proxy 3.6
accepts such requests, but again, not Proxy 4.0. For example, with 4.0:
CONNECT www.google.com:80 HTTP/1.1
HTTP/1.1 400 Bad request
Server: Sun-Java-System-Web-Proxy-Server/4.0
...
...
[3]
Proxy 4.0 is of a multithreaded architecture, while proxy 3.6 takes a multiprocess
line. Proxy 4.0 does provide support for having multiple processes - through the
"MaxProcs" magnus conf variable - but please note that it is not recommended.
Stick to a single process configuration, but feel free to bump up RqThrottle -
another magnus.conf variable, which specifies the number of worker threads - as
required.
[4]
Proxy 4.0, by default, allows CONNECT requests to ports 443 and 563 only. If you
receive 403 for CONNECT requests with a similar line appearing in error log:
[28/Jul/2006:12:42:27] security (15652): for host 127.0.0.1 trying to CONNECT
connect://xxx.xxx.xxx:5555, deny-service reports: denying service of
connect://xxx.xxx.xxx:5555
Then you should consider opening up CONNECT to the required ports, as needed, by
modifying obj.conf.
[5]
Certian tools, like subversion, depends on using the REPORT method. Proxy
4.0 does not support this by default, but you can configure obj.conf to get
such scenarios to work:
...
Init fn="register-http-method" methods="REPORT"
...
[6]
If you are on a pre-4.0.3 version, and is facing severe high cpu consumption
problems, please upgrade to 4.0.3 - which contains fixes for all known high cpu
utilization issues.
[7]
This is about Client IP forwarding. Proxy 3.6 does not forward the client
ip by default; pre-4.0.3 versions do. 4.0.3 onwards, the default obj.conf setting
blocks forwarding of client ip.
[8]
Regarding cache size control - before 4.0.3, Garbage Collection did not kick in
correctly, and this allowed the cache size to grow beyond specified limits. The
majority of such problems are addressed in 4.0.3.
[9]
Along a similar line, 4.0.3 has certian hiccups managing caches of size greater
than 2GB - this issue has been fixed completely in 4.0.4 (which will be released
within a couple of months).
[10]
Memory leak/growth issues - Majority of all such problems have been addressed in
4.0.3. But if you notice your 4.0.3 memory size showing a gradual bloat, this
issue has been addressed in 4.0.4.
[11]
If you are on 4.0.3 or earlier, and notice the following error happening too
often in your error logs:
......service-common reports: timed out waiting for request body from client
It indicates a bunch of eccentric clients in action. specifically, those clients
specify a Content-length header along with a CONNECT request. The proxy
does not handle this situation altogether well, but this issue is resolved in
4.0.4, too.
[12]
Proxy 3.6 has a ProcessLife parameter - which specifies the number of
requests that a worker process will handle, after which it will exit. This
paramter/"feature" does NOT exist on Proxy 4.0.
Ok, so that's it for now. I will update this regularly as we come up with more
similar data.
Posted by Manoj Kumar Malhotra on korrik 30, 2006 at 09:30 MD PDT #
Regarding the point [11] (......service-common reports: timed out waiting for request body from client)
I am using version 4.0.4 and I see a lot of errors like this (~80000 entries per day).
Could you specify more about this?
Another question .. I'm using a SunFire T2000, what is the right value for AcceptorThreads ? (MaxProcs=1, RqThrottle=2048)
Thanks in advance !!
Posted by Francisco Castrillo on qershor 05, 2007 at 01:50 MD PDT #