Michele, Thanks for your suggestion on the admin get solution. I did some testing to try it out and I have a few questions/observations that need clarification (sorry for long post):
1. This cb queue appears to be tied directly to a specific session (joe/1), so it follows that I must publish all of my messages in PTP mode using Joe/1 in the destination tag, correct? In other words, the messages I intend to run admin gets on MUST be sent PTP. Please clarify. 2. If I specify forceQueuing=true option when publishing messages, what happens to these messages if I publish them PRIOR to the creation of the destination client's cb queue? Xmlblaster doesn't throw an exception if I publish a message in this manner, but even after the cb queue is created and I perform an admin get, no messages are returned. Are the messages gone? It seems the cb queue must exist before messages can be published to it. 3. Can an admin get() perform XPATH queries on the key when requesting messages? 4. This is how I've managed to test this solution so far: I had a total of 3 clients: ClientQ - a client whose cb queue I'm going to be performing admin gets on; its dispatch manager is deactivated ClientP - a message publisher ClientG1 - a client who will be issuing the admin gets for ClientQ's cb queue ClientG2 - another client who will be issuing the admin gets for ClientQ's cb queue Sequence of events: A) ClientQ connects to xmlblaster as ClientQ/1. So that means its cb queue gets created here B) ClientP connects to xmlblaster and publishes a PTP message to ClientQ/1 with forceQueuing=true C) ClientG1 connects to xmlblaster and performs an admin get on the cb queue for ClientQ/1 with consumable=false D) ClientG2 connects to xmlblaster and performs an admin get on the cb queue for ClientQ/1 with consumable=false Also, if ClientQ were to disconnect from xmlblaster while ClientP/ClientG1/ClientG2 are still active, I noticed that ClientQ's cb queue doesn't get deleted. ClientP can continue to publish messages to ClientQ/1 and won't get any exceptions. Similarly, both ClientGs will continue to admin get() those cb queued messages just fine. Is it safe to say that ClientQ/1 only needs to log on initially so that its cb queue gets created, and that it can safely disconnect while other clients continue to publish/get from its cb queue? 5. In my testing, messages are deleted as soon as ClientG1/ClientG2 retrieves it (so this appears to solve my problem on preventing other Clients from "getting" the same message). If a client uses an admin get on a cb queue, is it guaranteed that the message will not be available to other clients performing admin gets on the same queue? I guess I'm trying to understand the difference between an admin get and a normal get/erase combination, and whether I can 100% rely on the admin get to ensure the same message isn't handled by more than one client. 6. Has there been any performance testing on routing/retrieving mass amount of messages in this manner? >Michele wrote: >Hi Joanne, >in the email I answered yesterday I forgot another possible solution to >your usecase: > >You could use an administrative get by querying the callback queue with >the 'consumable' flag set: > >1) Create a topic the normal way > >2)Connect in failsafe mode: for exampel as client joe with the session 1 >(joe/1). Then a callback queue is created for this session. > >2) Disactivate its dispatch manager to ensure no async delivery is >enabled by publishing an administrative message to the oid (this way >even if somebody connects with the same session id and makes a >subscription does not get anything delivered to him)
