[
http://issues.apache.org/jira/browse/LUCENE-550?page=comments#action_12451870 ]
wolfgang hoschek commented on LUCENE-550:
-
I've now checked in a version of MemoryIndexTest into contrib/memory that more
easily allows to switch between
Hello java-devs,
I assume you guys are all quiet experienced java developers and
familiar with xml. After SummerOfCode I do have a bit more relaxed
time to implement one of the most important parts of gdata server -->
the storage layer. During summer of code I used DB4O which is GPL so I
implemen
22 nov 2006 kl. 11.38 skrev Simon Willnauer:
I'm actually looking for alternatives and suggestions
How much data is it that you store? I'm using Prevayler with great
success in many projects. Hobby and commercial. In some cases I use
it as a transactional layer for the index I keep buggin
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Karl Wettin updated LUCENE-550:
---
Attachment: lucene2karl-061122.tar.gz
This is the current version of my local Lucene branch, including
InstantiatedIndex. As I have not merged with the trunk for
Hi Karl,
I was looking at prevayler but I can not make any assumptions on how
many objects / data a person using the server wants to store. Imagine
a usecase like google mail. google mail is based on gdata and stores a
lot of data I guess. If you combine your mail server like JAMES (I did
that to
22 nov 2006 kl. 14.38 skrev Simon Willnauer:
some caches inside the storage or cache on the response layer but
first I need a "standard" persistence for the server which can scale
on many servers as well but single server environment is also
desirable at the moment.
I usually hide my persista
On 11/22/06, karl wettin <[EMAIL PROTECTED]> wrote:
22 nov 2006 kl. 14.38 skrev Simon Willnauer:
> some caches inside the storage or cache on the response layer but
> first I need a "standard" persistence for the server which can scale
> on many servers as well but single server environment is
On Nov 21, 2006, at 2:01 AM, Michael Busch (JIRA) wrote:
Furthermore people could take a look in the code coverage reports
to figure out where work needs to be done, i. e. where additional
testcases are neccessary. It would be nice if we could add a page
to the Lucene website showing the
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12451955 ]
Grant Ingersoll commented on LUCENE-707:
Any last comments on the new site? I am going to commit these changes within
the week (per the 4 items laid out i
[ http://issues.apache.org/jira/browse/LUCENE-550?page=all ]
Karl Wettin updated LUCENE-550:
---
Summary: InstantiatedIndex - faster but memory consuming index
(was: InstanciatedIndex - faster but memory consuming index)
Affects Version/s: 2.0.
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12451963 ]
Yonik Seeley commented on LUCENE-707:
-
> New site update instructions will be the same as:
> http://wiki.apache.org/solr/Website_Update_HOWTO
We might want a
[ http://issues.apache.org/jira/browse/LUCENE-720?page=all ]
Michael McCandless resolved LUCENE-720.
---
Fix Version/s: 2.1
Resolution: Fixed
OK I was able to reproduce the failure using IBMs JDK 5.0 on Linux. I changed
the tests to load the
[
http://issues.apache.org/jira/browse/LUCENE-720?page=comments#action_12452001 ]
Michael Busch commented on LUCENE-720:
--
The tests now pass on my machine too. Good job, Mike! Thanks.
> Unit tests TestBackwardsCompatibility and TestIndexFil
Grant Ingersoll wrote:
I would be more than happy to put 'em in once I get my zones account and
we decide on which tool to use.
You now have a zones account.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional com
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452006 ]
Doug Cutting commented on LUCENE-707:
-
The recently clarified Apache release policy at
http://www.apache.org/dev/release.html states that we should not link to
I was away so I'm catching up.
If this (occasional large documents consume too much memory) happens
to a few applications, should it be solved in IndexWriter?
A possible design could be:
First, in addDocument(), compute the byte size of a ram segment after
the ram segment is created. In the sync
[
http://issues.apache.org/jira/browse/LUCENE-720?page=comments#action_12452010 ]
Michael McCandless commented on LUCENE-720:
---
Thank you for tracking this down! I did not realize field number assinment was
volatile across JREs.
> Uni
Chris Hostetter wrote:
To throw another twist onto things, it would appear that the ASF has a
License for Clover 1.3.2 donated by Cenqua that Committers have access to
(see committers/donated-licenses/clover in SVN) ... it's not clear to me
if that License would allow for auto generated reports o
Ning Li wrote:
I was away so I'm catching up.
If this (occasional large documents consume too much memory) happens
to a few applications, should it be solved in IndexWriter?
A possible design could be:
First, in addDocument(), compute the byte size of a ram segment after
the ram segment is crea
I agree with Michael, if there is a clover licence we should use it.
One major advantage of clover is the ide support for eclipse and
netbeans. Emma has no Eclipse support yet and a old not maintained
netbeans plugin.
There is a ASF donated clover license under:
https://svn.apache.org/repos/privat
Michael Busch wrote on 11/22/2006 08:47 AM:
> Ning Li wrote:
>> A possible design could be:
>> First, in addDocument(), compute the byte size of a ram segment after
>> the ram segment is created. In the synchronized block, when the newly
>> created segment is added to ramSegmentInfos, also add its
[
http://issues.apache.org/jira/browse/LUCENE-565?page=comments#action_12452039 ]
Ning Li commented on LUCENE-565:
With the recent commits to IndexWriter, this patch no longer applies cleanly.
The 5 votes for this issue encourages
me to submit y
There is a flaw in this approach as you exceed the threshold before
flushing. With very large documents, that can cause an OOM.
This is a good point.
I agree that it would be better to do this in IndexWriter, but more
machinery would be needed. Lucene would need to estimate the size of
the n
Hi,
I'm working on a unit test for:
http://issues.apache.org/jira/browse/LUCENE-702
which is the "disk full during addIndexes() can corrupt index" issue.
I think the simplest way to do this is to subclass RAMDirectory to
create a MockDiskFullRAMDirectory class (and a corresponding
MockDisk
Michael McCandless wrote:
But to do this I'd need to make RAMDirectory non-final. Any
objections to this?
I can think of no reason it must be final.
Doug
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e
[ http://issues.apache.org/jira/browse/LUCENE-722?page=all ]
Daniel Naber resolved LUCENE-722.
-
Resolution: Fixed
Okay, unless there's a third version of that file it's fixed now :-)
> DEFAULT spelled DEFALT in MoreLikeThis.java
> --
Oracle JVM implementation for Lucene DataStore also a preliminary
implementation for an Oracle Domain index using Lucene
Key: LUCENE-724
URL:
[ http://issues.apache.org/jira/browse/LUCENE-724?page=all ]
Marcelo F. Ochoa updated LUCENE-724:
Attachment: ojvm.tar.gz
see patch description
> Oracle JVM implementation for Lucene DataStore also a preliminary
> implementation for an Oracle Domai
[ http://issues.apache.org/jira/browse/LUCENE-682?page=all ]
Hoss Man updated LUCENE-682:
Attachment: LocalizedQueryParser.patch
Revised version of the patch -- includes the changes so that only one method
creates the lists; a test of the splitting logic; m
[ http://issues.apache.org/jira/browse/LUCENE-682?page=all ]
Hoss Man updated LUCENE-682:
Attachment: LocalizedQueryParserOperatorsMicroBench.java
microbenchmark of the "default" (no ResourceBundle) usage, run against the
current trunk, and with this change
Simon,
Try BerkeleyDB. It's free, it's fast, it's got a super-simple API, it let's
you tune caching easily, etc.
Otis
- Original Message
From: Simon Willnauer <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Wednesday, November 22, 2006 5:38:26 AM
Subject: Storing GData Feeds -
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452157 ]
Otis Gospodnetic commented on LUCENE-707:
-
Grant, you should remove links to lucene4C (dead), and add links to Lucene.NET
in the Incubator.
I see 2 Lucene
[
http://issues.apache.org/jira/browse/LUCENE-707?page=comments#action_12452158 ]
Otis Gospodnetic commented on LUCENE-707:
-
Oh, and don't we want tabs for individual sub-projects at the top, like on
lucene.apache.org today?
> Lucene J
33 matches
Mail list logo
