Slow subscriber causing solace spool quota blow up

Hi @Rajesh, welcome to the wonderful world of Solace!

TL;DR: I don’t think you want to persist messages, but you are. Make sure you have your subscribers set up to receive DIRECT messages, they aren’t reading from queues or Topic Endpoints.

I think the most important thing to get clear here is the interaction of DIRECT messages, PERSISTENT messages, topics and queues. So my first question is: are you using JMS?
There is some confusing terminology to get to grips with. A DIRECT message is stored in memory - it doesn’t survive a broker restart. Note I said DIRECT message - not subscriber. From your description it seems like you don’t want subscribers that have closed getting current messages later when they re-connect - in other words you don’t want the messages to be queued (persisted). This is what DIRECT messages are meant for. If messages are being queued and quota exceeded, then it’s clear your incoming messages are being attracted to a persistent endpoint somewhere - this is what is causing the problem.

So, are your applications getting messages from a topic or a queue? This is where the distinction between JMS and everything else becomes important. JMS has the idea of a durable subscriber. This creates a special type of persistent endpoint called a Topic Endpoint. When the subscriber is off line, the Topic Endpoint will persist messages on that topic. If you aren’t using JMS, then you must have a queue endpoint somewhere that is subscribed to your topics.

If you don’t use a JMS durable subscriber or a queue, you will get exactly the behaviour you want with DIRECT messages. Pubsub+ keeps a track of all subscribers, and when it detects a slow subscriber it will keep a track of it. If Pubsub+ starts to run out of memory allocated to a client (see Message Delivery Resources), Pubsub+ will start to discard messages for that particular client. We’re nice and set a flag for you in subsequent messages (see Message Discard Notification) If things get worse and Pubsub+ starts to run out of memory because there are many slow subscribers, Pubsub+ will start to disconnect the slow subscribers (see Egress Buffer Management).

In summary: I don’t think you want to persist messages, but you are. Make sure you have your subscribers set up to receive DIRECT messages, they aren’t reading from queues or Topic Endpoints.