DefaultSubscriptionRegistry loses track of subscribers in its cache [SPR-13555]

[spring-projects-issues]

Henrik Olsson opened SPR-13555 and commented

Sometimes when sending data to destinations with multiple subscribers not all of them receive the data.
This seems to happen after a large number of subscriptions has been done (tests were done with ~2000 subscribers on the same destination, related to DEFAULT_CACHE_LIMIT = 1024?).

From one of our test runs:
Session dn0zchmw subscribes to /api/en/events/9719 at start, always receives data.
Session v535qopd subscribes to /api/en/events/9719 after 2000 other sessions has subscribed to it, does not receive any data.

Looking up the session v535qopd in DefaultSubscriptionRegistry.subscriptionRegistry it exits and is mapped correctly:

[
  sessionId=v535qopd,
  subscriptions={
    /request-response-userv535qopd=[subscription(id=/user/request-response)],
    /error-userv535qopd=[subscription(id=/user/error)],
    /api/en/events/9719=[subscription(id=/api/en/events/9719)]
  }
]

However, looking up the destination /api/en/events/9719 in DefaultSubscriptionRegistry.accessCache does not return that session, only the working one:

/api/en/events/9719 = {dn0zchmw=[/api/en/events/9719]}

Removing the cache from DefaultSubscriptionRegistry to make findSubscriptionsInternal always fall back to doing a lookup in subscriptionRegistry seems to fix the issue.

---

Affects: 4.1.7, 4.2 GA

Backported to: 4.1.8

0 votes, 6 watchers

[spring-projects-issues]

Rossen Stoyanchev commented

Does session v535qopd receive messages at first and then they stop, or no messages at all for that destination after subscribing? I think there is a possibility for race condition when a destination is being added for the first time to the accessCache. Just trying to confirm if this could be the issue.

[spring-projects-issues]

Henrik Olsson commented

Yes, v535qopd never got any messages

[spring-projects-issues]

Rossen Stoyanchev commented

There is a fix ready for this (and the CI build is currently building 4.2.2 and 4.1.8 snapshots). It should fix the issue but if you could confirm with your test that would be great.

[spring-projects-issues]

Henrik Olsson commented

Unfortunately this doesn't seem to solve the issue. Tested using 4.2.2.BUILD-SNAPSHOT (4.2.2.BUILD-20151013.230208-91).

We'll look into creating an isolated testcase for the issue that we can share.

[spring-projects-issues]

Rossen Stoyanchev commented

Strange because I added a failing test and fixed it. It was also very clear that the accessCache wasn't kept in sync with the updateCache for evicted items. At this point it would be great to see an isolated test case. You can try setting the cacheLimit to 1 as I did in the test.

[spring-projects-issues]

Henrik Olsson commented

Sorry, it seems you're right. After creating an isolated test case i'm unable to reproduce it when using the latest SNAPSHOT. Seems like the test run from earlier today had the wrong spring version in it's classpath despite switching to a SNAPSHOT in the pom. Thanks for the quick fix!

[spring-projects-issues]

Rossen Stoyanchev commented

No worries, thanks for reporting the issue and testing the fix!