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

Re: [xmlblaster] Re: Delaying messages

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

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 !

You need to estimate the message sizes which is probably a bit unprecise...



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 Blaster.org 06/20/2002 08:58 AM Please respond to xmlblaster

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