Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
spring-projects-issues opened this issue Oct 9, 2015 · 7 comments
Assignees
Labels
in: web status: backported type: bug
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Oct 9, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2015

Henrik Olsson commented

Yes, v535qopd never got any messages

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 13, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 14, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 14, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 14, 2015

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
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Oct 14, 2015

Rossen Stoyanchev commented

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

@spring-projects-issues spring-projects-issues added type: bug status: backported in: web labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 4.2.2 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web status: backported type: bug
Projects
None yet
Development

No branches or pull requests

2 participants