Description
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