Re: [xmlblaster] Some QOS Questions

[Marcel Ruff <ruff at swand.lake.de>]

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 :-)

> ftp://kalamazoolinux.org/pub/pdf/xmlBlaster.pdf
>
>
>
>
>
>  

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

Marcel