jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tobias Bocanegra <tobias.bocane...@day.com>
Subject Re: handling indexing failure
Date Wed, 11 Jan 2006 08:25:23 GMT
...wait for jsr283 and the synchronous/vetoable observation [1] :-)

well, if the peformance does not suffer to much (i.e. if the indexing
is fast), you could index the data twice. once, just for checking
somewhere in the dav server part, and once in the filter.

we also planed to introduce some sort of custom constraint filter,
that can be somehow registered to the repository, in order to check
the property values.

regards, toby

[1] https://jsr-283.dev.java.net/issues/show_bug.cgi?id=13

On 1/10/06, Brian Moseley <bcm@osafoundation.org> wrote:
> my caldav server has a custom text filter for icalendar files. when an
> icalendar resource is put into the server, its content is parsed and
> the icalendar data is indexed but not stored (well, the binary stream
> is, but the parsed out components, properties and parameters are not).
> subsequent queries for the resource are serviced wholly out of the
> index.
> when filtering fails for some reason (say icalendar parsing fails),
> i'd like the PUT request to fail. in other words, the repository
> should communicate to the dav layer that indexing failed. but because
> indexing is implemented as an observation event, it doesn't appear
> that there is a regular code path that does what i want.
> one idea is to throw a specific runtime exception from the text filter
> and catch it in the layer that calls node.save(). that layer would
> have to explicitly remove the node upon catching the indexing
> exception.
> another idea is to chuck this whole index-but-dont-store strategy,
> which was devised in order to save storage space. our capacity goals
> are 10,000 users each with one 1,000 event calendar. without directly
> storing icalendar data in the repository, we'll need 10M nodes and 10M
> properties; adding icalendar components, properties and parameters
> might require another 100M or more of each. so you can see why storage
> space is at a premium :)
> anybody have any other suggestions?

-----------------------------------------< tobias.bocanegra@day.com >---
Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
T +41 61 226 98 98, F +41 61 226 98 97
-----------------------------------------------< http://www.day.com >---

View raw message