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

[xmlblaster] Re: Delaying messages

Thanks for your answers !

If I understand well, it is possible to store messages with an
InvocationRecorder (with FileRecorder for instance), and playback the
messages slowly, or even better at a max rate, right ?

This would be the perfect solution for me, as this max messages per second
rate could be set to fit within the ISDN  bandwidth value !

                      Marcel Ruff                                                                                                          
                      <ruff at swand.lake.de>               To:       xmlblaster at server.xmlBlaster.org, Bertrand-Raphael.Maquel at ses-astra.com 
                      Sent by:                           cc:                                                                               
                      owner-xmlblaster at server.xml        Subject:  Re: [xmlblaster] Delaying messages                                      
                      06/20/2002 08:58 AM                                                                                                  
                      Please respond to                                                                                                    

    Bertrand-Raphael.Maquel at ses-astra.com wrote:

  >Working in asynchronous mode (whith publish/subscribe methods), Is it
  >possible to use a Publish Filter to delay messages ? I mean storing the
  >messages and sending them to the receiver later.
  >Here is my problem : I have a client linked to the XMLBlaster server
via a
  >switchable line : the line can switch between high bandwidth (normal
  >and low bandwidth (emergency state). But this client is not aware of the
  >status of the line, only the server can be.
  >So I want to store the messages sent to this client when the line is in
  >emergency state, so that the client can actually receive them when the
  >gets back to normal state.
  >I'm not allowed to use another client buffering the messages, although I
  >admit it would be really helpful ! Only the server may manage this
Hi Bertrand,

following Heinrichs solution you could consider this:

If i got you right, the client receives mainly updates
and is not a big publisher.

One solution is probably like this:
+--------+    fast connection        | xmlBlaster |
|        |----------------------<----|            |
| client |                      cb-updateQueue    |
|        |----------------------<----|            |
+--------+    emergency              +------------+

The client connects two times (two new XmlBlasterConnection
if it is a java client).
The emergConnect subscribes to emergency messages only
and the fastConnect to other messages.

You install an AccessFilter for mime types of the tail back messages.
Now you can hold back messages in the plugin and
feed them when the plugin detects high bandwith.

The problem is how does the plugin publish the tail back messages?

1.One solution is that the plugin connects itself as a client to
    its MoM and plays publisher, the problem is that if other clients
    have subcribed on this message they get it twice.

2. The other solution is to take the 'recevier' argument of the
    match(SubjectInfo publisher, SubjectInfo receiver, MessageUnitWrapper
msgUnitWrapper, Query query)
    method (from the I_AccessFilter)
    extract the callback session queue and push it there:

     import org.xmlBlaster.authentication.SessionInfo;
     import org.xmlBlaster.engine.SubscriptionInfo;
     import org.xmlBlaster.engine.queue.MsgQueueEntry;
     import java.util.Vector;
     import org.jutils.collection.Queue;

        // On hold back (RAM based queue):
        Queue queue = new Queue("MsgQueue", 10000);
        // ...
        try {
        catch(Exception e) {}

      // on playback (error handling is missing):
       // Assume the client has only logged in once with this name
      SessionInfo sessionInfo = receiver.getFirstSession();
      Vector vec =
      // Assume the client has exactly subscribed once
      SubscriptionInfo sub = (SubscriptionInfo)vec.firstElement();

      for (int i=0; i<queue.size(); i++) {
         MessageUnitWrapper msg = (MessageUnitWrapper)queue.pull();
         sessionInfo.queueMessage(new MsgQueueEntry(glob, sub, msg));
         // queue to be sent

     If you have to hold back many message which do not fit into
    RAM, you can use our high performing InvocationRecorder which
    allows you to store/retrieve messages to harddisk. See in
    org.xmlBlaster.client.protocol.XmlBlasterConnection.java the
    usage of 'recorder'. It allows fast/slow motion playback or
    playback with a max rate/sec.

3. The smartest solution on 'low-bandwidth' is to push all messages
     into our callback queue as usual (with the AccessPlugin and match()
     returns true) but
     set the callback worker thread to 'suspend' or 'slow motion'.

     You would need to implement this nice feature into
     and it would be a beautiful new QoS of xmlBlaster.

I would go # 3. but # 2. is smart as well.
Please use the newest xmlBlaster from cvs as i just have changed
a method access to public which would allow # 2.

good luck


This e-mail contains proprietary information some or all of which may be
legally privileged. It is for the intended recipient only. If an addressing
or transmission error has misdirected this e-mail, please notify the author
by replying to this e-mail. If you are not the intended recipient you must
not use, disclose, distribute, copy, print, or rely on this e-mail.