Hi guys.

 

When a backend starts sending http error 500 (internal server error) how
does pound react?

Imagine a simple scenario with a LB balancing to two servers... one
starts sending http error code 500 or similar because the webserver
crashed... does it switch to the other backend? From what I have seen in
the code it doesn't, correct? It only allows showing some default web
page... is it possible to change this behavior since what I think would
be more interesting is having the LB switch to a working backend when
this happens?

 

A backend is considered dead when? Only when Pound cannot connect to it?

 

Regards,

Sergio Freire

 

On Wed, 2006-03-08 at 15:56 +0000, Sergio Freire wrote:
> Hi guys.
> 
>  
> 
> When a backend starts sending http error 500 (internal server error) how
> does pound react?

The reply is considered a normal one and Pound just passes it to the
client.

> Imagine a simple scenario with a LB balancing to two servers... one
> starts sending http error code 500 or similar because the webserver
> crashed... does it switch to the other backend? From what I have seen in
> the code it doesn't, correct? It only allows showing some default web
> page... is it possible to change this behavior since what I think would
> be more interesting is having the LB switch to a working backend when
> this happens?

How exactly can a web server return a 500 reply after it crashed? At
least in my experience crashed web servers very seldom return anything
at all.

> A backend is considered dead when? Only when Pound cannot connect to it?

Normally yes. The exception is when you use the HAport feature, in which
case that gets checked periodically as well.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

No Robert, its not a normal reply. HTTP error 500 means the web server
faces an internal server error. This is "normal" in web servers like
tomcat and other, when there are things like a problem with a web
application deployment or simply an out of memory. In this case if we
have any backend OK we should balance all traffic to it.

What do you all guys think? 

If we are just checking normal socket connection we aren't checking the
HTTP service that we should since Pound is an HTTP load balancer..

Regards,
Sergio Freire


-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Wednesday, March 08, 2006 4:22 PM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
dead when?

On Wed, 2006-03-08 at 15:56 +0000, Sergio Freire wrote:
> Hi guys.
> 
>  
> 
> When a backend starts sending http error 500 (internal server error)
how
> does pound react?

The reply is considered a normal one and Pound just passes it to the
client.

> Imagine a simple scenario with a LB balancing to two servers... one
> starts sending http error code 500 or similar because the webserver
> crashed... does it switch to the other backend? From what I have seen
in
> the code it doesn't, correct? It only allows showing some default web
> page... is it possible to change this behavior since what I think
would
> be more interesting is having the LB switch to a working backend when
> this happens?

How exactly can a web server return a 500 reply after it crashed? At
least in my experience crashed web servers very seldom return anything
at all.

> A backend is considered dead when? Only when Pound cannot connect to
it?

Normally yes. The exception is when you use the HAport feature, in which
case that gets checked periodically as well.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141834941000

On Wed, 2006-03-08 at 16:31 +0000, Sergio Freire wrote:
> No Robert, its not a normal reply. HTTP error 500 means the web server
> faces an internal server error. This is "normal" in web servers like
> tomcat and other, when there are things like a problem with a web
> application deployment or simply an out of memory. In this case if we
> have any backend OK we should balance all traffic to it.

So it is not the web server that has crashed, but rather some
application behind it (Java server framework, DBMS, etc). Should Pound
even know about those?

> What do you all guys think? 
> 
> If we are just checking normal socket connection we aren't checking the
> HTTP service that we should since Pound is an HTTP load balancer..

Precisely - and the HTTP is working. The question I would like you to
consider: is it at all reasonable for Pound to check the contents of
what is returned (application check), rather than the absolute fact that
something is returned (HTTP)?

The second (and probably harder) question is how should such a back-end
be resurrected once it was declared dead? How is Pound to check that it
is operational again?

And the third, just to make things interesting: how do we deal with
"mixed" servers (a web server that serves both static content and some
dynamic, DB-dependent stuff)? Should we declare it dead once we received
any 500, or block only the parts that are dynamic? How is Pound to know
which is which?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Robert is right that the HAPort feature is the way to handle these sorts 
of policy issues.

If you have a policy that certain kinds of exceptions mean that your 
server is down until certain other kinds of things happen (such as 
manual intervention, memory becomes available or the db comes back) then 
you should implement a watchdog that knows about your policy and either 
refuses a connection from pound (to indicate the server is down) or 
accepts the connection from pound (to indicate the server is up).  Pound 
really shouldn't have too much policy builtin.

When we were still using pound for our systems, I had just such a policy 
script (although our policies differed from what you need).  On startup, 
it would try to make access a page on the tomcat being monitored.  This 
access would succeed after the web applications running under tomcat had 
fully started.  The watchdog script would then access a standard list of 
30 pages whose URL's were stored in a file.  This would warm up the 
application's caches sufficiently to handle real loads.  After the 
warmup completed, the watchdog would start accepting connections from 
pound.  Every 15-30 seconds, the watchdog would check on the tomcat to 
make sure that it was still there.  During shutdown, the watchdog was 
taken down first and the shutdown script would then wait until pound had 
time to go through an interrogation fo the server status.  As the actual 
tomcat came down, it would finish all pending transactions before exiting.

Now that we are using an f5 to do the load balancing, we still use the 
policy script, but we also have the option of doing a soft start and 
only move traffic onto the new server a bit at a time.  In high volume 
situations, this can decrease the amount of oscillation in the load when 
a new server comes on.

Robert Segall wrote:

>On Wed, 2006-03-08 at 16:31 +0000, Sergio Freire wrote:
>  
>
>>No Robert, its not a normal reply. HTTP error 500 means the web server
>>faces an internal server error. This is "normal" in web servers like
>>tomcat and other, when there are things like a problem with a web
>>application deployment or simply an out of memory. In this case if we
>>have any backend OK we should balance all traffic to it.
>>    
>>
>Mime-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain
>
>So it is not the web server that has crashed, but rather some
>application behind it (Java server framework, DBMS, etc). Should Pound
>even know about those?
>
>  
>
>>What do you all guys think? 
>>
>>If we are just checking normal socket connection we aren't checking the
>>HTTP service that we should since Pound is an HTTP load balancer..
>>    
>>
>
>Precisely - and the HTTP is working. The question I would like you to
>consider: is it at all reasonable for Pound to check the contents of
>what is returned (application check), rather than the absolute fact that
>something is returned (HTTP)?
>
>The second (and probably harder) question is how should such a back-end
>be resurrected once it was declared dead? How is Pound to check that it
>is operational again?
>
>And the third, just to make things interesting: how do we deal with
>"mixed" servers (a web server that serves both static content and some
>dynamic, DB-dependent stuff)? Should we declare it dead once we received
>any 500, or block only the parts that are dynamic? How is Pound to know
>which is which?
>  
>

-- 
Ted Dunning
Chief Scientist
Veoh Networks

We also have a watchdog like that one.
I think this depends on the scenario, a more complete email is following
shortly.


-----Original Message-----
From: Ted Dunning [mailto:tdunning(at)veoh.com] 
Sent: Wednesday, March 08, 2006 6:07 PM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
dead when?


Robert is right that the HAPort feature is the way to handle these sorts

of policy issues.

If you have a policy that certain kinds of exceptions mean that your 
server is down until certain other kinds of things happen (such as 
manual intervention, memory becomes available or the db comes back) then

you should implement a watchdog that knows about your policy and either 
refuses a connection from pound (to indicate the server is down) or 
accepts the connection from pound (to indicate the server is up).  Pound

really shouldn't have too much policy builtin.

When we were still using pound for our systems, I had just such a policy

script (although our policies differed from what you need).  On startup,

it would try to make access a page on the tomcat being monitored.  This 
access would succeed after the web applications running under tomcat had

fully started.  The watchdog script would then access a standard list of

30 pages whose URL's were stored in a file.  This would warm up the 
application's caches sufficiently to handle real loads.  After the 
warmup completed, the watchdog would start accepting connections from 
pound.  Every 15-30 seconds, the watchdog would check on the tomcat to 
make sure that it was still there.  During shutdown, the watchdog was 
taken down first and the shutdown script would then wait until pound had

time to go through an interrogation fo the server status.  As the actual

tomcat came down, it would finish all pending transactions before
exiting.

Now that we are using an f5 to do the load balancing, we still use the 
policy script, but we also have the option of doing a soft start and 
only move traffic onto the new server a bit at a time.  In high volume 
situations, this can decrease the amount of oscillation in the load when

a new server comes on.

Robert Segall wrote:

>On Wed, 2006-03-08 at 16:31 +0000, Sergio Freire wrote:
>  
>
>>No Robert, its not a normal reply. HTTP error 500 means the web server
>>faces an internal server error. This is "normal" in web servers like
>>tomcat and other, when there are things like a problem with a web
>>application deployment or simply an out of memory. In this case if we
>>have any backend OK we should balance all traffic to it.
>>    
>>
>Mime-Version: 1.0
>Content-Transfer-Encoding: 7bit
>Content-Type: text/plain
>
>So it is not the web server that has crashed, but rather some
>application behind it (Java server framework, DBMS, etc). Should Pound
>even know about those?
>
>  
>
>>What do you all guys think? 
>>
>>If we are just checking normal socket connection we aren't checking
the
>>HTTP service that we should since Pound is an HTTP load balancer..
>>    
>>
>
>Precisely - and the HTTP is working. The question I would like you to
>consider: is it at all reasonable for Pound to check the contents of
>what is returned (application check), rather than the absolute fact
that
>something is returned (HTTP)?
>
>The second (and probably harder) question is how should such a back-end
>be resurrected once it was declared dead? How is Pound to check that it
>is operational again?
>
>And the third, just to make things interesting: how do we deal with
>"mixed" servers (a web server that serves both static content and some
>dynamic, DB-dependent stuff)? Should we declare it dead once we
received
>any 500, or block only the parts that are dynamic? How is Pound to know
>which is which?
>  
>

-- 
Ted Dunning
Chief Scientist
Veoh Networks



-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141841191000

This is getting interesting :)

1. Well, in fact LBs balance things not just based on the protocol but
on the service supported by it. We should look at commercial hardware
based solutions. Alteon for example, checks HTTP backend by doing an
HTTP request which must return an http 200 error code. Pound for example
doesn't do that, it only check socket connection where it should check
at protocol level.
Im looking at more info from Cisco but this will take a while, when I
have more info Ill post it.


2. The protocol stack itself is working, I know, but that doesn't matter
much to us, does it? What we are always concerned is about the service
and that is the one that we always want to be OK to the end user.

Look at:
http://www.w3.org/Protocols/HTTP/HTRESP.html

In this link, you can see that 5xx http error codes refer to internal
server error "for the cases in which the server is aware that the server
has erred".

Quoting:

500 - The server encountered an unexpected condition which prevented it
from fulfilling the request.
501 - The server does not support the facility required.
502 - The server cannot process the request due to a high load (whether
HTTP servicing or other requests). The implication is that this is a
temporary condition which maybe alleviated at other times.
503 - This is equivalent to Internal Error 500, but in the case of a
server which is in turn accessing some other service, this indicates
that the respose from the other service did not return within a time
that the gateway was prepared to wait. As from the point of view of the
client and the HTTP transaction the other service is hidden within the
server, this maybe treated identically to Internal error 500, but has
more diagnostic value.


As you can all see, these errors tell the client that the server has
some kind of internal error due to several factors. In any case, doing
another request will most probably result in another error.
So, when can we consider the backend to back alive again?
My answer:
	- if the client receives these kind of http codes: 2xx
(success), 3xx (redirection) and 4xx (client request error). Explaining
in further detail: 2xx are OK results, 3xx are normal redirect actions
(normally used to avoid problems among lots of other things) and 4xx are
errors that should be passed to the client which invoked the URL, since
they mean client request erros so the client itself should be aware of
those



3. Well, Pound should consider dead the backend when it receives the 5xx
http error codes. But lets go further on this. If we want to distinguish
a server where static and dynamic content is available, we should
consider adding two different entries in pound.cfg. Thus, the only
affected part will be the one where the errors are occurring.
This might not be as trivial as it might sound.
You can have another approach which is the one I first mentioned -
consider it dead when 5xx http codes happen.

So, in my point of view, there are different approaches for this problem
you refer:
	- configure two different entries in pound.cfg, if we can
distinguish the URL somehow
	- configure one entry and assume that the server is "dead" if it
just starts returning 500 error codes
	- keep the actual behavior, which doesn't look at the HTTP
result code
	- possibly other

So what we should do? Well, I don't know others opinion but I think this
behavior on 5xx codes should be configurable. 
There might be scenarios where you want to pass the "internal server
error" to the end user while there are other where you don't.

Regards,
Sergio Freire












-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Wednesday, March 08, 2006 5:04 PM
To: pound(at)apsis.ch
Subject: RE: [Pound Mailing List] Pound doubt - backend is considered
dead when?

On Wed, 2006-03-08 at 16:31 +0000, Sergio Freire wrote:
> No Robert, its not a normal reply. HTTP error 500 means the web server
> faces an internal server error. This is "normal" in web servers like
> tomcat and other, when there are things like a problem with a web
> application deployment or simply an out of memory. In this case if we
> have any backend OK we should balance all traffic to it.

So it is not the web server that has crashed, but rather some
application behind it (Java server framework, DBMS, etc). Should Pound
even know about those?

> What do you all guys think? 
> 
> If we are just checking normal socket connection we aren't checking
the
> HTTP service that we should since Pound is an HTTP load balancer..

Precisely - and the HTTP is working. The question I would like you to
consider: is it at all reasonable for Pound to check the contents of
what is returned (application check), rather than the absolute fact that
something is returned (HTTP)?

The second (and probably harder) question is how should such a back-end
be resurrected once it was declared dead? How is Pound to check that it
is operational again?

And the third, just to make things interesting: how do we deal with
"mixed" servers (a web server that serves both static content and some
dynamic, DB-dependent stuff)? Should we declare it dead once we received
any 500, or block only the parts that are dynamic? How is Pound to know
which is which?
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141837468000

No, a 5xx codes can not be treated as the server's death.

Just a example:
Suppose you are using the traditional *.cgi way. Even a file permission
error will cause 500 error. But it just means the file/cgi can not be
used, not the server. The 5xx errors are content relevant.

If some system problems such as lack of memory cause 5xx errors, you'd
better use some other system health watcher, instead of pound.

On Wed, 8 Mar 2006 18:36:59 -0000
"Sergio Freire" <sergio-s-freire(at)ptinovacao.pt> wrote:

> This is getting interesting :)
> 
> So what we should do? Well, I don't know others opinion but I think this
> behavior on 5xx codes should be configurable. 
> There might be scenarios where you want to pass the "internal server
> error" to the end user while there are other where you don't.
> 
> Regards,
> Sergio Freire
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/1141843019000
> 

On the subject of 500 HTTP codes I'd just like to throw in my 10c.

The web applications I am familiar with generate 500 errors on a per 
page URL. Some URLs invoke a code route which has a typo in it and so 
Python or Ruby or Java or whatever interpreter/compiler powers your web 
site cannot serve the page and returns 500. This doesn't mean that other 
URLs cannot be served however so the server is not dead, just that 
particular request could not be served.

If Pound declares the server dead based on 500 codes from particular 
URLs while the rest of the site is functional that wouldn't be very 
helpful.

Ultimately what to do with an application level failure can be different 
for each application. Pound has no knowledge of what failed. It *does* 
know that the webserver itself is still okay since it managed to return 
a HTTP code.

Ximon

You're in part right. In the scenario you mention I agree with you.
I think this depends on what you are using. For CGI based web servers
that is for sure the truth but not for web application servers.

-----Original Message-----
From: Hu Hailin [mailto:hu.hailin(at)adways.net] 
Sent: Thursday, March 09, 2006 4:06 AM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
dead when?

No, a 5xx codes can not be treated as the server's death.

Just a example:
Suppose you are using the traditional *.cgi way. Even a file permission
error will cause 500 error. But it just means the file/cgi can not be
used, not the server. The 5xx errors are content relevant.

If some system problems such as lack of memory cause 5xx errors, you'd
better use some other system health watcher, instead of pound.

On Wed, 8 Mar 2006 18:36:59 -0000
"Sergio Freire" <sergio-s-freire(at)ptinovacao.pt> wrote:

> This is getting interesting :)
> 
> So what we should do? Well, I don't know others opinion but I think
this
> behavior on 5xx codes should be configurable. 
> There might be scenarios where you want to pass the "internal server
> error" to the end user while there are other where you don't.
> 
> Regards,
> Sergio Freire
> -- 
> To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141843019000
> 



-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141877168000

Once again, it depends on the scenario you're using.
If you have a web application server like jboss+tomcat and you use it,
as I do, to serve mobile clients you don't want 5xx errors to get into
to end user. More, normally a 5xx error it's not just a problem with one
URL, in application servers if an application is with some problem all
URLs that depend on it will be affected. This leads to great service
degradation, since one app can be an entire portal or similar. In those
cases would you balance traffic to those backends? Well, I don't think
so.
To be clear, I think it's dumb to consider 5xx HTTP errors as the entire
server is dead, ok?
What I am trying to say is that this should be configurable since, in my
point of view, there might be cases where if you're getting 5xx error
codes then it's because the server it's of no use to you. Probably the
web server is OK but not the applications that you depend on.
Cisco load balancers, although I cannot guarantee 100%, do a check on a
URL you specify and they expect to receive a HTTP 200 code. So what I am
trying to say is that my opinion seems to be also the opinions of other.
But we are here to discuss :)


About this last phrase, I almost sure it's not true from discussions
here and from source code analyzing.

"Ultimately what to do with an application level failure can be
different 
for each application. Pound has no knowledge of what failed. It *does* 
know that the web server itself is still okay since it managed to return

a HTTP code."


Pound doesn't look at the HTTP protocol level to consider a backend
dead, and it should. Pound only looks if it can do a socket connection
to a backend and if not then it considers it dead.

Regards,
Sergio Freire


-----Original Message-----
From: Ximon Eighteen [mailto:ximon.eighteen(at)int.greenpeace.org] 
Sent: Thursday, March 09, 2006 8:12 AM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
dead when?

On the subject of 500 HTTP codes I'd just like to throw in my 10c.

The web applications I am familiar with generate 500 errors on a per 
page URL. Some URLs invoke a code route which has a typo in it and so 
Python or Ruby or Java or whatever interpreter/compiler powers your web 
site cannot serve the page and returns 500. This doesn't mean that other

URLs cannot be served however so the server is not dead, just that 
particular request could not be served.

If Pound declares the server dead based on 500 codes from particular 
URLs while the rest of the site is functional that wouldn't be very 
helpful.

Ultimately what to do with an application level failure can be different

for each application. Pound has no knowledge of what failed. It *does* 
know that the webserver itself is still okay since it managed to return 
a HTTP code.

Ximon


-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141891949000

> Once again, it depends on the scenario you're using.
> If you have a web application server like jboss+tomcat and you use it,
> as I do, to serve mobile clients you don't want 5xx errors to get into
> to end user. More, normally a 5xx error it's not just a problem with one
> URL, in application servers if an application is with some problem all
> URLs that depend on it will be affected. This leads to great service
> degradation, since one app can be an entire portal or similar. In those
> cases would you balance traffic to those backends? Well, I don't think
> so.
> To be clear, I think it's dumb to consider 5xx HTTP errors as the entire
> server is dead, ok?
> What I am trying to say is that this should be configurable since, in my
> point of view, there might be cases where if you're getting 5xx error
> codes then it's because the server it's of no use to you. Probably the
> web server is OK but not the applications that you depend on.
> Cisco load balancers, although I cannot guarantee 100%, do a check on a
> URL you specify and they expect to receive a HTTP 200 code. So what I am
> trying to say is that my opinion seems to be also the opinions of other.
> But we are here to discuss :)
>
>
> About this last phrase, I almost sure it's not true from discussions
> here and from source code analyzing.
>
> "Ultimately what to do with an application level failure can be
> different
> for each application. Pound has no knowledge of what failed. It *does*
> know that the web server itself is still okay since it managed to return
>
> a HTTP code."
>
>
> Pound doesn't look at the HTTP protocol level to consider a backend
> dead, and it should. Pound only looks if it can do a socket connection
> to a backend and if not then it considers it dead.

But then again, I'm not sure pound should do all of this. For more complex
setups I guess it's better to have a dedicated system monitoring which can
be observed by pound using the HAport feature. Even a bash script could do
this job in a very flexible way.

Simon

IMO, the conclusion is that since its not a general principle that a 500
code signifies an unreachable backend server, it is not pounds job to
deal with that condition.

As was said previously, you can reach your goal today by using the
HAPort option and talking to some script at the backend that can
specifically interpret the condition of your appservers

Christian

Sergio Freire wrote:
> Once again, it depends on the scenario you're using.
> If you have a web application server like jboss+tomcat and you use it,
> as I do, to serve mobile clients you don't want 5xx errors to get into
> to end user. More, normally a 5xx error it's not just a problem with one
> URL, in application servers if an application is with some problem all
> URLs that depend on it will be affected. This leads to great service
> degradation, since one app can be an entire portal or similar. In those
> cases would you balance traffic to those backends? Well, I don't think
> so.
> To be clear, I think it's dumb to consider 5xx HTTP errors as the entire
> server is dead, ok?
> What I am trying to say is that this should be configurable since, in my
> point of view, there might be cases where if you're getting 5xx error
> codes then it's because the server it's of no use to you. Probably the
> web server is OK but not the applications that you depend on.
> Cisco load balancers, although I cannot guarantee 100%, do a check on a
> URL you specify and they expect to receive a HTTP 200 code. So what I am
> trying to say is that my opinion seems to be also the opinions of other.
> But we are here to discuss :)
> 
> 
> About this last phrase, I almost sure it's not true from discussions
> here and from source code analyzing.
> 
> "Ultimately what to do with an application level failure can be
> different 
> for each application. Pound has no knowledge of what failed. It *does* 
> know that the web server itself is still okay since it managed to return
> 
> a HTTP code."
> 
> 
> Pound doesn't look at the HTTP protocol level to consider a backend
> dead, and it should. Pound only looks if it can do a socket connection
> to a backend and if not then it considers it dead.
> 
> Regards,
> Sergio Freire
> 
> 
> -----Original Message-----
> From: Ximon Eighteen [mailto:ximon.eighteen(at)int.greenpeace.org] 
> Sent: Thursday, March 09, 2006 8:12 AM
> To: pound(at)apsis.ch
> Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
> dead when?
> 
> On the subject of 500 HTTP codes I'd just like to throw in my 10c.
> 
> The web applications I am familiar with generate 500 errors on a per 
> page URL. Some URLs invoke a code route which has a typo in it and so 
> Python or Ruby or Java or whatever interpreter/compiler powers your web 
> site cannot serve the page and returns 500. This doesn't mean that other
> 
> URLs cannot be served however so the server is not dead, just that 
> particular request could not be served.
> 
> If Pound declares the server dead based on 500 codes from particular 
> URLs while the rest of the site is functional that wouldn't be very 
> helpful.
> 
> Ultimately what to do with an application level failure can be different
> 
> for each application. Pound has no knowledge of what failed. It *does* 
> know that the webserver itself is still okay since it managed to return 
> a HTTP code.
> 
> Ximon
> 
> 

Ok, two questions, one for all and the last for Robert:

	1) HAport specifies an address/port for monitoring; this means
ALL checks are done through these settings and not through the normal
expected backend URL? Imagine that the HAport is down but the backend is
UP.. the backend is considered down or up? I think is down since HAport
is more important, correct?
	2) shouldn't Pound do the check at application level (level 7)
and not at TCP/IP level (level 3)? It only verifies if it can connect to
a server socket... in my opinion it should check if it can connect and
if it receives a valid HTTP response. Robert?

Regards,
Sergio Freire

-----Original Message-----
From: Christian Sell [mailto:christian.sell(at)netcologne.de] 
Sent: Thursday, March 09, 2006 11:08 AM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
dead when?

IMO, the conclusion is that since its not a general principle that a 500
code signifies an unreachable backend server, it is not pounds job to
deal with that condition.

As was said previously, you can reach your goal today by using the
HAPort option and talking to some script at the backend that can
specifically interpret the condition of your appservers

Christian

Sergio Freire wrote:
> Once again, it depends on the scenario you're using.
> If you have a web application server like jboss+tomcat and you use it,
> as I do, to serve mobile clients you don't want 5xx errors to get into
> to end user. More, normally a 5xx error it's not just a problem with
one
> URL, in application servers if an application is with some problem all
> URLs that depend on it will be affected. This leads to great service
> degradation, since one app can be an entire portal or similar. In
those
> cases would you balance traffic to those backends? Well, I don't think
> so.
> To be clear, I think it's dumb to consider 5xx HTTP errors as the
entire
> server is dead, ok?
> What I am trying to say is that this should be configurable since, in
my
> point of view, there might be cases where if you're getting 5xx error
> codes then it's because the server it's of no use to you. Probably the
> web server is OK but not the applications that you depend on.
> Cisco load balancers, although I cannot guarantee 100%, do a check on
a
> URL you specify and they expect to receive a HTTP 200 code. So what I
am
> trying to say is that my opinion seems to be also the opinions of
other.
> But we are here to discuss :)
> 
> 
> About this last phrase, I almost sure it's not true from discussions
> here and from source code analyzing.
> 
> "Ultimately what to do with an application level failure can be
> different 
> for each application. Pound has no knowledge of what failed. It *does*

> know that the web server itself is still okay since it managed to
return
> 
> a HTTP code."
> 
> 
> Pound doesn't look at the HTTP protocol level to consider a backend
> dead, and it should. Pound only looks if it can do a socket connection
> to a backend and if not then it considers it dead.
> 
> Regards,
> Sergio Freire
> 
> 
> -----Original Message-----
> From: Ximon Eighteen [mailto:ximon.eighteen(at)int.greenpeace.org] 
> Sent: Thursday, March 09, 2006 8:12 AM
> To: pound(at)apsis.ch
> Subject: Re: [Pound Mailing List] Pound doubt - backend is considered
> dead when?
> 
> On the subject of 500 HTTP codes I'd just like to throw in my 10c.
> 
> The web applications I am familiar with generate 500 errors on a per 
> page URL. Some URLs invoke a code route which has a typo in it and so 
> Python or Ruby or Java or whatever interpreter/compiler powers your
web 
> site cannot serve the page and returns 500. This doesn't mean that
other
> 
> URLs cannot be served however so the server is not dead, just that 
> particular request could not be served.
> 
> If Pound declares the server dead based on 500 codes from particular 
> URLs while the rest of the site is functional that wouldn't be very 
> helpful.
> 
> Ultimately what to do with an application level failure can be
different
> 
> for each application. Pound has no knowledge of what failed. It *does*

> know that the webserver itself is still okay since it managed to
return 
> a HTTP code.
> 
> Ximon
> 
> 


-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141902462000

On Thu, 2006-03-09 at 11:22 +0000, Sergio Freire wrote:
> Ok, two questions, one for all and the last for Robert:

Still here...

> 	1) HAport specifies an address/port for monitoring; this means
> ALL checks are done through these settings and not through the normal
> expected backend URL? Imagine that the HAport is down but the backend is
> UP.. the backend is considered down or up? I think is down since HAport
> is more important, correct?

Basically yes. There is one exception to the rule: if a back-end does
not respond it is still declared dead, but its resurrection is dependent
on HAport.

> 	2) shouldn't Pound do the check at application level (level 7)
> and not at TCP/IP level (level 3)? It only verifies if it can connect to
> a server socket... in my opinion it should check if it can connect and
> if it receives a valid HTTP response. Robert?

HAport is designed that way to allow you to implement your own policy.
Basically you create your own mechanism that checks the health of the
web server, and the HAport is how Pound communicates with it. This is a
simple way to cause back-ends to be considered dead or alive, which is
external to Pound.

The main point is that you do NOT integrate this sort of policy
decision-making into Pound itself, but implement it as an external
module. This gives you all the flexibility you may ever need - make your
checks as simple or as complex as you wish - while keeping the Pound
code as simple as possible (a good thing in my opinion).

Therefore:

- without HAport Pound decides if a back-end is alive or dead based on
if it can reply: if no response arrives the back-end is considered dead.
The status is periodically checked (via a simple connection attempt) to
allow for back-end resurrection.

- with HAport Pound basically delegates the decision to an external
policy checker. The socket connect is simply a signalling mechanism - we
could have used signals or semaphores just as easily, but we wanted a
network-transparent mechanism.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Ok, so what I am seeing wrong?
I am using Pound 2.0.
I have one server with Pound 10.112.70.20 which has two backends .21 and
.22.
I stopped a server in .21 used in HAport but I still see Pound sending
traffic to it as you can see bellow. Why?


This is part of my config:


        ListenHTTP
            Address 0.0.0.0
            Port    80

            Service
                Session
                        Type    HEADER
                        ID      "x-up-calling-line-id"
                        TTL     300
                End

                BackEnd
                    Address dino-fe1
                    Port    80
                    HAport  12060
                End
                BackEnd
                    Address dino-fe2
                    Port    80
                    HAport  12060
                End


            End

        End





These are the logs:



Mar  9 12:17:19 dino-lb1 pound: 172.30.2.3 GET
/discovery.action?folderId=1040 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.70.22:80)
Mar  9 12:17:19 dino-lb1 pound: BackEnd 10.112.70.21:12060 is dead (HA)
Mar  9 12:17:19 dino-lb1 last message repeated 3 times
Mar  9 12:17:20 dino-lb1 pound: 172.30.2.3 GET
/discovery.action?folderId=1127 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.70.22:82)
Mar  9 12:17:20 dino-lb1 pound: 172.30.2.3 GET
/discovery.action?contentTypeId=1000 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.70.22:
82)
Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET
/content/icons/TI/TI-Polifonicos.gif?iid=4&resize=15 HTTP/1.1 - HTTP/1.1
200 O
K (10.112.70.22:82)
Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/small_jogos.gif
HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/separator.gif
HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/jogos.gif
HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
Mar  9 12:17:22 dino-lb1 pound: 172.30.2.3 GET
/content.action?folderId=1041&contentId=18402 HTTP/1.1 - HTTP/1.1 200 OK
(10.1
12.70.22:80)
Mar  9 12:17:22 dino-lb1 pound: 172.30.2.3 GET
/content.action?folderId=1040&contentId=1309 HTTP/1.1 - HTTP/1.1 200 OK
(10.11
2.70.22:80)
Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET /offers.action HTTP/1.1 -
HTTP/1.1 200 OK (10.112.70.22:80)
Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET
/content/18402.gif?cid=18402&iid=1&resize=90 HTTP/1.1 - HTTP/1.1 200 OK
(10.11
2.70.22:80)
Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET /css/i9.css HTTP/1.1 -
HTTP/1.1 200 OK (10.112.70.22:82)
Mar  9 12:17:24 dino-lb1 pound: 172.30.2.3 GET
/content/icons/TI/top.gif?iid=4&resize=15 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.7
0.22:82)
Mar  9 12:17:24 dino-lb1 pound: 172.30.2.3 GET
/content/ducatiextreme_120x160.gif?cid=1126&iid=1&resize=90 HTTP/1.1 -
HTTP/1.
1 200 OK (10.112.70.22:80)
Mar  9 12:17:25 dino-lb1 pound: 172.30.2.3 GET
/purchase.action?offerId=12686 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.70.22:80)
Mar  9 12:17:25 dino-lb1 pound: MONITOR: worker exited on signal 11,
restarting...
Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
/content.action?folderId=1040&contentId=12666 HTTP/1.1 - HTTP/1.1 200 OK
(10.1
12.70.21:81)
Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
/discovery.action?folderId=1027 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.70.21:81)
Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
/delivery/http?buyid=1302217 HTTP/1.1 - HTTP/1.1 302 Moved Temporarily
(10.112
.70.21:83)
Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
/discovery.action?folderId=1189 HTTP/1.1 - HTTP/1.1 200 OK
(10.112.70.21:82)
Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
/content/wwtbam_Portugal_screenshot_120x160.gif?cid=1309&iid=1&resize=90
HTTP/
1.1 - HTTP/1.1 200 OK (10.112.70.22:80)



-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Thursday, March 09, 2006 11:47 AM
To: pound(at)apsis.ch
Subject: RE: [Pound Mailing List] Pound doubt - backend is considered
dead when?

On Thu, 2006-03-09 at 11:22 +0000, Sergio Freire wrote:
> Ok, two questions, one for all and the last for Robert:

Still here...

> 	1) HAport specifies an address/port for monitoring; this means
> ALL checks are done through these settings and not through the normal
> expected backend URL? Imagine that the HAport is down but the backend
is
> UP.. the backend is considered down or up? I think is down since
HAport
> is more important, correct?

Basically yes. There is one exception to the rule: if a back-end does
not respond it is still declared dead, but its resurrection is dependent
on HAport.

> 	2) shouldn't Pound do the check at application level (level 7)
> and not at TCP/IP level (level 3)? It only verifies if it can connect
to
> a server socket... in my opinion it should check if it can connect and
> if it receives a valid HTTP response. Robert?

HAport is designed that way to allow you to implement your own policy.
Basically you create your own mechanism that checks the health of the
web server, and the HAport is how Pound communicates with it. This is a
simple way to cause back-ends to be considered dead or alive, which is
external to Pound.

The main point is that you do NOT integrate this sort of policy
decision-making into Pound itself, but implement it as an external
module. This gives you all the flexibility you may ever need - make your
checks as simple or as complex as you wish - while keeping the Pound
code as simple as possible (a good thing in my opinion).

Therefore:

- without HAport Pound decides if a back-end is alive or dead based on
if it can reply: if no response arrives the back-end is considered dead.
The status is periodically checked (via a simple connection attempt) to
allow for back-end resurrection.

- with HAport Pound basically delegates the decision to an external
policy checker. The socket connect is simply a signalling mechanism - we
could have used signals or semaphores just as easily, but we wanted a
network-transparent mechanism.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904


-- 
To unsubscribe send an email with subject 'unsubscribe' to
pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
1141904827000

> Ok, so what I am seeing wrong?
> I am using Pound 2.0.
> I have one server with Pound 10.112.70.20 which has two backends .21 and
> .22.
> I stopped a server in .21 used in HAport but I still see Pound sending
> traffic to it as you can see bellow. Why?

I don't see traffic to 10.112.70.21:80 after "BackEnd 10.112.70.21:12060
is dead (HA)". You still have traffic to 10.112.70.21:81 and
10.112.70.21:82 which are not handled by the configuration you showed us.
Looks like we miss some piece of information here.

Simon

>
>
> This is part of my config:
>
>
>         ListenHTTP
>             Address 0.0.0.0
>             Port    80
>
>             Service
>                 Session
>                         Type    HEADER
>                         ID      "x-up-calling-line-id"
>                         TTL     300
>                 End
>
>                 BackEnd
>                     Address dino-fe1
>                     Port    80
>                     HAport  12060
>                 End
>                 BackEnd
>                     Address dino-fe2
>                     Port    80
>                     HAport  12060
>                 End
>
>
>             End
>
>         End
>
>
>
>
>
> These are the logs:
>
>
>
> Mar  9 12:17:19 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId40 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:80)
> Mar  9 12:17:19 dino-lb1 pound: BackEnd 10.112.70.21:12060 is dead (HA)
> Mar  9 12:17:19 dino-lb1 last message repeated 3 times
> Mar  9 12:17:20 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId27 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:82)
> Mar  9 12:17:20 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?contentTypeId00 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:
> 82)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET
> /content/icons/TI/TI-Polifonicos.gif?iid?resize HTTP/1.1 - HTTP/1.1
> 200 O
> K (10.112.70.22:82)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/small_jogos.gif
> HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/separator.gif
> HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/jogos.gif
> HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
> Mar  9 12:17:22 dino-lb1 pound: 172.30.2.3 GET
> /content.action?folderId41&contentId402 HTTP/1.1 - HTTP/1.1 200 OK
> (10.1
> 12.70.22:80)
> Mar  9 12:17:22 dino-lb1 pound: 172.30.2.3 GET
> /content.action?folderId40&contentId09 HTTP/1.1 - HTTP/1.1 200 OK
> (10.11
> 2.70.22:80)
> Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET /offers.action HTTP/1.1 -
> HTTP/1.1 200 OK (10.112.70.22:80)
> Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET
> /content/18402.gif?cid402&iidresize HTTP/1.1 - HTTP/1.1 200 OK
> (10.11
> 2.70.22:80)
> Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET /css/i9.css HTTP/1.1 -
> HTTP/1.1 200 OK (10.112.70.22:82)
> Mar  9 12:17:24 dino-lb1 pound: 172.30.2.3 GET
> /content/icons/TI/top.gif?iid?resize HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.7
> 0.22:82)
> Mar  9 12:17:24 dino-lb1 pound: 172.30.2.3 GET
> /content/ducatiextreme_120x160.gif?cid26&iidresize HTTP/1.1 -
> HTTP/1.
> 1 200 OK (10.112.70.22:80)
> Mar  9 12:17:25 dino-lb1 pound: 172.30.2.3 GET
> /purchase.action?offerId686 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:80)
> Mar  9 12:17:25 dino-lb1 pound: MONITOR: worker exited on signal 11,
> restarting...
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /content.action?folderId40&contentId666 HTTP/1.1 - HTTP/1.1 200 OK
> (10.1
> 12.70.21:81)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId27 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.21:81)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /delivery/http?buyid02217 HTTP/1.1 - HTTP/1.1 302 Moved Temporarily
> (10.112
> .70.21:83)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId89 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.21:82)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /content/wwtbam_Portugal_screenshot_120x160.gif?cid09&iidresize
> HTTP/
> 1.1 - HTTP/1.1 200 OK (10.112.70.22:80)
>
>
>
> -----Original Message-----
> From: Robert Segall [mailto:roseg(at)apsis.ch]
> Sent: Thursday, March 09, 2006 11:47 AM
> To: pound(at)apsis.ch
> Subject: RE: [Pound Mailing List] Pound doubt - backend is considered
> dead when?
>
> On Thu, 2006-03-09 at 11:22 +0000, Sergio Freire wrote:
>> Ok, two questions, one for all and the last for Robert:
>
> Still here...
>
>> 	1) HAport specifies an address/port for monitoring; this means
>> ALL checks are done through these settings and not through the normal
>> expected backend URL? Imagine that the HAport is down but the backend
> is
>> UP.. the backend is considered down or up? I think is down since
> HAport
>> is more important, correct?
>
> Basically yes. There is one exception to the rule: if a back-end does
> not respond it is still declared dead, but its resurrection is dependent
> on HAport.
>
>> 	2) shouldn't Pound do the check at application level (level 7)
>> and not at TCP/IP level (level 3)? It only verifies if it can connect
> to
>> a server socket... in my opinion it should check if it can connect and
>> if it receives a valid HTTP response. Robert?
>
> HAport is designed that way to allow you to implement your own policy.
> Basically you create your own mechanism that checks the health of the
> web server, and the HAport is how Pound communicates with it. This is a
> simple way to cause back-ends to be considered dead or alive, which is
> external to Pound.
>
> The main point is that you do NOT integrate this sort of policy
> decision-making into Pound itself, but implement it as an external
> module. This gives you all the flexibility you may ever need - make your
> checks as simple or as complex as you wish - while keeping the Pound
> code as simple as possible (a good thing in my opinion).
>
> Therefore:
>
> - without HAport Pound decides if a back-end is alive or dead based on
> if it can reply: if no response arrives the back-end is considered dead.
> The status is periodically checked (via a simple connection attempt) to
> allow for back-end resurrection.
>
> - with HAport Pound basically delegates the decision to an external
> policy checker. The socket connect is simply a signalling mechanism - we
> could have used signals or semaphores just as easily, but we wanted a
> network-transparent mechanism.
> --
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> --
> To unsubscribe send an email with subject 'unsubscribe' to
> pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
> http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
> 1141904827000
>
> --
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/1141906377000
>

The configuration is replicated for the other ports.
It seems that this is related with the Monitor thread that crashes...

-----Original Message-----
From: Simon Matter [mailto:simon.matter(at)ch.sauter-bc.com] 
Sent: Thursday, March 09, 2006 12:30 PM
To: pound(at)apsis.ch
Cc: pound(at)apsis.ch
Subject: RE: [Pound Mailing List] Pound doubt - backend is considered dead
when?

> Ok, so what I am seeing wrong?
> I am using Pound 2.0.
> I have one server with Pound 10.112.70.20 which has two backends .21 and
> .22.
> I stopped a server in .21 used in HAport but I still see Pound sending
> traffic to it as you can see bellow. Why?

I don't see traffic to 10.112.70.21:80 after "BackEnd 10.112.70.21:12060
is dead (HA)". You still have traffic to 10.112.70.21:81 and
10.112.70.21:82 which are not handled by the configuration you showed us.
Looks like we miss some piece of information here.

Simon

>
>
> This is part of my config:
>
>
>         ListenHTTP
>             Address 0.0.0.0
>             Port    80
>
>             Service
>                 Session
>                         Type    HEADER
>                         ID      "x-up-calling-line-id"
>                         TTL     300
>                 End
>
>                 BackEnd
>                     Address dino-fe1
>                     Port    80
>                     HAport  12060
>                 End
>                 BackEnd
>                     Address dino-fe2
>                     Port    80
>                     HAport  12060
>                 End
>
>
>             End
>
>         End
>
>
>
>
>
> These are the logs:
>
>
>
> Mar  9 12:17:19 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId40 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:80)
> Mar  9 12:17:19 dino-lb1 pound: BackEnd 10.112.70.21:12060 is dead (HA)
> Mar  9 12:17:19 dino-lb1 last message repeated 3 times
> Mar  9 12:17:20 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId27 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:82)
> Mar  9 12:17:20 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?contentTypeId00 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:
> 82)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET
> /content/icons/TI/TI-Polifonicos.gif?iid?resize HTTP/1.1 - HTTP/1.1
> 200 O
> K (10.112.70.22:82)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/small_jogos.gif
> HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/separator.gif
> HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
> Mar  9 12:17:21 dino-lb1 pound: 172.30.2.3 GET /images/jogos.gif
> HTTP/1.1 - HTTP/1.1 304 Not Modified (10.112.70.22:80)
> Mar  9 12:17:22 dino-lb1 pound: 172.30.2.3 GET
> /content.action?folderId41&contentId402 HTTP/1.1 - HTTP/1.1 200 OK
> (10.1
> 12.70.22:80)
> Mar  9 12:17:22 dino-lb1 pound: 172.30.2.3 GET
> /content.action?folderId40&contentId09 HTTP/1.1 - HTTP/1.1 200 OK
> (10.11
> 2.70.22:80)
> Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET /offers.action HTTP/1.1 -
> HTTP/1.1 200 OK (10.112.70.22:80)
> Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET
> /content/18402.gif?cid402&iidresize HTTP/1.1 - HTTP/1.1 200 OK
> (10.11
> 2.70.22:80)
> Mar  9 12:17:23 dino-lb1 pound: 172.30.2.3 GET /css/i9.css HTTP/1.1 -
> HTTP/1.1 200 OK (10.112.70.22:82)
> Mar  9 12:17:24 dino-lb1 pound: 172.30.2.3 GET
> /content/icons/TI/top.gif?iid?resize HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.7
> 0.22:82)
> Mar  9 12:17:24 dino-lb1 pound: 172.30.2.3 GET
> /content/ducatiextreme_120x160.gif?cid26&iidresize HTTP/1.1 -
> HTTP/1.
> 1 200 OK (10.112.70.22:80)
> Mar  9 12:17:25 dino-lb1 pound: 172.30.2.3 GET
> /purchase.action?offerId686 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.22:80)
> Mar  9 12:17:25 dino-lb1 pound: MONITOR: worker exited on signal 11,
> restarting...
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /content.action?folderId40&contentId666 HTTP/1.1 - HTTP/1.1 200 OK
> (10.1
> 12.70.21:81)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId27 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.21:81)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /delivery/http?buyid02217 HTTP/1.1 - HTTP/1.1 302 Moved Temporarily
> (10.112
> .70.21:83)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /discovery.action?folderId89 HTTP/1.1 - HTTP/1.1 200 OK
> (10.112.70.21:82)
> Mar  9 12:17:27 dino-lb1 pound: 172.30.2.3 GET
> /content/wwtbam_Portugal_screenshot_120x160.gif?cid09&iidresize
> HTTP/
> 1.1 - HTTP/1.1 200 OK (10.112.70.22:80)
>
>
>
> -----Original Message-----
> From: Robert Segall [mailto:roseg(at)apsis.ch]
> Sent: Thursday, March 09, 2006 11:47 AM
> To: pound(at)apsis.ch
> Subject: RE: [Pound Mailing List] Pound doubt - backend is considered
> dead when?
>
> On Thu, 2006-03-09 at 11:22 +0000, Sergio Freire wrote:
>> Ok, two questions, one for all and the last for Robert:
>
> Still here...
>
>> 	1) HAport specifies an address/port for monitoring; this means
>> ALL checks are done through these settings and not through the normal
>> expected backend URL? Imagine that the HAport is down but the backend
> is
>> UP.. the backend is considered down or up? I think is down since
> HAport
>> is more important, correct?
>
> Basically yes. There is one exception to the rule: if a back-end does
> not respond it is still declared dead, but its resurrection is dependent
> on HAport.
>
>> 	2) shouldn't Pound do the check at application level (level 7)
>> and not at TCP/IP level (level 3)? It only verifies if it can connect
> to
>> a server socket... in my opinion it should check if it can connect and
>> if it receives a valid HTTP response. Robert?
>
> HAport is designed that way to allow you to implement your own policy.
> Basically you create your own mechanism that checks the health of the
> web server, and the HAport is how Pound communicates with it. This is a
> simple way to cause back-ends to be considered dead or alive, which is
> external to Pound.
>
> The main point is that you do NOT integrate this sort of policy
> decision-making into Pound itself, but implement it as an external
> module. This gives you all the flexibility you may ever need - make your
> checks as simple or as complex as you wish - while keeping the Pound
> code as simple as possible (a good thing in my opinion).
>
> Therefore:
>
> - without HAport Pound decides if a back-end is alive or dead based on
> if it can reply: if no response arrives the back-end is considered dead.
> The status is periodically checked (via a simple connection attempt) to
> allow for back-end resurrection.
>
> - with HAport Pound basically delegates the decision to an external
> policy checker. The socket connect is simply a signalling mechanism - we
> could have used signals or semaphores just as easily, but we wanted a
> network-transparent mechanism.
> --
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
>
>
> --
> To unsubscribe send an email with subject 'unsubscribe' to
> pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
> http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/
> 1141904827000
>
> --
> To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
> Please contact roseg(at)apsis.ch for questions.
>
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/1141906377000
>

-- 
To unsubscribe send an email with subject 'unsubscribe' to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.
http://www.apsis.ch/pound/pound_list/archive/2006/2006-03/1141833385000/1141907385000