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

[xmlblaster] Re: Delaying messages



I still don't understand everything about how I_InvocationRecorder works.
Is it only a plug-in ? If this plug-in is declared to be use in the
properties file, will it be used for the connections to all clients ? Or
can I create a new FileRecorder from within, let's say an AccessFilter
plug-in, and use it to record and playback the messages sent to a
particular client ?

Thank you for your support
--
Brome



                                                                                                                                           
                      Marcel Ruff                                                                                                          
                      <ruff at swand.lake.de>               To:       xmlblaster at server.xmlBlaster.org                                        
                      Sent by:                           cc:                                                                               
                      owner-xmlblaster at server.xml        Subject:  Re: [xmlblaster] Re: Delaying messages                                  
                      Blaster.org                                                                                                          
                                                                                                                                           
                                                                                                                                           
                      06/20/2002 11:26 PM                                                                                                  
                      Please respond to                                                                                                    
                      xmlblaster                                                                                                           
                                                                                                                                           
                                                                                                                                           




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 ?
>
Yes.

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

>--
>Brome
>
>
>
>

>                      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
>state)
>  >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
>line
>  >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
>  >situation.
>  >
>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 {
>        queue.push(msgUnitWrapper);
>        }
>        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
>        org.xmlBlaster.engine.callback.CbWorker.java
>     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
>
>Marcel
>
>
>









--
DISCLAIMER:
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.