About using the upstream address as the picker object key and version in lrucache

[redynasc]

in upstream.lua
set_directly(api_ctx, up_conf.type .. "#upstream_" .. tostring(up_conf),tostring(up_conf), up_conf)

Is it possible that the addresses of the new upstream and the old upstream are the same, and if so, would it cause serious problems? will use a dirty picker

[tzssangglass]

tostring(up_conf) will get the memory address of the table up_conf. The new and old up_conf are two tables and the memory addresses will not be the same.

[spacewander]

It seems we need to use the upstream ID instead of type as the prefix?

[spacewander]

key => upstream ID + source
version => tostring(up_conf)

[tzssangglass]

I remember that upstream IDs conflict with discovery?

[tokers]

when upstream changed in etcd, upstream changed in worker process like this: upstream-A-v1 -> upstream-A-v2 -> upstream-A-v3 -> upstream-A-v4 upstream-B-v1 -> upstream-B-v2 -> upstream-B-v3 -> upstream-B-v4 v1 ,v2, v3 have been GC，Is it possible that upstream-B-v4 address use the upstream-A-v1 address?

That's might be possible but what's the influence? Old v1, v2 and v3 objects are GCed, it means that we never use it, in such a case, a new object reuses the old object's address looks fine?

[redynasc]

when upstream-B-v4 address use the upstream-A-v1 address, if picker's lrucache like this:
upstream-A-v1 address ---> upstream-A-v1 picker
the traffic proxied to upstream-B-v4,will use the upstream-A-v1 picker ,this will occur error

[redynasc]

run test commad:
for i in {1..5}; do /usr/local/openresty/bin/resty addr-reuse-test.txt; done
output:
_
1001 addr reuse at table: 0x7f3198711790
1000 addr reuse at table: 0x7f6768da1470
1001 addr reuse at table: 0x7f9068879ed0
1001 addr reuse at table: 0x7fd0d67f7e88
1001 addr reuse at table: 0x7fe30b4e9658
_
It seems that it is easy to reuse addr

addr-reuse-test.txt