Ok, until now the latest beta behaves ok.
Regards,
Sérgio

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Monday, January 23, 2006 1:12 PM
To: pound(at)apsis.ch
Subject: [Pound Mailing List] 2.0 Release

Unless someone comes up with additional problems or objections we would
like to release the "official" 2.0 by the end of this week. The code is
(essentially) that of the latest beta.

Please let us know if you found out anything that still needs fixing.
-- 
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-01/1138021893000

> Unless someone comes up with additional problems or objections we would
> like to release the "official" 2.0 by the end of this week. The code is
> (essentially) that of the latest beta.

We're running 2.0-0.b6_1 for quite some time now on two production servers
without any problems. We also don't see any memory leaks anymore like the
one we saw with 1.x.

Simon

Are you going to include any init scripts?
If you want me to revise anything please tell.
Regards,
Sergio Freire

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Monday, January 23, 2006 1:12 PM
To: pound(at)apsis.ch
Subject: [Pound Mailing List] 2.0 Release

Unless someone comes up with additional problems or objections we would
like to release the "official" 2.0 by the end of this week. The code is
(essentially) that of the latest beta.

Please let us know if you found out anything that still needs fixing.
-- 
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-01/1138021893000

On Mon, 2006-01-23 at 16:18 +0000, Sergio Freire wrote:
> Are you going to include any init scripts?
> If you want me to revise anything please tell.
> Regards,
> Sergio Freire

Thanks for the offer, but we do not include init scripts or anything of
the sort. Given that each system is different we feel it is best to
leave that to the packagers (Debian is not RH is not Suse is not FreeBSD
is not OpenBSD is not Solaris is not AIX is not OS/X is not Cygwin is
not OpenVMS is not Tru64 is not zOS - you get the idea).
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Hello,

Apologies that it has taken so long to reply, I have been on holidays
for six weeks.  We recently went live with Pound 1.9.x on our site
http://www.globalhand.org.  We are in the process of adding a number of
features to Pound.

A key feature we require is the ability to failover to a server, if and
only if all backend servers are dead.  We require this functionality to
bypass our inline cache if it fails.  We had considered using cached and
non-cached access to our site as backends, the cached access being
weighted highly whilst the non-cached access being weighted low.  This
is not possible in our case as some of our pages are very intensive to
create and relatively static, the performance penalty is too great.

Additionally, we need to set a <meta> tag in the head of the error pages
so we can perform redirection to the real error page (we have nice
friendly nice looking error pages served from Apache) if there is an
error in Pound.  We have noticed that specifying a Err4xx page in the
configuration file does not allow control of all the HTML served during
an error, Pound adds its' own head, title and HTML to the page.

Initially we will add these features to the 1.9.x branch as we are most
familiar with the source, and will port it to 2.x once it has stabilised
(I see 2.x is about to leave beta status) and we have done sufficient
testing.

Could you post somewhere, or email us the configure.in and associated
files so we can add additional configuration options.  We are
considering a '--no-ssl' or similar option to remove all SSL code along
with a few other options.


				Many thanks,


				Tom Pike

On Mon, 2005-12-12 at 12:56 +0100, Robert Segall wrote: 
> On Sat, 2005-12-10 at 15:53 +1100, Tom Pike wrote:
> > G'day,
> > 
> > 	We've been using 1.9.x Pound for quite some time, in fact we are soon
> > to go live with our site, a combination of ZEO/Squid/Pound/Apache after
> > several months of configuration and testing.  We really need to add some
> > functionality to Pound and were wondering about the status of the new
> > 2.x tree.  Is it worth modifying 1.9.x or should we start with the 2.x
> > betas?  It will probably be a 2-3 months before we are finished with our
> > additions and testing.
> 
> The 1.x series is pretty much EOL. I suggest you go with 2.0, which will
> be released as soon as we can iron out all the bugs.
> 
> You may also want to tell us a bit more about what changes you want -
> some of them may be planned anyway, so we could both save some effort.
> -- 
> Robert Segall
> Apsis GmbH
> Postfach, Uetikon am See, CH-8707
> Tel: +41-44-920 4904
> 
> 
-- 
+------------------------------------------+
| Tom Pike thwpike(at)p3international.org     |
| P3 International www.p3international.org |
+------------------------------------------+

On Thu, 2006-01-26 at 23:28 +1100, Tom Pike wrote:
> Hello,
> 
> Apologies that it has taken so long to reply, I have been on holidays
> for six weeks.  We recently went live with Pound 1.9.x on our site
> http://www.globalhand.org.  We are in the process of adding a number of
> features to Pound.
> 
> A key feature we require is the ability to failover to a server, if and
> only if all backend servers are dead.  We require this functionality to
> bypass our inline cache if it fails.  We had considered using cached and
> non-cached access to our site as backends, the cached access being
> weighted highly whilst the non-cached access being weighted low.  This
> is not possible in our case as some of our pages are very intensive to
> create and relatively static, the performance penalty is too great.
> 
> Additionally, we need to set a <meta> tag in the head of the error pages
> so we can perform redirection to the real error page (we have nice
> friendly nice looking error pages served from Apache) if there is an
> error in Pound.  We have noticed that specifying a Err4xx page in the
> configuration file does not allow control of all the HTML served during
> an error, Pound adds its' own head, title and HTML to the page.
> 
> Initially we will add these features to the 1.9.x branch as we are most
> familiar with the source, and will port it to 2.x once it has stabilised
> (I see 2.x is about to leave beta status) and we have done sufficient
> testing.
> 
> Could you post somewhere, or email us the configure.in and associated
> files so we can add additional configuration options.  We are
> considering a '--no-ssl' or similar option to remove all SSL code along
> with a few other options.

The emergency back-end and/or redirect are planned features for 2.1.
Right now we concentrate on getting 2.0 out - hopefully this week. In
any case I suggest you try working on the 2.x series, as 1.x are
definitely EOL and we won't be making any new releases there.

As to specifics: we plan on adding an Emergency back-end directive,
which can be either a real back-end or a redirect. This would be
activated iff all back-ends for a given Service are dead.

The 4xx error won't help you. It is meant only as an indication for the
client that it has exceeded a Pound limit (specifically the length of a
request URI), and it does not indicate a problem on the back-ends. A
possible change there would be to take a full HTML file rather than a
text file/string. I would appreciate some opinions on this.

Finally a --no-ssl option would be difficult to do, as all I/O is done
via the BIO functions, even for regular HTTP. So at best you could
disable HTTPS, but that won't remove the dependency on the OpenSSL
library.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904