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

Re: [xmlblaster] Some QOS Questions

Adam Williams wrote:

o Page 3
This is the qos of a publish() in Pub/Sub mode
o Page 4
This is the qos of a publish() in PtX mode
(The XPath is not implemented yet)
o Page 7
<content>false and <meta>false is not implemented, but
we should a soon the first user complains :-)
It is simple to add but takes time for testsuite etc. ..
Interesting is the QoS of the update() messages, they contain
a lot of information.

Ok, I think I've re-tooled to take care of the above problems, but I haven't attacked the Key DTD as I want to get the QoS stuff straight first.

I've added a slide for the <queue> tag in subscribing, but the example
leaves alot of questions.  Why is it "relating='unrelated'"?  The

This is reserved for future to allow unrelated subscribes. The subscribe is in this case
not related to a login session with its specific callback channel.
You can subscribe and and pass a callback address with the subscribe (currently
this is only possible on login). An example is a client which subscribes for a dumb toaster or
vacuum cleaner which are not capable or intelligent enough (or have no login account)
to do it themselve.

maxMsg, maxSize, and onOverFlow parameters make sense. But the term
"deadletter" seems confusing, as to those of us with a back ground in
mail servers a dead letter is a letter composed but never sent.

Ok, probably you are right. We have stolen the term from MQSeries (from IBM)
which use it to sent unrecoverable messages as dead letters.
Specialized clients (e.g. an administrator or a recorder) subscribes for dead letters
to handle them 'manually'.

Anyway... Is "deadletter" the only possible value for this parameter or
can the callback be made by other means as well?

/** message queue onOverflow handling, blocking until queue takes messages again */
public final static String ONOVERFLOW_BLOCK = "block";
/** message queue onOverflow handling, send a message marked as dead letter */
public final static String ONOVERFLOW_DEADLETTER = "deadLetter";
/** message queue onOverflow handling, erase the message silently */
public final static String ONOVERFLOW_DISCARD = "discard";
/** message queue onOverflow handling, take the oldest message from queue and erase it and stuff in the newest */
public final static String ONOVERFLOW_DISCARDOLDEST = "discardOldest";
/** message queue onOverflow handling, throw an exception */
public final static String ONOVERFLOW_EXCEPTION = "exception";

This are possible solution if a queue overflows.
For callback currently only deadLetter is implemented (block as well, but this makes
no sense since the server may dead lock).
On client side for the msg-recorder block, discard, discardOldest, exception is implemented.

Currently all this is under redesign - a persistent queue will allow similar behaviour
on client side (especially for cluster nodes) and for callbacks.
The behaviour will probably be a plugin, allowing users to code other
behaviour if they wish.
We have scheduled this until 12/2002.

 If so what is the
exact relationship to having selected onOverFlow="deadletter" and
"callback type='EMAIL'" or is the dead letter not really a "letter" but
simply a message that can be conveyed via any support callback method?

Exactly, the deadletter has nothing to do with email, it is just a special named message
containing a lost message.
Probably we should rename the feature to 'deadmessage'?

Next on to the QOS for update and get.... :)

The connect QoS is big as well :-)


thanks and keep on your valuable work (it is a good feedback as well)