Robert,

Well I think my last email has something to do with this message:

"MONITOR: worker exited on signal 11, restarting..."


Why does this message happen?
And when it happens the state of the backend is lost?

Regards,
Sergio Freire





-----Original Message-----
From: Sergio Freire [mailto:sergio-s-freire(at)ptinovacao.pt] 
Sent: Thursday, March 09, 2006 12:13 PM
To: 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?


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&iid=resize 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&iid=resize 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&iid=resize
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:[...]

Still here...
[...]
is[...]
HAport[...]

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.
[...]
to[...]

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.[...]

On Thu, 2006-03-09 at 12:28 +0000, Sergio Freire wrote:[...]

That is a "bad thing" (TM): your worker process got a segmentation
violation and exited. The monitor process starts another worker, but all
the state information is kept in the worker, and is thus lost (this
includes sessions and back-end state).

I would be very interested in finding out more about the conditions
under which it happens, as this is a certain bug and needs fixing. I
know it's not easy to track down, but I would really appreciate if you
could make the effort.[...]

Robert,
I have installed version 2.0.2 few minutes ago and the problem vanished.
Maybe there was a fix between 2.0 and 2.0.2, I don't know but you
probably do :)
Let's see how this does and the next hours.
Regards,
Sergio Freire

-----Original Message-----
From: Robert Segall [mailto:roseg(at)apsis.ch] 
Sent: Thursday, March 09, 2006 12:58 PM
To: pound(at)apsis.ch
Subject: Re: [Pound Mailing List] monitor thread problem?

On Thu, 2006-03-09 at 12:28 +0000, Sergio Freire wrote:[...]

That is a "bad thing" (TM): your worker process got a segmentation
violation and exited. The monitor process starts another worker, but all
the state information is kept in the worker, and is thus lost (this
includes sessions and back-end state).

I would be very interested in finding out more about the conditions
under which it happens, as this is a certain bug and needs fixing. I
know it's not easy to track down, but I would really appreciate if you
could make the effort.[...]