Yes, it is ok. But I would actually suggest that you strongly consider using SEMPv1 for this particular use case. As of the time of this writing, SEMPv1 performance still significantly exceeds SEMPv2, and if you’re pulling back information for 3k queues, that could take some significant time in SEMPv2. (note, there are performance enhancements being made, just not sure when they are ready). SEMPv2 is great for configuration, where you have the full RESTful verbs/methods to build objects. But just fetching data, especially for a large number of queues/objects, I’d suggest (at least looking at) SEMPv1. Just means that you have to parse XML instead. But is much faster.
Send a POST with the payload:
<rpc>
<show>
<queue>
<name>*</name>
<vpn-name>*</vpn-name>
<detail/>
<count/>
<num-elements>100</num-elements>
</queue>
</show>
</rpc>
to the broker management port with /SEMP as the URL path. It will return 100 elements on one “page”, and then at the end of the response will give you a “more cookie” for you to get the next page. Repeat until all done. Will be much faster than asking for 3,000 individual queues via SEMPv2.