: That is not my understanding. My understanding is that volatile just ensures
: the JIT always accesses the var in order - prevents some compiler
: optimizations - where as synchronized needs to acquire the lock. (There were
: discussions regarding having volatile create synchronized accessors be
For what its worth...
That is not my understanding. My understanding is that volatile just ensures
the JIT always accesses the var in order - prevents some compiler
optimizations - where as synchronized needs to acquire the lock. (There were
discussions regarding having volatile create synchronize
Is it just me or do we have a whole bunch of people proposing a whole
bunch of fairly broad changes to Lucene? (I know, I know, they should
always be backward compatible) Might this warrant some
coordination/planning? I know things are mostly done in an ad-hoc way
(whoever submits a patch), b
I agree with almost all of what you said.
The file format issue whoever is a non-issue. If you want interoperability
between systems do it via remote invocation and IIOP, or some HTTP
interface. This is far more easier to control, especially through version
change cycles - otherwise all platforms
On 5/10/06, Robert Engels <[EMAIL PROTECTED]> wrote:
I think you could use a volatile primitive boolean to control whether or not
the index needs to be read, and also mark the index data volatile and it
SHOULD PROBABLY work.
No, that still doesn't work.
volatile doesn't quite mean what you thin
You are correct.
It would seem that modern processor architecture will provide a better
solution to this. Since they seem to be giving up on clock-speed and going
with multiple parallel cores, and multi-processors, making a solution to
this problem of even greater importance. The upside should be
You mean you want us to be more organized!?!? :)
I think a Wiki page like
http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard might help. Something
like http://wiki.apache.org/jakarta-lucene/Lucene2.1Whiteboard
Otis
- Original Message
From: Grant Ingersoll <[EMAIL PROTECTED]>
To:
speaking of the wiki, we need to move it to /lucene instead of the
old /jakarta-lucene. I've copied infrastructure on this message to
find out what we need to do to shift it.
Erik
On May 10, 2006, at 11:30 AM, Otis Gospodnetic wrote:
You mean you want us to be more organized!?!
Sure, or even a place called Lucene Planning or Lucene Strategy. Just
not sure if it should be only on the Java side or not. Or even
Lucene3Whiteboard (did I really write Lucene 3?!?)
Otis Gospodnetic wrote:
You mean you want us to be more organized!?!? :)
I think a Wiki page like
http://wi
On Wed, 2006-05-10 at 13:29 -0400, Grant Ingersoll wrote:
> Or even Lucene3Whiteboard (did I really write Lucene 3?!?)
You know, I was just thinking that it would be nice if Lucene was
developed like the Linux kernels. When 2.6 is stable, people are beta
testing 2.7 and some hack 2.8.
Lucene version numbers are about compatibility.
Minor versions should always have complete API back-compatiblity.
That's to say, any code developed against X.0 should continue to run
without alteration against all X.N releases. A major release may
introduce incompatible API changes. The tran
What about the case where a "bug" is found that necessitates a file format
change.
Obviously this should be VERY rare given adequate testing, but it seems
difficult to make a hard and fast rule that X.0 should be able to ALWAYS
read X.N.
-Original Message-
From: Doug Cutting [mailto:[EMA
> File formats are back-compatible between major versions. Version X.N
> should be able to read indexes generated by any version after and
> including version X-1.0, but may-or-may-not be able to read indexes
> generated by version X-2.N.
>
> Note that older releases are never guaranteed to be
I have an application I'd like to move to J2ME which uses lucene for
creating and searching indexes. I can get by with the capabilities of
search.
karl wettin wrote:
On Sun, 2006-05-07 at 12:55 +0100, [EMAIL PROTECTED] wrote:
Some what off topic, but I've started looking in to porting Luc
On Wed, 2006-05-10 at 11:13 -0700, Doug Cutting wrote:
> File formats are back-compatible between major versions. Version X.N
> should be able to read indexes generated by any version after and
> including version X-1.0, but may-or-may-not be able to read indexes
> generated by version X-2.N.
>
>
On Wed, 2006-05-10 at 11:13 -0700, Doug Cutting wrote:
>
> File formats are back-compatible between major versions. Version X.N
> should be able to read indexes generated by any version after and
> including version X-1.0, but may-or-may-not be able to read indexes
> generated by version X-2.N.
>
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man updated LUCENE-557:
Attachment: LUCENE-557-newtests.zip
Silly Hoss ... I made a big blunder when i created these tests, and didn't
check that my "expected" cases where right for the basic
I'm looking into some of the issues with LUCENE-557 and it seems that a
lot of them are triggered by the way BooleanWeight.normalize is
implimented...
public void normalize(float norm) {
norm *= getBoost(); // incorporate boost
for (int i = 0 ; i < weights.
[
http://issues.apache.org/jira/browse/LUCENE-436?page=comments#action_12378997 ]
Fernando commented on LUCENE-436:
-
Here are our facts. It looks like this bug is also affecting us!!
We are also running into memory issues on our production servers and run
Hi
Can anyone please help me to know about how to compare two different lucene
indexes.
Thanks and reg
Anandh.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail and an
On Thursday 11 May 2006 01:39, Chris Hostetter wrote:
>
> I'm looking into some of the issues with LUCENE-557 and it seems that a
> lot of them are triggered by the way BooleanWeight.normalize is
> implimented...
>
> public void normalize(float norm) {
> norm *= getBoost();
21 matches
Mail list logo
