[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [xmlblaster] ConsumableQueuePlugin

Hi Joanne,

Joanne wrote:
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.
No that is not correct:
The session joe/1 must be created, i.e. the client joe must log in on let's say its session 1 but this is just to force xmlBlaster to create a callback queue.

If you disactivate the dispatcher (point two of my previous email), then you can as session joe/1 subscribe to whatever you want. These messages end up in joe/1 callback queue.

So in fact it does not matter if the messages are published ptp to joe/1 or if joe/1 gets them via a subscription: both alternatives are valid.

The trick is that with administrative gets you can get entries of all callback- (and for instance history-) queues you want.

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.
If joe/1 has not logged in and you send to it a PtP message with forceQueuing set, then a callback queue shall be created. If this is not the case, then it is a bug (I believe however this feature is well tested)

3. Can an admin get() perform XPATH queries on the key when requesting messages?
Not directly. But you can solve that by letting joe/1 make an XPATH subscription. The admin get() just picks up the messages on which joe/1 subscribed.

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?
Yes, that's safe provided clientQ does not disconnect and provided its callback is on failsafe mode.

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.
On admin get, if you choose consumable=true, then the entry is taken (and deleted from the callback queue) inside a sync to that queue, so there is no way somebody else gets that message. In a normal get/erase aproach there is currently no way to synchronize that (We are still waiting for a sponsor to implement transactions :(

6. Has there been any performance testing on routing/retrieving mass amount of messages in this manner?
No, the admin get has not been productional yet. It was first intended to be used in our (yet unfinished) jms client library. It is used to synchronously get messages from jms queues.
I don't see however any reasons why it should not work well: it makes use of the get() and the queue access. Both of these are currently used productively and can be considered stable.



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)