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

Re: [xmlblaster] I_AccessFilter

On 24 Sep, Marcel Ruff wrote:
> Peter Antman wrote:
>>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

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


> Marcel

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