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:
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.
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.
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!