[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] Some QOS Questions
Adam Williams wrote:
This is reserved for future to allow unrelated subscribes. The subscribe
is in this case
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
I've added a slide for the <queue> tag in subscribing, but the example
leaves alot of questions. Why is it "relating='unrelated'"? The
not related to a login session with its specific callback channel.
You can subscribe and and pass a callback address with the subscribe
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
to do it themselve.
maxMsg, maxSize, and onOverFlow parameters make sense. But the termOk, probably you are right. We have stolen the term from MQSeries (from IBM)
"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.
which use it to sent unrecoverable messages as dead letters.
Specialized clients (e.g. an administrator or a recorder) subscribes for
to handle them 'manually'.
/** message queue onOverflow handling, blocking until queue takes
messages again */
Anyway... Is "deadletter" the only possible value for this parameter or
can the callback be made by other means as well?
public final static String ONOVERFLOW_BLOCK = "block";
/** message queue onOverflow handling, send a message marked as dead
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
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.
Exactly, the deadletter has nothing to do with email, it is just a
special named message
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?
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)