Hi,

I don't know how practical this would be but could pound reuse a 
connection (if available) after randomly selecting a backend? By maintaining
a connection pool for each backend I would have thought the number of TCP
connections being created/destroyed between pound and the backends would 
be significantly reduced. Particularly if the backends were configured 
with a large keep alive period to take advantage of this.

This would preserve the random distribution of client requests over the
backend servers whilst also getting the benefits of reusing connections. 
The only problem I can see would be the overhead/complexity of maintaining 
the connection pools.

Regards,
Andrew


On Mon, 22 Sep 2008, Robert Segall wrote:
[...]

Just between you and me, pound could use better documentation.  A wiki
would be a huge service.

Carlos Konstanski

On Thu, 13 Nov 2008, Human Servers wrote:
[...]
Carlos

On 11/12/2008 10:33 PM, Carlos Konstanski wrote:[...]


I would second that nomination for a wiki.  :-)  The community could
then help provide useful tips and documentation.

I would suggest the primary documentation not be lost to the wiki
though, as an official read-only document is valuable too.  The wiki
documentation could help feed the official document as well.

Kenneth

Hi,

nice idea, my vote goes to [trac] ;-)

Regards,
Robert


Kenneth Burgener schrieb:[...][...][...]

I think it'd be great, and a source for more sample configs.

It took me a long time to figure out the config that I finally ended up
with, and better documentation for poundctl would also be welcome :) 

-----Original Message-----
From: Robert Klikics [mailto:klikics(at)preisroboter.de] 
Sent: Friday, November 14, 2008 10:27 AM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] Wiki

Hi,

nice idea, my vote goes to [trac] ;-)

Regards,
Robert


Kenneth Burgener schrieb:[...][...][...]
pound(at)apsis.ch.[...]

--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.

--
This message has been scanned for viruses and dangerous content by
SecureMail, and is believed to be clean.

> > Just between you and me, pound could use better documentation.  A
wiki[...]

I would also vote for a Wiki.  They can be invaluable when it comes to
spreading the "tribal knowledge" wealth about products.

--
This e-mail may contain technical information which is controlled by the United
States Government, Department of State, International Traffic & Arms
Regulations (ITAR) (22 CFR 120-130) which requires an export license prior to
sharing with foreign persons. Lacking such license, ITAR technical data is
limited to US Legal Residents only. It is the responsibility of the
organization and individual in control of this data to abide by US export laws.
If you are not a US Legal Resident, immediately forward this e-mail to
notify(at)hartwellcorp.com or reply to sender without reading any further. Take
no other action with this e-mail until contacted.

Notice:  The information in this document and document itself, in whole or in
part, in any form ("Information") is proprietary and/or confidential property
of Hartwell Corporation, Placentia, California.  Hartwell Corporation and its
successors and assignees retain and reserve all right, title and interest in
this information in whole or in part and in all forms.  This Information is
provided to the original recipient only for confidential use, with the
understanding that it will not be used in any manner detrimental to the
interests of Hartwell Corporation, and subject to return on request. 
Reproduction, transmission, distribution or publication of this Information in
any form, in whole or in part, for any purpose without prior written permission
of Hartwell Corporation is strictly prohibited.

[...]

On 11/14/2008 8:27 AM, Robert Klikics wrote:[...]


trac has wiki support, and project release management support as well.
That would be a good solution.

Hi,

Trac is a good product for projects like pound. My voto goes for it.

Regards,  Francisco.

Kenneth Burgener escribió:[...][...][...]

my 2 cents for a wiki too

I think i also would place some of my configs as example there

Also i could think of third party solutions like a "monitoring for
backends", and "how to make HA with ucarp and pound" that i could
document there.

Greg

2008. 11. 17, hétfő keltezéssel 08.18-kor Francisco Ruiz ezt
írta:[...][...]

HTTP 500 level is not considered "server failure".  "Server failure" is 
a state in which connection can not be established.

Chris Sarginson wrote:[...]

Thanks for the clarification, so if a server is responding with "Internal Error
500" (say on a PHP script) pound would continue to direct traffic to the
server?  Is this the same with all 5xx errors?  Does pound simply check for a
socket response, or  does it check for an HTTP status?

Chris

-----Original Message-----
From: Albert [mailto:pound(at)alacra.com]
Sent: 19 November 2008 15:02
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] A few questions

HTTP 500 level is not considered "server failure".  "Server failure" is
a state in which connection can not be established.

Chris Sarginson wrote:[...]

--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.

Pound simply checks if it can establish a connection to the backend.  If 
it can't, then it will take the backend out of the service group.  If 
all backends in the service groups are down, then pound will go to 
emergency backend.

If you want pound to stop going to a backend on 500 level error, I 
suggest you write a small service on your backend which checks the 
backend HTTP status.  You can use HAPort to have pound connect to such 
service.  If the service sees a problem, it will not accept connections 
from pound. 

Chris Sarginson wrote:[...][...][...]

Yes, "Internal Server Error" means that the server is alive and
"responding" (it's response is that for whatever reason, it was unable
to process your request).  Pound shouldn't care that there is an error
in the script, that's the job of exception handling on the server app.  

You can think of it this way, Pound should be transparent, what would
happen if Pound wasn't in front of the web servers? If a normal user
received an "internal server error" message from the web server, the
server wouldn't automatically shut off and stop responding to other
valid requests.

I hope that helps.

--Alfonso

-----Original Message-----
From: Chris Sarginson [mailto:Chris.Sarginson(at)ukfast.co.uk] 
Sent: Wednesday, November 19, 2008 10:21 AM
To: pound(at)apsis.ch
Subject: RE: [Pound Mailing List] A few questions

Thanks for the clarification, so if a server is responding with
"Internal Error 500" (say on a PHP script) pound would continue to
direct traffic to the server?  Is this the same with all 5xx errors?
Does pound simply check for a socket response, or  does it check for an
HTTP status?

Chris

-----Original Message-----
From: Albert [mailto:pound(at)alacra.com]
Sent: 19 November 2008 15:02
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] A few questions

HTTP 500 level is not considered "server failure".  "Server failure" is
a state in which connection can not be established.

Chris Sarginson wrote:[...]
location that are unused unless neither of the primary servers are
responding.[...]
pound(at)apsis.ch.[...]

--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.

--
To unsubscribe send an email with subject unsubscribe to pound(at)apsis.ch.
Please contact roseg(at)apsis.ch for questions.

--
This message has been scanned for viruses and dangerous content by
SecureMail, and is believed to be clean.

Hi Robert,[...][...][...]
Using m4 is an interesting workaround.  The downsides of this are both 
technical and business related:

    * Technical: The deployment of Pound is not portable.  That is, we
      cannot then migrate Pound configuration files from one of our
      servers to another without being part of the Pound software
      deployment process.  We'd minimally need to modify
      /etc/init.d/pound so that our changes are applied before starting
      Pound each time.  And, we'd need to install our scripts that run
      m4, check for errors (e.g., missing files, recursion loops, etc.),
      and take appropriate action if errors are found (as simple as
      returning an error status so that "service pound start" fails).
    * Business: Especially for businesses other than small businesses,
      it is important that risks be mitigated.  The loose coupling of
      two pieces of software introduces risk.  It would be better to
      have one piece of software that can be QE tested and deployed.

So, while the workaround is certainly technically possible, it would not 
be a desirable solution for enterprise environments.  Pound deserves to 
be Enterprise Grade.

As a side note, it would be a desirable feature that to have Pound 
capable of re-reading configuration files without the service going down 
(e.g., initiated with a HUP signal).  Doing "service pound restart" is 
always a bit troubling... there is a window in which the server will 
fail to honor requests that always makes me cringe.

Thanks,
Steve Amerige
Fat Bear Incorporated

While I agree with the desire for an 'Include' statement, and perhaps a config
reload method also, in the mean time you can have 2+ balancers sharing 1 IP
with ucarp to have one take over while the other is restarting.  This setup has
an added advantage of making OS upgrades and machine reboots easy also.

-Miles

Fat Bear Incorporated - Pound Mailing List wrote:[...][...]
>>> Is there any "Include" directive for pound such as in Apache?  If 
>>> not, can it be added?  This would really help us better manage
Pound 
>>> in a virtual hosting environment.  Also, just like Apache, I would

>>> like the ability for included files to also use Include
directives.  
>>> With this addition, I will be able to add Pound support to 
>>> Virtualmin, a feature that I wish to develop.
>>>     [...][...]

On Thu, Nov 6, 2008 at 12:19 PM, Nigel Kersten <nigelk(at)google.com>
wrote:
[...][...]
Did that provide any useful info Robert?
[...]