[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] ConsumableQueuePlugin
Michele, No that is not correct:
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.
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
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
Yes, that's safe provided clientQ does not disconnect and provided its
callback is on failsafe mode.
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?
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 :(
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?
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.
in the email I answered yesterday I forgot another possible solution to
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)