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

Re: Request for new feature

Peter Antman wrote:
> Hi,
> this is a request for a new feature in XmlBlaster. You will have to
> excuse me if this already works, I meen if the feature is already
> available in XmlBlaster, and I have missed it.
> Background:
> Naively I have assumed that the following behaviour was supported by
> XmlBlaster (since it seemded like something any MOM must have):
> - A new client subscriber will only get new messages, not messages
>    published before it logged in and started its subscription.
> Why is this needed? Lets take the following scenario:
> - We have a publisher which is publishing news of some sort. In the key
>  the publisher not only ads a unique oid for every message, it also ad
>  metainformation,such as headline, typ of subject, and perhaps even the
>  body of the text.
> - Clients wants to subscribe to these news, but through an XPATH query.
>   The XPATH query is not placed against the oid since that is unique for
>   every new message, but against the meta info.
> - Only clients that are currently online should get messages that
>   matched their query. A client that goes offline and then comes back
>   should not recive any old messages.
> - A future possibility would be to ad durable subscriptions so that
>   clients that identifyes them self in a special way may get old
>   messages (but not messages they have already recived).
> Current behaviour:
> I have not been able to get this type of behavour to work. Looking
> through the code I get to understand XmlBlaster a little better. To me
> it now seems as if there is a missmatch between the idea of specifying a
> target in the key and specifying searchable metadata. If I get it, the
> basic idea of XmlBlaster here is that messages with new content are
> published to the same key. This is not what I want.


> A soulution:
> I have implemented a workaround for this. It might not be the best one,
> but it seems to work. It consists of the following two additions:
> 1. Ad tag <topic> to PublishQoS (a boolean).
> 2. If isTopic is true, then a published message will be removed after
>    publishing in RequestBroker, ie:
>     // NEW FEATURE, Removes message after publishing
>          if (publishQoS.isTopic()) {
>              if (Log.TRACE) Log.trace(ME, "Erasing published message");
>              fireMessageEraseEvent(clientInfo, msgUnitHandler);
>              msgUnitHandler.erase();
>              msgUnitHandler = null;
>          }
> This will only be done i Pub/Sub mode.
> Ok, am I totaly of line here?
> Comments please.

I have added your suggestion, the new publish qos is




A use case where a published message stays transient (volatile=false)
is for example a mechanical measurement device.
A GUI subscribing to this data wants to see the current
value even if published only every 10 minutes.



Marcel Ruff
mailto:ruff at swand.lake.de