Files
nats-server/test
Ivan Kozlovic 25bd5ca352 [FIXED] Unsubscribe may not be propagated through a leaf node
There is a race between the time the processing of a subscription
and the init/send of subscriptions when accepting a leaf node
connection that may cause internally a subscription's subject
to be counted many times, which would then prevent the send of
an LS- when the subscription's interest goes away.

Imagine this sequence of events, each side represents a "thread"
of execution:
```
client readLoop                         leaf node readLoop
----------------------------------------------------------
recv SUB foo 1
sub added to account's sublist

                                         recv CONNECT
                                     auth, added to acc.

updateSmap
smap["foo"]++ -> 1
no LS+ because !allSubsSent

                                         init smap
                                    finds sub in acc sl
                                    smap["foo"]++ -> 2
                                        sends LS+ foo
                                    allSubsSent == true

recv UNSUB 1
updateSmap
smap["foo"]-- -> 1
no LS- because count != 0
----------------------------------------------------------
```
Equivalent result but with slightly diffent execution:
```
client readLoop                         leaf node readLoop
----------------------------------------------------------
recv SUB foo 1
sub added to account's sublist

                                         recv CONNECT
                                     auth, added to acc.

                                         init smap
                                    finds sub in acc sl
                                    smap["foo"]++ -> 1
                                        sends LS+ foo
                                    allSubsSent == true

updateSmap
smap["foo"]++ -> 2
no LS+ because count != 1

recv UNSUB 1
updateSmap
smap["foo"]-- -> 1
no LS- because count != 0
----------------------------------------------------------
```

The approach for the fix is delay the creation of the smap
until we actually initialize the map and send the subs on processing
of the CONNECT.
In the meantime, as soon as the LN connection is registered
and available in updateSmap, we check that smap is nil or
not. If nil, we do nothing.

In "init smap" we keep track of the subscriptions that have been
added to smap. This map will be short lived, just enough to
protect against races above.

In updateSmap, when smap is not nil, we need to checki, if we
are adding, that the subscription has not already been handled.
The tempory subscription map will be ultimately emptied/set to
nil with the use of a timer (if not emptied in place when
processing smap updates).

Signed-off-by: Ivan Kozlovic <ivan@synadia.com>
2020-06-05 10:07:15 -06:00
..
2020-05-29 17:56:45 -07:00
2018-01-15 15:27:18 -08:00
2020-06-01 13:30:34 -07:00
2019-05-10 15:11:30 -07:00
2020-02-19 13:19:08 -07:00
2020-05-28 13:41:02 -06:00
2020-03-31 10:29:06 -06:00
2019-12-12 11:58:24 -07:00
2020-06-01 18:00:13 -04:00
2020-05-29 17:56:45 -07:00
2020-06-01 18:00:13 -04:00
2018-03-15 22:31:07 -07:00
2019-07-28 07:10:37 -07:00
2020-05-20 11:14:39 -06:00
2020-05-29 17:56:45 -07:00
2019-08-26 09:34:17 -06:00
2020-01-10 12:01:59 -07:00
2020-06-01 18:00:13 -04:00
2020-05-25 06:58:23 -07:00
2020-05-29 17:56:45 -07:00