Return Receipt
                                                                           
   Your       [Pound Mailing List] poundctl bad flag                       
   document:                                                               
                                                                           
   was        Neil R Taylor/UK/IBM                                         
   received                                                                
   by:                                                                     
                                                                           
   at:        06/02/2007 15:30:54                                          
                                                                           

On Tue, 2007-02-06 at 13:10 +0000, Anthony Underwood wrote:
> Hi All,
> 
>  
> 
> I am trying to use poundctl to turn off one of the backend servers on
> the global services. However when I use -1 to specify the global
> service, poundctl returns and error of "bad flag".
> 
>  
> 
> How should I specify global services with poundctl?

It seems to be a bug - we'll fix it in the next release. Thanks for
pointing this out.
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

On Tue, 2007-02-06 at 13:55 +0100, Francisco Ruiz wrote:
> Hello,
> 
> I'm new with Pound, so I'm looking for some clue for a concrete problem.
> 
> We are using the session control based on cookies, and whenever a 
> backend dies all the sessions assigned to it are removed, so if the 
> client tries to access again the site it is redirected to any of the 
> alive backends inmediatly. Since it has his session open on the dead 
> backend the user should close it browser and open it again in order a 
> new session cookie to be created, but pound just redirect it and the 
> application does not work correctly.
> 
> What I'm looking for is for something like a "Zombie" directive in the 
> Session section.  If this directive is defined, the sessions should not 
> be removed when the backend dies, instead of this pound should send a 
> redirect to a new page (defined in the directive).  The zombie sessions 
> should be removed when their TTL is reached.
> 
> 
> For example:
>  
>   Session
>     Type COOKIE
>     TTL 7200
>     ID "ASPSESSIONID.*"
>     Zombie "http://server/error.html"
>   End
> 
> or
> 
>   Session
>     Type COOKIE
>     TTL 7200
>     ID "ASPSESSIONID.*"
>     Zombie "http://server/relogin.html"
>   End
> 
> 
> Thanks in advance. Regards
> 
> Francisco Ruiz

These really are two separate issues.

1. Keeping sessions for a dead back-end: why would you want to do that?
Once a server is dead, in all likelihood the sessions are gone as well,
so there is no advantage to it.

2. Showing a "special" page: you have two possibilities: either use the
custom error pages to return it in Pound, or have your application
redirect to a special page if the request contains an invalid session
key (which is good practise anyway).
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Robert Segall escribió:

  On Tue, 2007-02-06 at 13:55 +0100, Francisco Ruiz wrote:
  
  
    Hello,

I'm new with Pound, so I'm looking for some clue for a concrete problem.

We are using the session control based on cookies, and whenever a 
backend dies all the sessions assigned to it are removed, so if the 
client tries to access again the site it is redirected to any of the 
alive backends inmediatly. Since it has his session open on the dead 
backend the user should close it browser and open it again in order a 
new session cookie to be created, but pound just redirect it and the 
application does not work correctly.

What I'm looking for is for something like a "Zombie" directive in the 
Session section.  If this directive is defined, the sessions should not 
be removed when the backend dies, instead of this pound should send a 
redirect to a new page (defined in the directive).  The zombie sessions 
should be removed when their TTL is reached.


For example:
 
  Session
    Type COOKIE
    TTL 7200
    ID "ASPSESSIONID.*"
    Zombie "http://server/error.html"
  End

or

  Session
    Type COOKIE
    TTL 7200
    ID "ASPSESSIONID.*"
    Zombie "http://server/relogin.html"
  End


Thanks in advance. Regards

Francisco Ruiz
    
  
  
These really are two separate issues.

1. Keeping sessions for a dead back-end: why would you want to do that?
Once a server is dead, in all likelihood the sessions are gone as well,
so there is no advantage to it.
  

That's true, but the client's doesn't know that the backend is gone and
try to access again with the same session cookie, pound has forgotten
the session associated to this cookie and simply create a new session
assigned to a new backend. When the application receive the request it
doesn't know the sessions and fails to give a correct answer.

  
2. Showing a "special" page: you have two possibilities: either use the
custom error pages to return it in Pound, or have your application
redirect to a special page if the request contains an invalid session
key (which is good practise anyway).
  

Your are right, my application could redirect to a special page if the
request contains an invalid session, but it was not done in the
original design and now is pretty hard to change all, so I was looking
for this kind of support inside Pound as I thought it could be useful
in many cases, no just for me.

Regards,

Francisco Ruiz

Francisco Ruiz wrote:

>     Hello,

Hello,

> Since it has his session open on the dead 
> backend the user should close it browser and open it again in order a 
> new session cookie to be created, but pound just redirect it and the 
> application does not work correctly.

Hm, why don't you improve the session handling in your application? If 
the user visits your website with an invalid session cookie, he should 
be redirected to an authentication page to log in again. The lack of 
validating session cookies _can_ be fixed by the used load balancer, but 
this only a workaround in my eyes :-)

Regards,

Falk

Hello Falk,


Falk Brockerhoff - smartTERRA GmbH escribió:

> Hm, why don't you improve the session handling in your application? If 
> the user visits your website with an invalid session cookie, he should 
> be redirected to an authentication page to log in again. The lack of 
> validating session cookies _can_ be fixed by the used load balancer, 
> but this only a workaround in my eyes :-) 
Sure, but that's not easy when you have serveral applications that 
does'nt make it right, and it's not easy to change them cleanly.  So 
this feature could be very useful in this situations.

Regards,

Francisco

There's no real way for Pound to know if an expired session is expired, or if
it's a new session.  For that matter, you will still have problems if you
reboot the application server, because the application server will clear the
sessions out of memory, and you'll have stale cookies around.  Pound has no way
to check that.  And to add to that, sometimes URL variables are used to pass
the session key as well, in a manner Pound won't know.  (J2EE uses JSESSIONID,
coldfusion uses CFID/CFTOKEN, ASP uses sessionID I think)  It's possible a
session ID could be passed via URL variables and Pound wouldn't know.

In our applications we check for such things in our Application.cfm
(coldfusion's version of global.asa or similar constructs).  Every page is
checked for valid authentication and session information, and if it isn't
present it shows a login screen.  The check itself only adds about 5ms to each
page load.

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

> -----Original Message-----
> From: Francisco Ruiz [mailto:fjruiz(at)hac.juntaex.es]
> Sent: Thursday, February 08, 2007 4:01 AM
> To: pound(at)apsis.ch
> Subject: Re: [Pound Mailing List] Sessions management
> 
> Hello Falk,
> 
> 
> Falk Brockerhoff - smartTERRA GmbH escribió:
> 
> > Hm, why don't you improve the session handling in your application? If
> > the user visits your website with an invalid session cookie, he should
> > be redirected to an authentication page to log in again. The lack of
> > validating session cookies _can_ be fixed by the used load balancer,
> > but this only a workaround in my eyes :-)
> Sure, but that's not easy when you have serveral applications that
> does'nt make it right, and it's not easy to change them cleanly.  So
> this feature could be very useful in this situations.
> 
> Regards,
> 
> Francisco
> 
> --
> 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/2007/2007-
> 02/1170775854000/1170925233000

We ran into this kind of problem (though on the end, not beginning).  
The carat '^' should bind your regex to the beginning of the URL,  
just like '$' binds to the end.

URL "^\/(photos|movies)\/.*"

Regards,
-Nathan / PBwiki

On Feb 11, 2007, at 4:27 PM, Mark Karp wrote:

> In my configuration I am using something that looks like:
>
> URL "\/(photos|movies)\/.*"
>
> Which will send someone going to: www.website.com/photos/ or  
> www.website.com/movies/ to Server A, and I then have a catchall  
> that sends everything else to Server B...
>
> It works, except that someone entering in: www.website.com/some- 
> nonsense/photos/ also gets sent to Server A.
>
> Shouldn't this only be the case if I had a wildcard at the  
> beginning (something like: URL ".*\/(photos|movies)\/.*")?
>
> Is there something I am missing? Does anyone have any ideas on how  
> I can fix this behavior?
>
> MK...
>
>
> -- 
> 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/ 
> 2007/2007-02/1171240050000

Mark Karp napisał(a):
> In my configuration I am using something that looks like:
> 
> URL "\/(photos|movies)\/.*"
> 
> Which will send someone going to: www.website.com/photos/ or  
> www.website.com/movies/ to Server A, and I then have a catchall that  
> sends everything else to Server B...
> 
> It works, except that someone entering in: www.website.com/some- 
> nonsense/photos/ also gets sent to Server A.
> 
> Shouldn't this only be the case if I had a wildcard at the beginning  
> (something like: URL ".*\/(photos|movies)\/.*")?
> 
> Is there something I am missing? Does anyone have any ideas on how I  
> can fix this behavior?

Of course - you need to indicate "start of line" - a "^" character.
URL "^/(photos|movies)/.*" will catch only these URL's which begin
with the /photos or /movies. You may also use "$" character in order
to indicate "end of line", so: "^/$" will catch only pure "/" URL.

regards;
AdamLis;

Robert,

these might be silly questions , but which Libraries are you referring 
to?  And how do I find out?

Robert Segall wrote:
> Given the number of complaints we have seen I'd like to have an informal
> poll (pun not intentional) for the performance problem. This is
> addressed to everybody, regardless of having a performance problem or
> not. Please mail me directly the following information and I'll
> summarise to the list.
>
> Pound server:
>   OS and version
>   DNS type and version
>   Pound version
>   RootJail Y/N?
>   Libraries used and versions
>
> Back-end:
>   OS and version
>   Web server and version
>
> File tested: size (at least 200K, larger if possible).
>
> time wget <back-end> - repeated 3 time one right after the other
> time wget <pound> - repeated 3 times one right after the other
>   (replace wget with curl or whatever you have available)
>
> the 6 relevant lines from the back-end log
> the 3 relevant lines from the Pound log
>
> Make sure Pound uses the back-end you tested directly!
>
> I repeat: please do NOT post your results to the list but mail them
> directly to me.
>
> Many thanks to everybody in advance.
>   

On Fri, 2007-02-16 at 12:12 -0500, Albert wrote:
> Robert,
> 
> these might be silly questions , but which Libraries are you referring 
> to?  And how do I find out?

It means the libraries Pound was linked against, such as OpenSSL. Each
system is a bit different; on Linux, *BSD and some Solaris versions you
could try:

	ldd pound

(where 'pound' is your binary) to see the list. If your system supports
no such command you can just look at the installed packages (usually
in /usr/lib). The really important ones are libssl, libcrypto and
optionally - if you use them - libpcre, libpcreposix and libtcmalloc (or
libhoard).
-- 
Robert Segall
Apsis GmbH
Postfach, Uetikon am See, CH-8707
Tel: +41-44-920 4904

Robert Klikics schrieb:

> is there or will there be a kind of session-fallback?

AFAIK no. But what's about using 'Type IP'? So you are independent of
the used application and the users are identified by their client ip
address.

Regards,

Falk

Falk Brockerhoff schrieb:
> AFAIK no. But what's about using 'Type IP'? So you are independent of
> the used application and the users are identified by their client ip
> address.
>   

Well, we (everybody at my company) are are using our own application the 
whole day with massive requests and have alle the same IP via NAT (~300 
people).
If I change to type 'IP' the load is extremely on high on exactly one 
machine - and thats always the one on which is serving us ...

> Regards,
>
> Falk
>
>   
Regards,
Robert

This basically means the connection was closed by the client before 
pound was able to send the info back.  Did you try running your test by 
calling pound, instead of backend?

"Connection timed out" message is caused by a timeout on the read by 
pound from client.  You can increase "Client" value in the pound.cfg

Dennis Jacobfeuerborn wrote:
> Hi,
> I'm running pound 2.2.5 on a debian machine I see sporadic errors in 
> the logfile like this:
>
> Feb 27 22:34:35 localhost pound: error flush headers to 82.83.69.159: 
> Connection reset by peer
> Feb 27 22:38:17 localhost pound: error copy chunk cont: Connection 
> reset by peer
> Feb 27 22:42:16 localhost pound: error flush headers to 
> 213.139.142.142: Connection reset by peer
> Feb 27 22:45:16 localhost pound: error copy server cont: Connection 
> reset by peer
> Feb 27 22:45:33 localhost pound: error read from 87.165.223.40: 
> Connection reset by peer
> Feb 27 22:48:45 localhost pound: error copy server cont: Connection 
> reset by peer
> Feb 27 22:51:55 localhost pound: error copy server cont: Connection 
> reset by peer
> Feb 27 22:53:28 localhost pound: error copy server cont: Connection 
> reset by peer
> Feb 27 22:53:43 localhost pound: error copy server cont: Connection 
> reset by peer
> Feb 27 22:54:26 localhost pound: error read from 84.56.116.218: 
> Connection timed out
>
> The real problem are the "connection reset by peer" errors as they 
> result in an "internal server error" message on the client. The setup 
> is fairly trivial with a simple HTTP listener that forwards request to 
> a single backend server. I've written a little test script that runs 
> on the pound server and repeatedly retrieves pages from the backend 
> and that works flawlessly so it looks like this could be a bug in 
> pound. What would be the best way to diagnose this problem further?
>
> Regards,
>   Dennis
>

Albert wrote:
> This basically means the connection was closed by the client before 
> pound was able to send the info back.  Did you try running your test by 
> calling pound, instead of backend?
> 
> "Connection timed out" message is caused by a timeout on the read by 
> pound from client.  You can increase "Client" value in the pound.cfg

I set that to 90 seconds already. The thing I don't understand here is what 
does kind of information does pound read from the client and why would that 
take so long? Shouldn't pound just receive the initial request and then 
spend most of its time writing the data it receives from the backend to the 
client?

Regards,
   Dennis

Dennis Jacobfeuerborn wrote:
> I set that to 90 seconds already. The thing I don't understand here is 
> what does kind of information does pound read from the client and why 
> would that take so long? Shouldn't pound just receive the initial 
> request and then spend most of its time writing the data it receives 
> from the backend to the client?
>
True, but do you know what the client is actually doing?  Maybe client 
just connected to you and is not sending the request.

Albert wrote:
> 
> 
> Dennis Jacobfeuerborn wrote:
>> I set that to 90 seconds already. The thing I don't understand here is 
>> what does kind of information does pound read from the client and why 
>> would that take so long? Shouldn't pound just receive the initial 
>> request and then spend most of its time writing the data it receives 
>> from the backend to the client?
>>
> True, but do you know what the client is actually doing?  Maybe client 
> just connected to you and is not sending the request.

These are not just clients "out there". I simply hit the reload button in 
the browser and while most of the time things are fine every minute or so I 
just get the "internal server error" message. As I already mentioned 
contacting the backend directly works fine so I don't see how it can be the 
clients fault if it works just fine once you take pound out of the loop?

Regards,
   Dennis

Part of the difficulty here is that you are also taking the server side DNS
systems out of the loop as well as pound.  This and other similar effects
can cause confusing diagnostics.

Tracing the client and server side is important here.  For instance, we have
observed some clients that are ill-behaved in terms of actually sending an
entire request.  Without the last byte some systems time out.  I don't say
that is your problem, but that is an example of a problem that can only
really be solved using traces.

On 2/28/07 2:06 PM, "Dennis Jacobfeuerborn" <d.jacobfeuerborn(at)conversis.de>
wrote:

>> True, but do you know what the client is actually doing?  Maybe client
>> just connected to you and is not sending the request.
> 
> These are not just clients "out there". I simply hit the reload button in
> the browser and while most of the time things are fine every minute or so I
> just get the "internal server error" message. As I already mentioned
> contacting the backend directly works fine so I don't see how it can be the
> clients fault if it works just fine once you take pound out of the loop?
> 
> Regards,
>    Dennis

Ted Dunning wrote:
> Part of the difficulty here is that you are also taking the server side DNS
> systems out of the loop as well as pound.  This and other similar effects
> can cause confusing diagnostics.
> 
> Tracing the client and server side is important here.  For instance, we have
> observed some clients that are ill-behaved in terms of actually sending an
> entire request.  Without the last byte some systems time out.  I don't say
> that is your problem, but that is an example of a problem that can only
> really be solved using traces.

If the client was ill-behaved and apache manages to to send a correct 
response shouldn't pound be able to accomplish this too? I'd be perfectly 
happy to apply patches to get better information for the debug log to hunt 
this down but I would need assistance for that as I'm not familiar with the 
pound codebase. A dump of the data received by the client so far (up until 
the "timeout") and maybe the state of some important variables to the log 
would probably make it easier to determine where exactly the problem lies.

Regards,
   Dennis

On 2/28/07 9:21 PM, "Dennis Jacobfeuerborn" <d.jacobfeuerborn(at)conversis.de>
wrote:

> 
> If the client was ill-behaved and apache manages to to send a correct
> response shouldn't pound be able to accomplish this too?

Not necessarily.  And defect in DNS can cause problems due to the fact that
pound is doing something more complex than is done by a single server.

> I'd be perfectly 
> happy to apply patches to get better information for the debug log to hunt
> this down but I would need assistance for that as I'm not familiar with the
> pound 

You don't need patches.  Just some network sniffing software.  Tcpdump will
do, ethereal will do.

Ted Dunning wrote:
> 
> On 2/28/07 9:21 PM, "Dennis Jacobfeuerborn"
<d.jacobfeuerborn(at)conversis.de>
> wrote:
> 
>> If the client was ill-behaved and apache manages to to send a correct
>> response shouldn't pound be able to accomplish this too?
> 
> Not necessarily.  And defect in DNS can cause problems due to the fact that
> pound is doing something more complex than is done by a single server.
> 
>> I'd be perfectly 
>> happy to apply patches to get better information for the debug log to hunt
>> this down but I would need assistance for that as I'm not familiar with the
>> pound 
> 
> You don't need patches.

They help though. The logging isn't very verbose for example I added code 
that outputs the IP of the client in case of "copy server cont" and "copy 
chunk cont" errors which makes the cross-referencing with other 
logfiles/tools much easier.

 > Just some network sniffing software.  Tcpdump will
> do, ethereal will do.

How would I go about that and what tcpdump options would be required? I now 
have a dump here done with "tcpdump -n -nn -w tcpdump.log port 80 or port 
443" and thanks to the logging change I can limit the contents to the 
communication between pound and the client. But what should I look for in 
that dump?

Regards,
   Dennis