Delete All the Messages on a Queue Using Legacy SEMP

Zahra Tabar · March 2021

For deleting all the messages on a queue you can use the following legacy SEMP command:

admin message-spool message-vpn <vpn-name> delete-messages queue <queue-name>
SEMP Request:
<rpc semp-version="soltr/9_6VMR">                     
    <admin>
        <message-spool>
            <vpn-name>vpn-name</vpn-name>
            <delete-messages>
                <queue-name>queue-name</queue-name>
            </delete-messages>
        </message-spool>
    </admin>
</rpc>

SasikumarSP · March 2021

Can we do the same with SEMP v2?

nram · March 2021

Hello @SasikumarSP , I don't believe this would be possible with SEMPv2. You will need to get list of msg-ids with GET http://<solace-url>/SEMP/v2/action/msgVpns/<vpn>/queues/<queue>/msgs and loop over each msg to delete with PUT http://<solace-url>/SEMP/v2/action/msgVpns/<vpn>/queues/<queue>/msgs/<msgid>/delete
Pl check SEMP Action reference for details : https://docs.solace.com/API-Developer-Online-Ref-Documentation/swagger-ui/action/index.html#/all/doMsgVpnQueueMsgDelete

SasikumarSP · March 2021

Okay. Thanks, Ramesh!
Is there any plan to decommission/EOVS for SEMPv1?

TomF · March 2021

Hi @SasikumarSP, there are no plans to discontinue SEMP v1 at the moment. We are implementing SEMP v2 incrementally, but until that's complete, SEMP v1 won't be going anywhere. Once SEMP v2 is complete I imagine we'll start decommissioning SEMP v1, but there are no dates yet.

amackenzie · March 2021

Hello @SasikumarSP I am with the product management team at Solace. SEMP is an area I cover. As @TomF mentions, we have no intention of deprecating SEMPv1. We continue to work on SEMPv2 and its UI PubSub+ Manager incrementally and with each release of the broker, we release new features towards this goal. But even when we get to a point where SEMPv2 is able to cover the use cases SEMPv1 provides, there are many commercial and customer production applications "in the wild" and we have no desire to break them. You can, with confidence, continue to use SEMPv1, especially in this case where SEMPv2 does not yet contain the feature you need from SEMPv1.