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