House keeping for durable exclusive queues/DTEs having no consumer for a defined time

subhoatg

Hi,

We want to implement a housekeeping mechanism for our Solace system so that durable exclusive queues/DTEs having no consumer for a defined time are deleted.

We are thinking of the following approach.

We implement a poller which looks at all the Queues/DTEs and finds out all the exclusive Queues/DTEs

For each of them, the poller then checks if there are active consumers in them with the SEMP API `GET SEMP/v2/monitor/msgVpns/<VPN-NAME>/topicEndpoints/<DTE-NAME>/txFlows`. If there are none, then it starts the deletion counter and also notes the bindSuccessCount from the `GET SEMP/v2/monitor/msgVpns/<VPN-NAME>/topicEndpoints/<DTE-NAME>`.

For every subsequent poll, it checks if there are any active consumer added or the bindSuccessCount has changed. If yes, then it resets the counter. Or else, it increases the counter.

Once the counter exceeds the timelimit of the pre-defined time, it deletes the queue/dte.

We want to know if this approach looks fine or there are better ways to achieve the same. Kindly suggest.

marc

Hi @subhoatg,

With your approach I could see the possibility that you miss a consumer which binds and unbinds to an endpoint in between your checks. I would consider using the "bindRequestCount" metric on the endpoint instead. This number would have incremented if a bind request was made between your polls.

You can find it via this SEMP request under data .

http://localhost:8080/SEMP/v2/monitor/msgVpns/<YOUR_MSG_VPN>/queues/<YOUR_QUEUE>

Another option would be to do this in an asynchronous manner by parsing the syslog events that the broker puts out. There is a CLIENT_CLIENT_BIND_SUCCESS (and FAILURE) event that you could watch for.

Hope that helps!

marc

Hi @subhoatg,

With your approach I could see the possibility that you miss a consumer which binds and unbinds to an endpoint in between your checks. I would consider using the "bindRequestCount" metric on the endpoint instead. This number would have incremented if a bind request was made between your polls.

You can find it via this SEMP request under data .

http://localhost:8080/SEMP/v2/monitor/msgVpns/<YOUR_MSG_VPN>/queues/<YOUR_QUEUE>

Another option would be to do this in an asynchronous manner by parsing the syslog events that the broker puts out. There is a CLIENT_CLIENT_BIND_SUCCESS (and FAILURE) event that you could watch for.

Hope that helps!

subhoatg

Hi @marc ,

Thanks for your reply. My understanding was that both bindRequestcount and bindSuccessCount will increase in case of any consumer connects and disconnects between the polls.

marc

Hi @subhoatg,

Correct, wouldn't that give you what you want? If the count goes up then an app is using/trying to use that endpoint and you wouldn't want to delete it.