It would be nice if org.springframework.messaging.simp.broker.DefaultSubscriptionRegistry allowed to retrieve the number of currently active subscriptions. Sending that value periodically to a metrics aggregation system would allow to have alerts when the number of subscriptions becomes inconsistent with expectations.

Comment From: rstoyanchev

We have SessionSubscribeEvent and SessionUnsubcribeEvent that allow you to track this, and also the SimpUserRegistry bean that provides connected users, their sessions, and for each session the number of subscriptions. Something like this:

long total = registry.getUsers().stream()
        .flatMap(user -> user.getSessions().stream())
        .flatMap(session -> session.getSubscriptions().stream())
        .count();

Comment From: bgK

Thank you for your answer.

It seems to me the events cannot be used to reliably track the number of active subscriptions because clients may disconnect without sending unsubscribe messages first (and in my case I also want to send disconnect messages from the server when user authentication expires, which seemingly has the same limitation).

Regarding SimpUserRegistry, I was hoping for a way to obtain that information that does not allocate potentially large amounts of memory. Maybe that's just me being too cautious. I'll do it that way and see what happens during load tests.

Comment From: rstoyanchev

I'm not sure that's true actually. It's purpose is to report correctly the number of active users and subscriptions. If that's not the case it would be an issue, but it does detect disconnects and removes user sessions, which contain the subscriptions.

Also the registry is available for use any time. It does not need to be enabled.

Comment From: bgK

Regarding the events, I have added some logs in my project for testing: * The amount of subscriptions extracted from the user registry is periodically reported * The Subscription and Unsubscription events are logged

1. Subscriptions from user registry: 0 <= Initial state
2. Received SessionSubscribeEvent      <= A client subscribed to a topic
3. Subscriptions from user registry: 1 
                                       <= The connection with the client is broken because the client closed it without sending UNSUBSCRIBE nor DISCONNECT messages
4. Subscriptions from user registry: 0 <= SimpUserRegistry noticed the client is gone

In this example, the SessionSubscribeEvent and SessionUnsubscribeEvent are not balanced.

Regarding the user registry, sorry for not being precise, I was referring to the fact that DefaultSimpUserRegistry.getUsers, LocalSimpUser.getSessions and LocalSimpSession.getSubscriptions make copies of the collections they return. However it's probably good enough for my purposes.

Comment From: rstoyanchev

Okay, resolving for now. If the collection copy becomes too much of an issue, let us know.