Re: Stick-table peers expiration time

[Willy Tarreau]

Hi Igor,

On Fri, Feb 19, 2016 at 06:48:13PM +1100, Igor Cicimov wrote:
> Hi Willy,
> 
> On 04/02/2016 3:11 PM, "Willy Tarreau"  wrote:
> >
> > On Wed, Feb 03, 2016 at 11:05:03AM +1100, Igor Cicimov wrote:
> > > Any comments on this? Shouldn't the expiration time get replicated upon
> > > restart or just the keys? Obviously the entry in the first server stick
> > > table will expire much sooner than the one on the restarted server
> meaning
> > > the first one might choose different backend for the same session id.
> >
> > I could be wrong (need to check with Emeric who started documenting the
> > peers protocol) but from what I remember, the expiration times are *not*
> > passed over the protocol, and each peer creates the entry with its local
> > expiration timer. The reason is simple, you push updates when you see
> > them, so these ones are supposed to be fresh when you receive them.
> > However maybe an exception should indeed be made during the first learning
> > phase so that timers could be passed along with contents (and bounded by
> > the table's expiration value). I don't know if that would be possible
> > without changing the protocol again though :-/
> 
> Do you think there is a chance for this change to happen any time soon? And
> is there a way of maybe creating an enhancement request?

I discussed it with Emeric who understood the problem but unfortunately it
would require a protocol change. We'll need to study how to do it without
having to modify too much of the protocol, but that will make it incompatible
again with the current one :-/ If we can adapt to the other node's version
maybe we can adjust the message format but I believe that the other side's
version is not checked before syncing.

Willy

Re: Stick-table peers expiration time

[Igor Cicimov]

Hi Willy,

On 04/02/2016 3:11 PM, "Willy Tarreau"  wrote:
>
> On Wed, Feb 03, 2016 at 11:05:03AM +1100, Igor Cicimov wrote:
> > Any comments on this? Shouldn't the expiration time get replicated upon
> > restart or just the keys? Obviously the entry in the first server stick
> > table will expire much sooner than the one on the restarted server
meaning
> > the first one might choose different backend for the same session id.
>
> I could be wrong (need to check with Emeric who started documenting the
> peers protocol) but from what I remember, the expiration times are *not*
> passed over the protocol, and each peer creates the entry with its local
> expiration timer. The reason is simple, you push updates when you see
> them, so these ones are supposed to be fresh when you receive them.
> However maybe an exception should indeed be made during the first learning
> phase so that timers could be passed along with contents (and bounded by
> the table's expiration value). I don't know if that would be possible
> without changing the protocol again though :-/

Do you think there is a chance for this change to happen any time soon? And
is there a way of maybe creating an enhancement request?

>
> Willy
>
Thanks,
Igor

Re: Stick-table peers expiration time

[Willy Tarreau]

On Wed, Feb 03, 2016 at 11:05:03AM +1100, Igor Cicimov wrote:
> Any comments on this? Shouldn't the expiration time get replicated upon
> restart or just the keys? Obviously the entry in the first server stick
> table will expire much sooner than the one on the restarted server meaning
> the first one might choose different backend for the same session id.

I could be wrong (need to check with Emeric who started documenting the
peers protocol) but from what I remember, the expiration times are *not*
passed over the protocol, and each peer creates the entry with its local
expiration timer. The reason is simple, you push updates when you see
them, so these ones are supposed to be fresh when you receive them.
However maybe an exception should indeed be made during the first learning
phase so that timers could be passed along with contents (and bounded by
the table's expiration value). I don't know if that would be possible
without changing the protocol again though :-/

Willy

Re: Stick-table peers expiration time

[Igor Cicimov]

Any comments on this? Shouldn't the expiration time get replicated upon
restart or just the keys? Obviously the entry in the first server stick
table will expire much sooner than the one on the restarted server meaning
the first one might choose different backend for the same session id.

Thanks,
Igor

On Mon, Feb 1, 2016 at 11:07 AM, Igor Cicimov <
ig...@encompasscorporation.com> wrote:

> Hi all,
>
> I have the following entry in a stick-table:
>
> 0x87bf54: key=09643F891F0C6F7BE467E619952E327E use=0 exp=1938168
> server_id=1
>
> and on the peer after doing a restart:
>
> 0x806934: key=09643F891F0C6F7BE467E619952E327E use=0 exp=4795722
> server_id=1
>
> can see the same entry with different expiration time. I thought that upon
> restart the server syncs the stick-table from the active peer including the
> expiration time. Shouldn't this be in sync between the peers?
>
> My stick-table definition:
>
> stick-table type string len 32 size 30k expire 80m peers LB
> stick store-response res.cook(JSESSIONID)
> stick on req.cook(JSESSIONID)
> tcp-request content track-sc0 req.cook(JSESSIONID)
>
> Thanks,
> Igor
>
>
>


-- 
Igor Cicimov | DevOps


p. +61 (0) 433 078 728
e. ig...@encompasscorporation.com 
w*.* encompasscorporation.com
a. Level 4, 65 York Street, Sydney 2000

Stick-table peers expiration time

[Igor Cicimov]

Hi all,

I have the following entry in a stick-table:

0x87bf54: key=09643F891F0C6F7BE467E619952E327E use=0 exp=1938168 server_id=1

and on the peer after doing a restart:

0x806934: key=09643F891F0C6F7BE467E619952E327E use=0 exp=4795722 server_id=1

can see the same entry with different expiration time. I thought that upon
restart the server syncs the stick-table from the active peer including the
expiration time. Shouldn't this be in sync between the peers?

My stick-table definition:

stick-table type string len 32 size 30k expire 80m peers LB
stick store-response res.cook(JSESSIONID)
stick on req.cook(JSESSIONID)
tcp-request content track-sc0 req.cook(JSESSIONID)

Thanks,
Igor