How to access cached hits in multi thread applications?

Hi all: is it safe to let multiple threads search concurrently using the same IndexSearcher? http://www.geocrawler.com/archives/3/2624/2001/6/0/5921366/ This problem was discussed in the middle of last year. Doug said: No, I don't think there has ever been a problem with this. The problems are o

Re: cvs commit: jakarta-lucene build.xml

Ah, I wish we had a discussion like this when the original suggestions were made, not now that things have been patched and committed. I never had a problem with the original Lucene setup, having 2 files did not bother me, and I think it is easier to edit property=value text files than Ant's XML.

Re: cvs commit: jakarta-lucene build.xml

- Original Message - From: "Otis Gospodnetic" <[EMAIL PROTECTED]> > I do think having defaults in build.xml and not build.properties is > better than having defaults in build.properties and that using > build.properties for overriding defaults instead of changing build.xml > is better (si

Re: cvs commit: jakarta-lucene build.xml

That build.properties in CVS looking like it is always used (because it's not called .sample or something such) looks like it would confuse people ("I changed XYZ in build.properties, but it didn't take effect. Why?"), that's what I was referring to when I said half-baked. In any case, I'll wait t

RE: cvs commit: jakarta-lucene build.xml

We should remove build.properties from CVS. Then things will be consistent. Separately we should resolve whether to add a default.properties file. Personally, I don't have a strong feeling about this. If forced to vote, I'd currently vote for leaving the defaults in build.xml, but I won't objec

cvs commit: jakarta-lucene/docs powered.html

cutting 02/02/27 09:36:07 Modified:docs powered.html Log: Regenerated powered.html Revision ChangesPath 1.9 +1 -0 jakarta-lucene/docs/powered.html Index: powered.html === RCS file: /h

Re: cvs commit: jakarta-lucene build.xml

As a new and cluless user of Ant, here's my vote: +1 on not requiring editing of build.xml +1 on keeping default properties in build.xml +1 on providing build.properties.sample with comments as to what can be overriden and how +1 on *no* default.properties I prefer build.properti

better, more accurate, RAMDirectory benchmark - RE: my submission though it's no faster - RE: Converting a FSDirectory (on disk index) to a RAMDirectory

Since the benchmark I ran yesterday had seemingly wrong results, and since the code was too complicated, I rewrote it into a simplier, more isolated benchmark. Executive summary is that with FSDirectory I get an avg of 850ms/query (time to process a query) and with RAMDirectory it's 775ms/query,

RE: cvs commit: jakarta-lucene build.xml

+ 1 on this Dmitry's votes. -Original Message- From: Dmitry Serebrennikov [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 12:09 PM To: Lucene Developers List Subject: Re: cvs commit: jakarta-lucene build.xml As a new and cluless user of Ant, here's my vote: +1 on not

RE: better, more accurate, RAMDirectory benchmark - RE: my submission though it's no faster - RE: Converting a FSDirectory (on disk index) to a RAMDirectory

Just curious, what OS is this and how much RAM do you have? Some OSes (Solaris, for example) apparently keep an in-memory disk cache using available RAM in the box. Something like this would negate much of any difference between the two runs as all the data would be in memory one way or another

Re: cvs commit: jakarta-lucene build.xml

Well, just to clarify if you change something in build.properties it *will* (by design) take effect! Thats what its all about! :) Erik - Original Message - From: "Otis Gospodnetic" <[EMAIL PROTECTED]> To: "Lucene Developers List" <[EMAIL PROTECTED]> Sent: Wednesday, February 27

cvs commit: jakarta-lucene/xdocs powered.xml

otis02/02/27 10:49:41 Modified:xdocspowered.xml Log: - Changed the name of the Yazd forum to its official name. Submitted by: Aflatoon Aflatooni Revision ChangesPath 1.7 +1 -1 jakarta-lucene/xdocs/powered.xml Index: powered.xml ===

Re: cvs commit: jakarta-lucene build.xml

Ah, yes, build.properties is still being sucked in by build.xml. Ok, I'm moving build.properties to build.properties.sample, commenting out everything it the latter (we can clean it up later), removing former from the CVS. This should clean things up. Anything else needs to be done? Otis ---

RE: cvs commit: jakarta-lucene build.xml

I don't think we should have a build.properties.sample. If someone wants to change a property they shouldn't create a copy of all of the properties, they should create a file that defines the single property that they wish to override. If we wish to provide an example of how you override a prope

RE: better, more accurate, RAMDirectory benchmark - RE: my submission though it's no faster - RE: Converting a FSDirectory (on disk index) to a RAMDirectory

Good point. I'm running on Win2k with 512MB. Decent cpu, approx 1GHz. -Original Message- From: Scott Ganyo [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 27, 2002 10:27 AM To: 'Lucene Developers List' Subject: RE: better, more accurate, RAMDirectory benchmark - RE: my submission

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 10:08 AM, "Dmitry Serebrennikov" <[EMAIL PROTECTED]> wrote: > As a new and cluless user of Ant, here's my vote: > +1 on not requiring editing of build.xml > +1 on keeping default properties in build.xml > +1 on providing build.properties.sample with comments as to what can > be o

RE: cvs commit: jakarta-lucene build.xml

Hi, I'm ok with either solution, provided that there's an easy and well documented way to override default properties (specifically javacc.home, which I think started this thread). Another option would be having only default properties in build.xml (the ones that should never be changed) and us

RE: new version of IndexWriter.java

My benchmarks show that my IndexWriter2.java performs better than the original IndexWriter.java, and - very important - preserves file system handles. Here are results of indexing on-and-the-same 11800 records on a poor SunBlade machine (1 cpu, 450mhz, decent IDE hard drive) with Solaris 8 OS. m

Re: cvs commit: jakarta-lucene build.xml

--- Jon Scott Stevens <[EMAIL PROTECTED]> wrote: > on 2/27/02 10:08 AM, "Dmitry Serebrennikov" <[EMAIL PROTECTED]> > wrote: > > > As a new and cluless user of Ant, here's my vote: > > +1 on not requiring editing of build.xml > > +1 on keeping default properties in build.xml > > +1 on provi

RE: cvs commit: jakarta-lucene build.xml

--- Doug Cutting <[EMAIL PROTECTED]> wrote: > I don't think we should have a build.properties.sample. If someone > wants to > change a property they shouldn't create a copy of all of the > properties, > they should create a file that defines the single property that they > wish to override. I a

RE: new version of IndexWriter.java

It would be good to also know the average size of your documents, the size of your index, and the amount of RAM required for each benchmark. Lucene currently indexes using very little memory. You're making it faster by using more RAM. In particular you're able to get a 10% speedup (58 versus 63

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 1:43 PM, "Otis Gospodnetic" <[EMAIL PROTECTED]> wrote: > I imagined build.properties.sample as a mostly blank file with a short > description about it's purpose at the top and maybe one commented out > example for people to follow. > So we wouldn't have to keep properties in sync with

RE: cvs commit: jakarta-lucene build.xml

Come on, what are we really asking of folks here? That those who wish to *build* Lucene know a little bit about reading an XML file? Why would this be a problem? You can always download the latest nightly binaries or whatever if you aren't up to building it. I would prefer that the build.prope

cvs commit: jakarta-lucene default.properties CHANGES.txt BUILD.txt build.xml

jon 02/02/27 14:18:28 Modified:.CHANGES.txt BUILD.txt build.xml Added: .default.properties Log: implemented what i proposed on the mailing list with regards to having a default.properties define the properties and allow people to define their own prop

cvs commit: jakarta-lucene build.properties

jon 02/02/27 14:20:06 Removed: .build.properties Log: no longer needed. -jon -- To unsubscribe, e-mail: For additional commands, e-mail:

cvs commit: jakarta-lucene CHANGES.txt

otis02/02/27 15:05:15 Modified:.CHANGES.txt Log: - Added 2 recent changes. Revision ChangesPath 1.8 +6 -2 jakarta-lucene/CHANGES.txt Index: CHANGES.txt === RCS file: /home/cvs

Re: cvs commit: jakarta-lucene build.xml

> > > >Ah, you are a committer here, so that -1 definitely has to count (for >some reason I thought you were not a commiter and hence didn't take >that -1 as seriously). Sorry about that. >I'm all for somebody else finishing this business. >Will you do it even if people vote not to use your sugges

Re: cvs commit: jakarta-lucene build.xml

*whew* what a bunch of trouble I stirred up. I apologize folks. I'm a firm believer in getting Ant usage more standardized, its just there is a lot of competing ways of such "standardization". Thank you Jon for enlightening me a bit into your reasons - it has been helpful for my own views. I a

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 7:05 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote: > *whew* what a bunch of trouble I stirred up. Please don't associate a discussion with trouble. :-) There is no trouble here...we all have ideas on how to make something work and we are just expressing them... > I apologize folks.

Re: cvs commit: jakarta-lucene build.xml

- Original Message - From: "Jon Scott Stevens" <[EMAIL PROTECTED]> > > *whew* what a bunch of trouble I stirred up. > > Please don't associate a discussion with trouble. :-) There is no trouble > here...we all have ideas on how to make something work and we are just > expressing them... T

Re: cvs commit: jakarta-lucene build.xml

on 2/27/02 10:02 PM, "Erik Hatcher" <[EMAIL PROTECTED]> wrote: > The biggest thing Ant and all the projects that use it is STANDARDIZATION! > One way or another, build.properties.sample / default.properties - doesn't > matter functionally. The standardization has to be at a much deeper level > t