[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xmlblaster] I_AccessFilter
Aha, I see the light now, I think. The subscriber specific stuff is
carried in the Query object. And the filter only need one instance. Ok.
I will work on that. Expect an XPath content router, soon ;-)
//Peter
On 24 Sep, Till: xmlblaster at server.xmlBlaster.org wrote:
> On 24 Sep, Marcel Ruff wrote:
>> Peter Antman wrote:
>>
>>>Hi,
>>>I am now looking into the new mime based connent filtering/query stuff.
>>>I do look verry promissing. However I have one problem with it. Let me
>>>explain my problem domain.
>>>
>>>We use XPATH based querys to route content. To be able to do this before
>>>the mime filters where invented we stuffed the content XML into the key
>>>header part. This has worked fine. It however has a couple of flawes:
>>>
>>>1. The key part is merged into the dom. The more XML content, the more
>>> expensive.
>>>
>>>2. Since XML blaster has not inherant notion of a destination in the JMS
>>> sense all content published will be parsed/queried by all XPATH
>>> queries, even if the are not at all applyable to the content.
>>>
>>>Therefore I would like to migrate to the mime based aproach. If I
>>>understand it correctly it would the be possible to publish with a for
>>>for example channel tag in key, have client filter exact on that (or
>>>oid, I do not remember) and then let the I_Access filter have its say
>>>only for the one that actually matched exact first. In that way we could
>>>lower the number of queries put against each message.
>>>
>>>However: we must be able to handle huge number of queries > 100 000.
>>>With the current I_AccesFilter implementation this does not seem like an
>>>options. Why. If I understand it correctly, each subscription means an
>>>instance of an I_AcessFilter.
>>>
>> No i don't think so, the plugin should only be loaded once.
>
> Then how does saving the query work? From Regexp for example:
>
> if (query.getPreparedQuery() == null) {
> try {
> expression = new RE(query.getQuery());
> query.setPreparedQuery(expression); // for better performance we remember the regex expression
>
> If I have two subscriptions, one with the query .*Telematique.*, the
> other with [^Hello], I would then not be able to setPreparedQuery if
> both my subscriptions used the same I_AccessFilter instance. Must it not
> be the case that NrOfInstances=NrOfFilter*NumberOfSubsribers?
>
>
>>> The broker will, for each subscriber,
>>>check the filter. The filter takes the "raw" MessageUntit. What does
>>>
>> No, it takes the preparsed (the xmlKey is preparsed) MessageUnitWrapper.
>
> Yea, I know. But the content is still the raw byte [] or string, is it
> not?
>
>>
>>>that mean: if I want to write an XPath based content router I would have
>>>to recreate a DOM tree of the content in each filter. Say I have 5000
>>>different quieries to be placed against the same content, I would have
>>>to create 5000 DOM trees of the same content. This will be verry slow.
>>>
>>>Is there any chance we could for mime type xml have a precreated DOM
>>>tree of the content available in the filter?
>>>
>> The filter framework does not support it itself, but you are
>> free to code anything into the filter plugin you like.
>
>
> But the problem is: if I have 5000 subsriptions I can not see any way of
> XmlBlaster not having to instantiated 5000 I_AccessFilter instances,
> which makes it impossible to create the DOM when seen first and then let
> all the other subsribers filter use that DOM tree instead of the raw
> data.
>
> //Peter
>
>>
>> Marcel
>>
>>>
>>>//Peter
>>>
>>>
>>
>
--
------------------------------------------------------------
Peter Antman Chief Systems Architect, Business Development
Technology in Media, Box 34105 100 26 Stockholm
WWW: http://www.tim.se WWW: http://www.backsource.org
Email: pra at tim.se
Phone: +46-(0)8-506 381 11 Mobile: 070-675 3942
------------------------------------------------------------