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

Re: [xmlblaster] Delaying messages

   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 = msgUnitWrapper.getMessageUnitHandler().findSubscriber(sessionInfo); // 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