Original author: pubcrawl...@gmail.com (September 03, 2009 01:58:25)
This is a feature request, information clarification and new concept for
Cherokee Reverse Proxy:
What steps will reproduce the problem?
Reverse proxy with single backend application server.
Backend application server (Coldfusion) generates pages with errors inline
HTML and it generates 500 HTTP code for the page - when application server
fails sometimes.
Cherokee detects the 500 HTTP code I suspect and labels the backend as
being down/failed.
What is the expected output? What do you see instead?
At current, Cherokee is unclear as to how long it labels a backend failed.
If you had multiple backends ideally you would be able to see in Cherokee
Admin what backends are labeled as failed. The recheck/retry time of
backends should be user configurable. Logging of the time/date of backend
failures should be a reporting piece in Cherokee - at least a logging
point. Configurable weighting of traffic rotation to multiple servers in
the backend INFORMATION SOURCES should be a long term feature also - as
resources are not always equal in responsiveness/hardware specs.
Ideally we need to detect information sources like these when they are down
and pipe a user request to another source in the pool gracefully - so user
not dumped into blank browser page or displayed an error - Cherokee should
never be reporting downed backend servers to the user unless last resort -
no other backends to service the request.
I have some other ideas - which in general move Reverse Proxy towards being
a Reverse Proxy load balancer per se.
What version of the product are you using? On what operating system?
Ubuntu 9.04 / Cherokee latest trunk
Further info:
I've disabled 500 codes in Coldfusion - actually a feature whereby all
pages return 200 OK code even if errors or other issues. This fixed the
aggressive detection by Cherokee of down backend - HOWEVER - 12 hours
later, we caught Cherokee throwing error about failed backend in response
to all page requests - EVEN THOUGH THE BACKEND WORKED FINE. Unsure what
Cherokee was thinking or what triggered it to throw such error. Further
debugging necessary to isolate this new similar fail instance.
Original author: pubcrawl...@gmail.com (September 03, 2009 01:58:25)
This is a feature request, information clarification and new concept for Cherokee Reverse Proxy:
What steps will reproduce the problem? Reverse proxy with single backend application server. Backend application server (Coldfusion) generates pages with errors inline HTML and it generates 500 HTTP code for the page - when application server fails sometimes.
Cherokee detects the 500 HTTP code I suspect and labels the backend as being down/failed.
What is the expected output? What do you see instead?
At current, Cherokee is unclear as to how long it labels a backend failed. If you had multiple backends ideally you would be able to see in Cherokee Admin what backends are labeled as failed. The recheck/retry time of backends should be user configurable. Logging of the time/date of backend failures should be a reporting piece in Cherokee - at least a logging point. Configurable weighting of traffic rotation to multiple servers in the backend INFORMATION SOURCES should be a long term feature also - as resources are not always equal in responsiveness/hardware specs.
Ideally we need to detect information sources like these when they are down and pipe a user request to another source in the pool gracefully - so user not dumped into blank browser page or displayed an error - Cherokee should never be reporting downed backend servers to the user unless last resort - no other backends to service the request.
I have some other ideas - which in general move Reverse Proxy towards being a Reverse Proxy load balancer per se.
What version of the product are you using? On what operating system? Ubuntu 9.04 / Cherokee latest trunk
Further info:
I've disabled 500 codes in Coldfusion - actually a feature whereby all pages return 200 OK code even if errors or other issues. This fixed the aggressive detection by Cherokee of down backend - HOWEVER - 12 hours later, we caught Cherokee throwing error about failed backend in response to all page requests - EVEN THOUGH THE BACKEND WORKED FINE. Unsure what Cherokee was thinking or what triggered it to throw such error. Further debugging necessary to isolate this new similar fail instance.
Original issue: http://code.google.com/p/cherokee/issues/detail?id=557