[EMAIL PROTECTED] 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
>
> <[EMAIL PROTECTED]> To:
>[EMAIL PROTECTED], [EMAIL PROTECTED]
> Sent by: cc:
>
> [EMAIL PROTECTED] Subject: Re: [xmlblaster]
>Delaying messages
> Blaster.org
>
>
>
>
>
> 06/20/2002 08:58 AM
>
> Please respond to
>
> xmlblaster
>
>
>
>
>
>
>
>
>
> [EMAIL PROTECTED] 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
>
>
>
