[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 !
--
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.