[...]
Why is it "deadly" in your opinion?

Would you like to benefit from a clean core dump?
http://en.wikipedia.org/wiki/Core_dump

[...]
Can the process correctly continue to run after a non-zero value was 
returned by 
"http://opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html"?
How much do you care for the danger that the current program behaviour 
can become thread-unsafe?

Regards,
Markus

As a person who uses Sticky session state and supports many concurrent
web sessions, I would rather most of the program work and maintain my
session than have the program dump core, thereby affecting ALL the users
and likely causing them to recreate all their sessions.

Your reference to crash only software doesn't apply, because there is no
way for pound to micro-reboot.  The config has to be parsed at start up
and it can't do incremental application or maintain session state.
Given those facts, I think Pound throwing an error is perfectly
acceptable.

Hell, I have another product (closed source from another vendor) that
throws 30-40 error messages a second to my syslog.  Other than that, it
runs fine.  If the programmer made the thing crash instead, I'd never be
able to get any data out of it.

I don't see any major problems with the philosophical decisions behind
Pound.  If it ain't broke, don't fix it!

Joseph Gooch
Sapphire Suite Product Manager
K12 Systems, Inc.
(866) 366-9540

[...]
[mailto:elfring(at)users.sourceforge.net][...]
load[...]
is[...]
ht[...]
pound(at)apsis.ch.[...]

Markus,

I hear lots of criticism, but don't see you producing any code to fix the
problems that you point out.

(I realize that I haven't contributed code to pound either)


On 10/3/06 3:18 AM, "SF Markus Elfring"
<elfring(at)users.sourceforge.net>
wrote:
[...][...][...][...][...]

[...]
I have tried to contribute some code. It seems that a suggestion about
const-correctness was accepted while the contribution about correct error
handling for synchronisation calls seems to need a second (or third?) try.

I hope that consensus can be achieved with the software maintainers. How do you
think about the arguments from my view?

Regards,
Markus

On 10/3/06 1:33 PM, "SF Markus Elfring"
<elfring(at)users.sourceforge.net>
wrote:
[...]

I think that your arguments are not very persuasive on the most recent
points (to do with return values).  The maintainers have extensive
experience regarding which errors cause instability and which don't.
Moreover, bouncing pound has a very significant cost in terms of system
usage.  If it were possible to do a soft-stop in which all existing
transactions were finished and all existing sessions were transferred to a
new instance of pound, then it might be reasonable to be more paranoid about
these error returns.  It would be a requirement that the new pound be able
to start serving transactions with very little down-time on the listening
ports.

If anyone were to do a soft-handover capability, it could even be used for a
soft transition to a new config file.  That is a feature that people have
been hoping to see for longer than I have known about pound.

[...]
I would like to insist on source code correctness.

Some more return values from "pthread_..." functions are checked after 
my suggestion. It seems that there are different opinions about the 
correct handling for non-zero values (error codes). I say that the 
program execution can not continue to correctly run after a lock or 
unlock operation failed because an absolutely required resource could 
not be acquired or released. Which reactions would you expect if a 
similarly important operation like a memory allocation does not succeed? 
- I recommend an abort. The amount of logging for context information 
and explanation before this final step is subject for debates.
(I'm concerned about thread-safety.)

Regards,
Markus

This is to announce the release of Pound v2.1.4. This is primarily a
bug-fix release. It (hopefully) addresses the urgent problems that were
discovered in 2.1.3.

Changes in this version (since 2.1.3):

Bug fixes:
  - content is now ignored only on HEAD requests
  - added CRLlist directive. The VerifyList is now a separate file

The software is at version 2.1.4 (beta quality). Further testing 
(especially under heavy loads), improvements and suggestions are
welcome.[...]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 14-okt-2006, at 16:51, Robert Segall wrote:
[...]

Hi Robert,

I got it running on OSX 10.48 with the following fixes:

diff -r Pound-2.1.4.orig/Makefile.in Pound-2.1.4/Makefile.in
50c50
<               (at)INSTALL(at) -o bin -g bin -m 555 -s pound ${DESTDIR} 
(at)sbindir(at)/pound
- ---
 >               (at)INSTALL(at) -m 555 -s pound
${DESTDIR}(at)sbindir(at)/pound
53c53
<               (at)INSTALL(at) -o bin -g bin -m 644 pound.8 ${DESTDIR} 
(at)mandir(at)/man8/pound.8
- ---
 >               (at)INSTALL(at) -m 644 pound.8
${DESTDIR}(at)mandir(at)/man8/ 
pound.8
diff -r Pound-2.1.4.orig/configure Pound-2.1.4/configure
3277c3277
<   LIBS="${LIBS} -lpcreposix"
- ---
 >   LIBS="-lpcreposix ${LIBS}"

Somehow parsing the pound config file fails (unknow directive  
"ListenHTTP" - aborted) when libpcreposix is at the end of the list  
of dynamic libs. Moving it forward fixes this.

Kind regards,

Ruben Kerkhof


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (Darwin)

iD8DBQFFMP8xJyEsTYWp9B4RAsowAJ4hRVm7L9SGEhzbDfOG5SGo4Ws+eACfXDZE
XwnxY9nABwdP6GX93Pwm+mo=
=qT0j
-----END PGP SIGNATURE-----

This is to announce the release of Pound v2.1.5. Changes in this version
(since 2.1.4):


Enhancements:

- added line numbers to config error messages to make life easier on
sysadmins.

- added dynamic rescaling of back-end priorities. The priorities are
periodically recalculated, and adjusted as a result of the back-end
average response times. This feature could probably benefit from some
serious stress testing - I would be particularly grateful for feedback
from people with large-volume sites. Given the difficulty of measuring
such a thing accurately your subjective impressions would be fine.

- added support for emergency back-ends. You may now define one back-end
to be used if and only if all other back-ends have failed.

- the program poundctl(8) is now available. For the moment it allows
listing the Pound internal state and enabling/disabling listeners,
services and back-ends. I fully trust the list to come up with creative
suggestions as to how this should be extended - the current code is more
a proof of concept thing (though fully functional).

- added the Control configuration directive to define the control
socket, as required by poundctl(8).


Bug fixes:

- improved owner/group detection for install. The configure script now
tries to look for plausible defined users and groups in order to create
the Makefile with some reasonable values.


The software is at version 2.1.5 (beta quality). Further testing 
(especially under heavy loads), improvements and suggestions are
welcome.[...]

Robert Segall schrieb:
[...]

This is great :)
[...]

Very nice feature!

Thank you for the release!

Regards,

Falk Brockerhoff

> - the program poundctl(8) is now available. For the moment it allows[...]

Hi Robert,

The new poundctl(8) looks very nice!
Small question, Is there a good reason for not providing a default socket
location with poundctl? A default like /var/run/pound/poundctl would be
nice, but then maybe I don't consider something you did when doing it.

Regards,
Simon

[...]
Does this implementation have got anything in common with the design 
pattern "service configurator"?
- http://www.cs.wustl.edu/~schmidt/ACE-papers.html
- http://en.wikipedia.org/wiki/Configuration_management
- http://en.wikipedia.org/wiki/Zeroconf
- http://crash.stanford.edu/

[...]
Is this similar to the approach by the software 
"http://quickserver.sourceforge.net/docs/1.4.5/org/quickserver/net/qsadmin/QSAdminServer.html"?

Regards,
Markus

Fantastic release!

Very nice set of new features.


On 10/23/06 12:52 AM, "Robert Segall" <roseg(at)apsis.ch> wrote:
[...]

Robert, this sounds like a big leap forward to on-the-fly management!

I've got the new version compiled up and working on a RH AS 4.0 test
machine and it seems fine with all the normal URL and Host syntax rules
we use.. I've yet to try out the new features, but can see them being
very, very useful indeed!

Regards

-John

 John Snowdon - IT Support Specialist
-==========================================-
 School of Medical Education Development 
 Faculty of Medical Sciences Computing
 University of Newcastle

 Email : j.p.snowdon(at)ncl.ac.uk

[...]
70705000/1161589921000

Hello Robert,

This sounds very promising, I wil start testing on our servers in a few
days.

Is there any chance this opens up the possibility for a gracefull shutdown
of backends allowing existing sessions to exist while no new ones will be
assigned to the backend?

Except for enabling backends (which could suffice for me) might the option
of adding/removing backends be considered?

Thanks,

Silvio Bierman

Hi

A simple fix that would probably do the trick for most people is to close
the listening sockets immediately when pound is signalled to stop, but 
keep processing the existing tcp sessions. This way a new, reconfigured 
instance of pound can be started practically immediately after the old one 
is signalled to stop, with only milliseconds downtime of services and 
without breaking existing tcp sessions.

This trick is "stolen" from haproxy (http://haproxy.1wt.eu/). haproxy has 
evolved this a step further, where the new process is passed a list of 
pids to synchronise with. When the new process is ready to take over 
listening it sends a signal to stop listen to these pids. If the new 
process fails to start correctly it sends another signal to these pids to 
indicate that the old processes should start listening again and resume 
normal operation.

I don't think there is any need for making a pound implementation this 
complex, however. Closing listening sockets immediately should suffice.

Regards
Rune


---
Rune Sætre <rune.saetre(at)netcom-gsm.no>
NetCom as
..

On Tue, 24 Oct 2006, Silvio Bierman wrote:
[...]

(at) -----Original Message-----
(at) From: Rune Saetre [mailto:rune.saetre(at)netcom-gsm.no]
(at) Sent: 24 October, 2006 15:52
(at) To: pound(at)apsis.ch
(at) Cc: Rune Saetre
(at) Subject: RE: [Pound Mailing List] ANNOUNCE: Pound - reverse proxy and
(at) load balancer - v2.1.5
(at)
(at)
(at) Hi
(at)
(at) A simple fix that would probably do the trick for most people is to close
(at) the listening sockets immediately when pound is signalled to stop, but
(at) keep processing the existing tcp sessions. This way a new, reconfigured
(at) instance of pound can be started practically immediately after
(at) the old one
(at) is signalled to stop, with only milliseconds downtime of services and
(at) without breaking existing tcp sessions.
(at)
(at) This trick is "stolen" from haproxy (http://haproxy.1wt.eu/). haproxy has
(at) evolved this a step further, where the new process is passed a list of
(at) pids to synchronise with. When the new process is ready to take over
(at) listening it sends a signal to stop listen to these pids. If the new
(at) process fails to start correctly it sends another signal to these pids to
(at) indicate that the old processes should start listening again and resume
(at) normal operation.
(at)
(at) I don't think there is any need for making a pound implementation this
(at) complex, however. Closing listening sockets immediately should suffice.
(at)
(at) Regards
(at) Rune
(at)
(at)
(at) ---
(at) Rune Sætre <rune.saetre(at)netcom-gsm.no>
(at) NetCom as
(at) ..
(at)

Hello Rune,

There are no TCP sessions, only HTTP sessions. That means that it is not
possible to have two instances of Pound listening on the same port, they
have to be handled by the same instance.

Or am I missing something?

Regards,

Silvio Bierman

Hi

Yes, you might be missing something.
HTTP is a protocol on top of TCP. HTTP is the language you are speaking 
through the TCP sessions you have set up. TCP sessions used for HTTP used 
to be fairly short lived, as you could send only one HTTP request 
(and receive the associated response) through each TCP session, but with 
HTTP/1.1 it is now possible to send several HTTP requests through each TCP 
session. Also HTTP can be used to carry other protocols on top of HTTP 
(like webdav or BEA WebLogics t3 protocol). This can make the TCP sessions 
very long lived.

If you are not to kill current TCP sessions (abort transfers) pound can 
take quite a while to stop, and during this time it does not allow new tcp 
sessions. As it is now you cannot start a new instance of pound until the 
previous one has exited completely. When reconfiguring pound this gives 
you the choice of killing all current TCP sessions to be able to start the 
reconfigured instance as soon as possible, or wait until all TCP sessions 
have completed "by them selves", and not accepting new connections in the 
meantime.

If pound could not only reject incoming connections while exiting, but 
stop listening to the configured ports entirely, then a new, reconfigured 
instance of pound could start immediately after the old one was signalled 
to stop. This will not affect current TCP sessions, so ongoing transfers 
will be able to complete, and the time when new connections are not 
accepted can be reduced to some milliseconds.

However, since pound is entirely restarted the persistence session table 
will be lost, so that clients might be sent to new backend servers after 
the restart. But if you have to restart pound that is a price you will 
have to pay anyway.

And maybe with the new poundctl interface it might be possible to transfer 
the persistence session table from the old pound instance to the new one?

Rune

---
Rune Sætre <rune.saetre(at)netcom-gsm.no>
NetCom as
..

On Tue, 24 Oct 2006, Silvio Bierman wrote:
[...]

(at) -----Original Message-----
(at) From: Rune Saetre [mailto:rune.saetre(at)netcom-gsm.no]
(at) Sent: 24 October, 2006 17:53
(at) To: pound(at)apsis.ch
(at) Cc: Rune Saetre
(at) Subject: RE: [Pound Mailing List] ANNOUNCE: Pound - reverse proxy and
(at) load balancer - v2.1.5
(at)
(at)
(at) Hi
(at)
(at) Yes, you might be missing something.
(at) HTTP is a protocol on top of TCP. HTTP is the language you are speaking
(at) through the TCP sessions you have set up. TCP sessions used for HTTP used
(at) to be fairly short lived, as you could send only one HTTP request
(at) (and receive the associated response) through each TCP session, but with
(at) HTTP/1.1 it is now possible to send several HTTP requests through
(at) each TCP
(at) session. Also HTTP can be used to carry other protocols on top of HTTP
(at) (like webdav or BEA WebLogics t3 protocol). This can make the TCP
(at) sessions
(at) very long lived.
(at)
(at) If you are not to kill current TCP sessions (abort transfers) pound can
(at) take quite a while to stop, and during this time it does not
(at) allow new tcp
(at) sessions. As it is now you cannot start a new instance of pound until the
(at) previous one has exited completely. When reconfiguring pound this gives
(at) you the choice of killing all current TCP sessions to be able to
(at) start the
(at) reconfigured instance as soon as possible, or wait until all TCP sessions
(at) have completed "by them selves", and not accepting new connections in the
(at) meantime.
(at)
(at) If pound could not only reject incoming connections while exiting, but
(at) stop listening to the configured ports entirely, then a new, reconfigured
(at) instance of pound could start immediately after the old one was signalled
(at) to stop. This will not affect current TCP sessions, so ongoing transfers
(at) will be able to complete, and the time when new connections are not
(at) accepted can be reduced to some milliseconds.
(at)
(at) However, since pound is entirely restarted the persistence session table
(at) will be lost, so that clients might be sent to new backend servers after
(at) the restart. But if you have to restart pound that is a price you will
(at) have to pay anyway.
(at)
(at) And maybe with the new poundctl interface it might be possible to
(at) transfer
(at) the persistence session table from the old pound instance to the new one?
(at)
(at) Rune
(at)
(at) ---
(at) Rune Sætre <rune.saetre(at)netcom-gsm.no>
(at) NetCom as
(at) ..
(at)
(at) On Tue, 24 Oct 2006, Silvio Bierman wrote:
(at)

Ok, so I do understand you correctly. A single TCP transfer (or perhaps N
transfers in a HTTP 1.1 situation, where N is typically small, trend being N
getting smaller since efficiency added value of keep-alive is diminishing)
is hardly worth preserving if the corresponding HTTP session will be broken.

I am talking about a situation where an application user is in a
(non-serializable) HTTP session on backend X which may live for several
minutes or even hours and consist of tens, hundreds or even thousands of TCP
connect/transfer/disconnect cycles.
What I would like is a way to keep such sessions alive while preventing new
HTTP sessions from being created on backend X. Given time (minutes of
perhaps hours) all HTTP sessions on X will terminate (typical session
timeouts are in the 30-90 minutes range). All new TCP connections that come
in without a session cookie should be redirected to different backends than
X (and off course remain there for the duration of the session).

I know all about HTTP session migration and there are many situations where
that is the way to go. If Pound whould be able to support the cases where
non-serializable sessions where chosen it would be quite an asset.

Regards,

Silvio Bierman

Hi

OK, back on track (I hope :-)

I got hung up in "the option of adding/removing backends", wich I guess 
will be done through loading a new config for some time still. At least 
keeping the existing TCP sessions while being able to accept new ones 
would be nice in these circumstances.

This is from the man page for poundctl:
        -B/-b n m r
               Enable/disable  a  back-end.  A  disabled  back-end  will not be
               passed requests to answer. Note however that  existing  sessions
               may still cause requests to be sent their way.

Doesn't this do just what you requested? Or does "existing sessions" mean 
TCP sessions? Or am I still missing something?

Regards
Rune

---
Rune Sætre <rune.saetre(at)netcom-gsm.no>
NetCom as
..

On Wed, 25 Oct 2006, Silvio Bierman wrote:
[...]

Hello Rune,

Thanks for pointing out that part of the man page, I had missed that. If
this does refer to HTTP sessions than it does exactly what I need and I am a
very happy man since this will allow me to update our servers during the day
while people are working on them instead of doing it at 3 in the morning :-)

I will try this out and let you know.

Kind regards,

Silvio Bierman


(at) -----Original Message-----
(at) From: Rune Saetre [mailto:rune.saetre(at)netcom-gsm.no]
(at) Sent: 25 October, 2006 02:35
(at) To: pound(at)apsis.ch
(at) Cc: Rune Saetre
(at) Subject: RE: [Pound Mailing List] ANNOUNCE: Pound - reverse proxy and
(at) load balancer - v2.1.5
(at)
(at)
(at) Hi
(at)
(at) OK, back on track (I hope :-)
(at)
(at) I got hung up in "the option of adding/removing backends", wich I guess
(at) will be done through loading a new config for some time still. At least
(at) keeping the existing TCP sessions while being able to accept new ones
(at) would be nice in these circumstances.
(at)
(at) This is from the man page for poundctl:
(at)         -B/-b n m r
(at)                Enable/disable  a  back-end.  A  disabled
(at) back-end  will not be
(at)                passed requests to answer. Note however that
(at) existing  sessions
(at)                may still cause requests to be sent their way.
(at)
(at) Doesn't this do just what you requested? Or does "existing sessions" mean
(at) TCP sessions? Or am I still missing something?
(at)
(at) Regards
(at) Rune
(at)
(at) ---
(at) Rune Sætre <rune.saetre(at)netcom-gsm.no>
(at) NetCom as
(at) ..
(at)
(at) On Wed, 25 Oct 2006, Silvio Bierman wrote:
(at)
(at) > (at) -----Original Message-----
(at) > (at) From: Rune Saetre [mailto:rune.saetre(at)netcom-gsm.no]
(at) > (at) Sent: 24 October, 2006 17:53
(at) > (at) To: pound(at)apsis.ch
(at) > (at) Cc: Rune Saetre
(at) > (at) Subject: RE: [Pound Mailing List] ANNOUNCE: Pound - reverse
proxy and
(at) > (at) load balancer - v2.1.5
(at) > (at)
(at) > (at)
(at) > (at) Hi
(at) > (at)
(at) > (at) Yes, you might be missing something.
(at) > (at) HTTP is a protocol on top of TCP. HTTP is the language you
(at) are speaking
(at) > (at) through the TCP sessions you have set up. TCP sessions used
(at) for HTTP used
(at) > (at) to be fairly short lived, as you could send only one HTTP
request
(at) > (at) (and receive the associated response) through each TCP
(at) session, but with
(at) > (at) HTTP/1.1 it is now possible to send several HTTP requests
through
(at) > (at) each TCP
(at) > (at) session. Also HTTP can be used to carry other protocols on top
of HTTP
(at) > (at) (like webdav or BEA WebLogics t3 protocol). This can make the
TCP
(at) > (at) sessions
(at) > (at) very long lived.
(at) > (at)
(at) > (at) If you are not to kill current TCP sessions (abort transfers)
(at) pound can
(at) > (at) take quite a while to stop, and during this time it does not
(at) > (at) allow new tcp
(at) > (at) sessions. As it is now you cannot start a new instance of
(at) pound until the
(at) > (at) previous one has exited completely. When reconfiguring pound
(at) this gives
(at) > (at) you the choice of killing all current TCP sessions to be able to
(at) > (at) start the
(at) > (at) reconfigured instance as soon as possible, or wait until all
(at) TCP sessions
(at) > (at) have completed "by them selves", and not accepting new
(at) connections in the
(at) > (at) meantime.
(at) > (at)
(at) > (at) If pound could not only reject incoming connections while
exiting, but
(at) > (at) stop listening to the configured ports entirely, then a new,
(at) reconfigured
(at) > (at) instance of pound could start immediately after the old one
(at) was signalled
(at) > (at) to stop. This will not affect current TCP sessions, so
(at) ongoing transfers
(at) > (at) will be able to complete, and the time when new connections are
not
(at) > (at) accepted can be reduced to some milliseconds.
(at) > (at)
(at) > (at) However, since pound is entirely restarted the persistence
(at) session table
(at) > (at) will be lost, so that clients might be sent to new backend
(at) servers after
(at) > (at) the restart. But if you have to restart pound that is a price
you will
(at) > (at) have to pay anyway.
(at) > (at)
(at) > (at) And maybe with the new poundctl interface it might be possible
to
(at) > (at) transfer
(at) > (at) the persistence session table from the old pound instance to
(at) the new one?
(at) > (at)
(at) > (at) Rune
(at) > (at)
(at) > (at) ---
(at) > (at) Rune Sætre <rune.saetre(at)netcom-gsm.no>
(at) > (at) NetCom as
(at) > (at) ..
(at) > (at)
(at) > (at) On Tue, 24 Oct 2006, Silvio Bierman wrote:
(at) > (at)
(at) >
(at) > Ok, so I do understand you correctly. A single TCP transfer (or
(at) perhaps N
(at) > transfers in a HTTP 1.1 situation, where N is typically small,
(at) trend being N
(at) > getting smaller since efficiency added value of keep-alive is
(at) diminishing)
(at) > is hardly worth preserving if the corresponding HTTP session
(at) will be broken.
(at) >
(at) > I am talking about a situation where an application user is in a
(at) > (non-serializable) HTTP session on backend X which may live for
several
(at) > minutes or even hours and consist of tens, hundreds or even
(at) thousands of TCP
(at) > connect/transfer/disconnect cycles.
(at) > What I would like is a way to keep such sessions alive while
(at) preventing new
(at) > HTTP sessions from being created on backend X. Given time (minutes of
(at) > perhaps hours) all HTTP sessions on X will terminate (typical session
(at) > timeouts are in the 30-90 minutes range). All new TCP
(at) connections that come
(at) > in without a session cookie should be redirected to different
(at) backends than
(at) > X (and off course remain there for the duration of the session).
(at) >
(at) > I know all about HTTP session migration and there are many
(at) situations where
(at) > that is the way to go. If Pound whould be able to support the
(at) cases where
(at) > non-serializable sessions where chosen it would be quite an asset.
(at) >
(at) > Regards,
(at) >
(at) > Silvio Bierman
(at) >
(at) >
(at) > --
(at) > To unsubscribe send an email with subject 'unsubscribe' to
(at) pound(at)apsis.ch.
(at) > Please contact roseg(at)apsis.ch for questions.
(at) >
(at) http://www.apsis.ch/pound/pound_list/archive/2006/2006-10/11598707
05000/1161731007000[...]
--
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-10/1159870705000/1161
736508000

On Oct 23, 2006, at 12:52 AM, Robert Segall wrote:
[...]

I can't seem to get this to work, I've got an apache process setup on  
the same server as pound, listening on port 8686.  I've put an  
Emergency block with the server's IP and that port in the Service  
block.  When I take down all the back-ends I get this message:  "The  
service is not available. Please try again later."

And in the logs I see:
Oct 30 12:56:24 localhost pound: no back-end "GET /home HTTP/1.1"  
from x.x.x.x

I see nothing at all about the emergency back-end.  Is this a bug?

Thanks,
-Blake

On Oct 30, 2006, at 1:00 PM, Blake Barnett wrote:
[...][...][...]

Some additional info:

OS: Debian Etch (testing)
Build: vanilla "./configure && make && make install"
Not running in a chroot
Cookie type is Session
Using HAPort to check for back-end status

-Blake

Just thought I'd report back.... 
I've transferred over all of my pound instances to 2.1.5 now and have
been running with them for a week. No problems encountered so far.

I did notice that I had to change my start/stop utility scripts to issue
a kill -15 signal rather than a kill -9, as the supervisor process was
dieing, but not the child process. Both now die cleanly with the
SIGTERM.

I haven't seen any weird load problems as yet. IP based sessions seem to
be more efficiently spread across a number of systems - previously they
would normally keep going to the first 1 or 2 servers until those boxes
became more loaded, they now spread across the 8 or so servers in that
particular applications case.

Regards

-John

  John Snowdon - IT Support Specialist
 -==========================================-
  School of Medical Education Development 
  Faculty of Medical Sciences Computing
  University of Newcastle
 
  Email : j.p.snowdon(at)ncl.ac.uk

On Mon, 2006-10-30 at 13:00 -0800, Blake Barnett wrote:[...]

Probably. I would appreciate looking at your config file and relevant
logs so we can start on the debugging.[...]

I have the emergency back-end using the same IP as the ListenHTTP  
config, maybe that's the issue?

Here's the config:
-----------------------------------
User            "www-data"
Group           "www-data"
Control         "/var/run/pound.cmd"
LogLevel        2
Alive           5
ListenHTTP
   Address 10.0.8.10
   Port 80

   Service
     URL ".*ps001.*"
     BackEnd
       Address 10.0.8.11
       Port 81
     End
   End
   Service
     URL ".*ps002.*"
     BackEnd
       Address 10.0.8.12
       Port 82
     End
   End
   Service
     URL ".*ps003.*"
     BackEnd
       Address 10.0.8.13
       Port 83
     End
   End

   Service
     Emergency
       Address 10.0.8.10
       Port 8686
     End
     BackEnd
       Address 10.0.8.11
       Port 80
       HAport 9090
       Priority 3
     End
     BackEnd
       Address 10.0.8.12
       Port 80
       HAport 9090
       Priority 3
     End
     BackEnd
       Address 10.0.8.13
       Port 80
       HAport 9090
       Priority 3
     End

     Session
       Type COOKIE
       ID "lb"
       TTL 600
     End
   End

End
-----------------------------------

And the log from the point where I stopped the back-ends and then  
attempted another request:
Oct 31 11:17:09 localhost pound: BackEnd 10.0.8.11:9090 is dead (HA)
Oct 31 11:17:09 localhost pound: BackEnd 10.0.8.12:9090 is dead (HA)
Oct 31 11:17:09 localhost pound: BackEnd 10.0.8.13:9090 is dead (HA)

Oct 31 11:17:14 localhost pound: response error read from  
10.0.8.11:80: Connection reset by peer
Oct 31 11:17:26 localhost pound: no back-end "GET / HTTP/1.1" from  
x.x.x.x



On Oct 31, 2006, at 9:36 AM, Robert Segall wrote:
[...][...]
>>> - added support for emergency back-ends. You may now define one
>>> back-end
>>> to be used if and only if all other back-ends have
failed.[...][...]

Sorry to reply to my own message, but I changed the IP that the  
emergency back-end is using just to be sure and it doesn't change the  
behavior.

-Blake

On Oct 31, 2006, at 11:19 AM, Blake Barnett wrote:
[...]
>>> On Oct 23, 2006, at 12:52 AM, Robert Segall wrote:
>>>
>>>>
>>>> - added support for emergency back-ends. You may now define
one
>>>> back-end
>>>> to be used if and only if all other back-ends have failed.
>>>
>>> I can't seem to get this to work, I've got an apache process  
>>> setup on
>>> the same server as pound, listening on port 8686.  I've put an
>>> Emergency block with the server's IP and that port in the Service
>>> block.  When I take down all the back-ends I get this message: 
"The
>>> service is not available. Please try again later."
>>>
>>> And in the logs I see:
>>> Oct 30 12:56:24 localhost pound: no back-end "GET /home HTTP/1.1"
>>> from x.x.x.x
>>>
>>> I see nothing at all about the emergency back-end.  Is this a
bug?[...][...]