SimpleBrokerMessageHandler SubscriptionRegistry DestinationCache doesn't honour unique subscriptionId [SPR-15414]

[spring-projects-issues]

Stephen Morrison opened SPR-15414 and commented

Hi folks,
When creating a subscription to a destination/topic in Spring WebSockets & STOMP I'm seeing a discrepancy in how the SessionSubscriptionRegistry and DestinationCache (within DefaultSubscriptionRegistry.addSubscriptionInternal) stores the subscription when there are multiple subscriptions (with the same subscriptionId) to the same destination for the same session.

The SessionSubscriptionRegistry.addSubscription stores the subscriptions into a Set therefore not allowing duplicate subscriptions with same subscriptionId to be stored for each session. This is desired functionality as I would prefer the client can subscribe to a destination multiple times and not have to worry about subscribing and unsubscribing before re-subscribing to the same destination. My use case is a chat window modal window.

However the DestinationCache.updateAfterNewSubscription stores the subscriptions into a Map of LinkedMultiValueMap keyed off the destination then the sessionId. Therefore we get a bunch of entries with the same sessionId/subId pairing in the LinkedMultiValueMap. I think this is a bug as the SessionSubscriptionRegistry and DestinationCache should contain the same number of unique subscriptions per session and destination.

The result of this issue is we see multiple messages sent via SimpleBrokerMessageHandler.sendMessageToSubscribers as this looks into the cache which contains a bunch of duplicate subscriptionIds.

On another note is there any way I could customise the SubscriptionRegistry or the DestinationCache for the SimpleBrokerMessageHandler so I may provide my own implementation of these classes?

Thanks,
Stephen

---

Affects: 4.3.7

Issue Links:

• Cannot receive message sometimes with SimpleBrokerMessageHandler [SPR-15282] #19848 Cannot receive message sometimes with SimpleBrokerMessageHandler

[spring-projects-issues]

Stephen Morrison commented

Removing what I thought was a workaround from description.

[spring-projects-issues]

Rossen Stoyanchev commented

This should be resolved now with #20102.