Mailing-List: contact dev-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@jackrabbit.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <91f3b2651002172339m1ce8d8ect81614644832eaa34@mail.gmail.com>
References: <510143ac1002170722g76806f23he522cd7fc05a2499@mail.gmail.com>
	 <c3ac3bad1002170747q778efe84y91a46495a38804e0@mail.gmail.com>
	 <697f8381002170751u6c090ae3kf413238a998ac9e6@mail.gmail.com>
	 <91f3b2651002172339m1ce8d8ect81614644832eaa34@mail.gmail.com>
Date: Thu, 18 Feb 2010 10:23:51 +0100
Message-ID: <697f8381002180123t7292b15erf31b02fcd9bc44c1@mail.gmail.com>
Subject: Re: [jr3] Search index in content
From: Ard Schrijvers <a.schrijvers@onehippo.com>
To: dev@jackrabbit.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Thu, Feb 18, 2010 at 8:39 AM, Thomas M=FCller <thomas.mueller@day.com> w=
rote:

>
> The fulltext index is (potentially) slow, specially fulltext
> extraction. Therefore, fulltext index should be done asynchronously if

would this be in line with the spec?

> it takes too long. Also, in a clustered environment, at least text
> extraction should only be done in one cluster node. I would still use
> Apache Tika and Apache Lucene for this.

Especially pdf extraction can kill the performance of an entire
cluster. As pdfs can be part of a document at our structure, where it
needs to be nodescope indexed every time the document is saved again,
we use an approach to store as binary (to use the DataStore) version
an extracted version of the pdf and index this extracted version: Only
one node in the cluster will now do the extraction, only one user is
blocked. The other nodes just index the extracted text version, which
is quite fast. Not sure if we should have this kind of option part of
JR

regards Ard

>
> Regards,
> Thomas
>