Universal Messaging 10.3 | Developer Guide | Enterprise APIs | Enterprise Developer's Guide for C++ | Message Queues | Finding a Queue
 
Finding a Queue
In order to find a queue, first of all the queue must be created. This can be achieved through the Universal Messaging Enterprise Manager, or programmatically (see Creating a Queue). First of all you must create your nSession object, which is your effectively your logical and physical connection to a Universal Messaging Realm. This is achieved by using the correct RNAME for your Universal Messaging Realm when constructing the nSessionAttributes object, as shown below:
std::string[] RNAME={"nsp://127.0.0.1:9000"};
nSessionAttributes *nsa=new nSessionAttributes(RNAME);
nSession *mySession = nSessionFactory->create(nsa);
mySession->init();
Once the nSession->init() method is successfully called, your connection to the realm will be established.
Using the nSession objects instance 'mySession', we can then try to find the queue object. Queues have an associated set of attributes, that define their behavior within the Universal Messaging Realm Server. As well as the name of the queue, the attributes determine the availability of the events published to a queue to any consumers wishing to consume them.
To find a queue previously created, we do the following:
nChannelAttributes *cattrib = new nChannelAttributes();
cattrib->setName("myqueue");
nQueue *myQueue = mySession->findQueue(cattrib);
Now we have a reference to a Universal Messaging queue within the realm.
Behavior if a queue has been deleted
Whenever a store (i.e. a channel or a queue) is deleted, all clients will be advised that the store has changed, and will mark the object as invalidated, thus stopping any further use of the object. At this point all producing and consuming to the server will have ceased. If the store has been recreated, you must go and find the store and create any durable subscriptions as if it was a fresh start.
See the section Deleting Channels and Queues in the Administration Guide for further details.
Note:
Since editing a store involves deleting the old store and creating a new store, the behavior described for deleting a store applies also to editing a store.
There will be exceptions raised whenever an invalidated object is used to attempt to undertake any function, since the public signatures of methods have not changed, and thus not all methods will raise an exception but most will.
Any asynchronous consumer will receive a special event upon deletion of a store. The event will have an event identifier of -2, an event tag containing "QUEUE DELETED" and an event data component equal to "The queue has been deleted".