Simon,
Im picking this thread up from the web archive, but I there was some
talk of replication of indexes. This message may not be threaded
correctly. I've just completed a custom FSDirectory implementation that
is designed to work in a cluster with replication.
The anatomy of this cluster
On 02/06/2006, at 9:37 AM, Simon Willnauer wrote:
The biggest problem with the lucene storage is to achieve a
transactional state. Imagine the following scenario:
An update request comes in. - the entry to update will be added to
the lucene writer who writes the update. But another delete
On 6/2/06, Ian Holsman [EMAIL PROTECTED] wrote:
On 02/06/2006, at 9:37 AM, Simon Willnauer wrote:
The biggest problem with the lucene storage is to achieve a
transactional state. Imagine the following scenario:
An update request comes in. - the entry to update will be added to
the lucene
On 6/1/06, Simon Willnauer [EMAIL PROTECTED] wrote:
So the results of the search are entry ids and a
corresponding feed. These entries will be retrieved from the storage
and send back to the client.
In the simplest case of using a lucene stored field to store the
original entry, it's a single
On 6/2/06, Yonik Seeley [EMAIL PROTECTED] wrote:
On 6/1/06, Simon Willnauer [EMAIL PROTECTED] wrote:
So the results of the search are entry ids and a
corresponding feed. These entries will be retrieved from the storage
and send back to the client.
In the simplest case of using a lucene
On 6/2/06, Simon Willnauer [EMAIL PROTECTED] wrote:
This is also true. This problem is still the server response, if i queue
some updates / inserts or index them into a RamDir I still have the problem
of concurrent indexing. The client should wait for the writing process to
finish correctly
: GData Server - Lucene storage
On 6/2/06, Simon Willnauer [EMAIL PROTECTED] wrote:
This is also true. This problem is still the server response, if i
queue some updates / inserts or index them into a RamDir I still have
the problem of concurrent indexing. The client should wait
On 6/2/06, Yonik Seeley [EMAIL PROTECTED] wrote:
On 6/2/06, Simon Willnauer [EMAIL PROTECTED] wrote:
This is also true. This problem is still the server response, if i queue
some updates / inserts or index them into a RamDir I still have the
problem
of concurrent indexing. The client should
--- Simon Willnauer [EMAIL PROTECTED]
wrote:
...
Using the client thread as the indexing thread might
just cause some
performance drawback but that's considerable for
Actually, I would not even assume that: handing tasks
over between threads causes context switch, and more
cache misses. In
On 6/2/06, Yonik Seeley [EMAIL PROTECTED] wrote:
On 6/2/06, Simon Willnauer [EMAIL PROTECTED] wrote:
So this would happen quiet often due to updates and inserts.
Hmm it is more and more a bad idea to use a lucene index as a storage.
Rather go straight to a Database.
Yes, if you need to be
On Jun 2, 2006, at 12:56 PM, Simon Willnauer wrote:
I had a look at the licence of the
sleepycat BerkleyDB for Java dist. and in my opinion it is alright
to use
and distribute it with the gdata server.
Are there any experts on licencing? Is it ok for the ASF to use that?
It's ok to use it,
From: Simon Willnauer [EMAIL PROTECTED]
To: Yonik Seeley [EMAIL PROTECTED]
Cc: java-dev@lucene.apache.org
Sent: Friday, June 2, 2006 9:56:24 AM
Subject: Re: GData Server - Lucene storage
On 6/2/06, Yonik Seeley [EMAIL PROTECTED] wrote:
On 6/2/06, Simon Willnauer [EMAIL PROTECTED] wrote
On 6/2/06, jason rutherglen [EMAIL PROTECTED] wrote:
It might be interesting to merge using BDB into Solr, as an option to provide
better realtime updates. Perhaps the replication could be used as well in
place of rsync? I don't have any experience with BDB replication, anyone have
thoughts
On Fri, 2 Jun 2006, jason rutherglen wrote:
It might be interesting to merge using BDB into Solr, as an option to
provide better realtime updates. Perhaps the replication could be used as
well in place of rsync? I don't have any experience with BDB replication,
anyone have thoughts on the
from the index+storage.
If that's so, I would consder renaming this StorageBuffer or some such.
Otis
- Original Message
From: Simon Willnauer [EMAIL PROTECTED]
To: java-dev@lucene.apache.org
Sent: Thursday, June 1, 2006 7:37:44 PM
Subject: GData Server - Lucene storage
Hello folks
consder renaming this StorageBuffer
or some such.
This is true. that should be changed. :)
Otis
- Original Message
From: Simon Willnauer [EMAIL PROTECTED]
To: java-dev@lucene.apache.org
Sent: Thursday, June 1, 2006 7:37:44 PM
Subject: GData Server - Lucene storage
Hello folks,
as I'm
Subject: Re: GData Server - Lucene storage
On Fri, 2 Jun 2006, jason rutherglen wrote:
It might be interesting to merge using BDB into Solr, as an option to
provide better realtime updates. Perhaps the replication could be used as
well in place of rsync? I don't have any experience with BDB
://www.sleepycat.com/docs/ref/lock/am_conv.html
Andi..
- Original Message
From: Andi Vajda [EMAIL PROTECTED]
To: java-dev@lucene.apache.org; jason rutherglen [EMAIL PROTECTED]
Sent: Friday, June 2, 2006 10:52:27 AM
Subject: Re: GData Server - Lucene storage
On Fri, 2 Jun 2006, jason
Hello folks,
as I'm the only developer on the project due to the SummerOfCode
program it is quiet a tough task to discuss all the architecture with
you on the mailing list. For this reason I decided to create UML
diagrams to discuss the main components. I will not attach the uml to
the mails
19 matches
Mail list logo
