;> >
>> > 3075 W. Ray Road
>> > Suite 200
>> > Chandler, AZ 85226-2495
>> > USA
>> >
>> >
>> > M: (303) 912-0958
>> >
>> > E: jd.cor...@pearson.com
>> >
>> > Pearson
>> >
>>
r, AZ 85226-2495
> > USA
> >
> >
> > M: (303) 912-0958
> >
> > E: jd.cor...@pearson.com
> >
> > Pearson
> >
> > Always Learning
> > Learn more at www.pearson.com <http://www.pearsonk12.com/>
> >
> > On Thu, Feb 16
2495
> USA
>
>
> M: (303) 912-0958
>
> E: jd.cor...@pearson.com
>
> Pearson
>
> Always Learning
> Learn more at www.pearson.com <http://www.pearsonk12.com/>
>
> On Thu, Feb 16, 2017 at 9:12 AM, Erick Erickson
> wrote:
>
> > Please read the CHAN
n
Always Learning
Learn more at www.pearson.com <http://www.pearsonk12.com/>
On Thu, Feb 16, 2017 at 9:12 AM, Erick Erickson
wrote:
> Please read the CHANGES.txt in both the lucene and solr directories
> for all the changes between versions. The "New Features" section
Please read the CHANGES.txt in both the lucene and solr directories
for all the changes between versions. The "New Features" section is
probably the best overview, while the detailed bug changes are also
listed. Both of the above are defined for each release.
Best,
Erick
On Thu, Feb 1
Today I noticed there is a new release of Lucene v5.5.4. What is the major
difference(s) between the 5.x and 6.x lines of Lucene.
Thanks,
J.D. Corbin
Any thought on the below question?
On Friday 14 October 2016, Rajnish Kamboj wrote:
> Hi
>
> How can I make my Lucene queries agnostic to Lucene Versions?
>
> e.g. NumericRangeQuery in 5.3.1 is LegacyNumericRangeQuery in 6.0.0
> (NumericRangeQuery is completely removed)
>
>
>
> --
> Rajnish
>
Hi
How can I make my Lucene queries agnostic to Lucene Versions?
e.g. NumericRangeQuery in 5.3.1 is LegacyNumericRangeQuery in 6.0.0
(NumericRangeQuery is completely removed)
--
Rajnish
On Tue, May 12, 2015 at 4:52 PM, Trejkaz wrote:
> - If the int is negative
> - If it's >= -8, then it's Lucene 2.x
> - If it's <= -9, then it's Lucene 3.x
>
> Is anything amiss with this logic?
To answer what nobody else is answering (perhaps nobody knows),
somethi
Hi all.
Some of our indexes out there in the wild were created on 2.x. We're
about to try updating lucene to 5.x, so we have to update them to at
least 4.x.
Firstly, has anyone already put together a tool to do this? I see
several people asking similar questions on the mailing list and figure
tha
was idea to migrate Java version on
Java 8.
For reference, JRE major versions with their corresponding Unicode versions:
* Java 6, Unicode 4.0
* Java 8, Unicode 6.2
The first thing I found was
JRE_VERSION_MIGRATION<https://github.com/apache/lucene-solr/blob/trunk/luc
On Thu, Feb 12, 2015 at 11:58 AM, McKinley, James T
wrote:
> Hi Robert,
>
> Thanks for responding to my message. Are you saying that you or others have
> encountered problems running Lucene 4.8+ on the 64-bit Java SE 1.7 JVM with
> G1 and was it on Windows or on Linux? If so, where can I find
Version Upgrade (3->4) and Java JVM Versions(6->8)
No, because you only looked into one bug. We have seen and do so see
many G1 related test failures, including latest 1.8.0 update 40 early
access editions. These include things like corruption.
I added this message with *every intention* to sc
t the OpenJDK/Oracle
> 32-bit JVM (if only on Windows, say only on Windows) has a bug that when used
> in combination with the the G1 garbage collector causes incorrect code to be
> produced possibly resulting in index corruption", or something along those
> lines. It seems a
ng
G1GC with the 64-bit JVM given that it has better performance on large heaps
which are becoming more common today.
FWIW,
Jim
From: McKinley, James T [james.mckin...@cengage.com]
Sent: Monday, February 09, 2015 11:00 AM
To: java-user@lucene.apache.org
Subject: RE:
tigate it.
Jim
From: Erick Erickson [erickerick...@gmail.com]
Sent: Saturday, February 07, 2015 2:22 PM
To: java-user
Subject: Re: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
The G1C1 issue reference by Robert Muir on the Wiki page is at a
Lucene level. Lucene, of
Subject: Re: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
>
> Hello.
> A little bit delayed question. But recently I have found this articles:
> https://wiki.apache.org/solr/SolrPerformanceProblems
> https://wiki.apache.org/solr/ShawnHeisey#GC_Tuning
>
> E
yway), G1GC seems to
> work well with Lucene.
>
> Jim
>
> From: Piotr Idzikowski [piotridzikow...@gmail.com]
> Sent: Friday, February 06, 2015 5:35 AM
> To: java-user@lucene.apache.org
> Subject: Re: Lucene Version Upgrade (3->4)
work well with
Lucene.
Jim
From: Piotr Idzikowski [piotridzikow...@gmail.com]
Sent: Friday, February 06, 2015 5:35 AM
To: java-user@lucene.apache.org
Subject: Re: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
Hello.
A little bit delay
Sent: Tuesday, January 27, 2015 3:02 PM
> To: java-user@lucene.apache.org
> Subject: RE: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
>
> Hi.,
>
> About G1GC. We consistently see problems when running the Lucene Testsuite
> with G1GC enabled. The people from
om: Uwe Schindler [u...@thetaphi.de]
Sent: Tuesday, January 27, 2015 3:02 PM
To: java-user@lucene.apache.org
Subject: RE: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
Hi.,
About G1GC. We consistently see problems when running the Lucene Testsuite with
G1GC enabled. The people fr
on Upgrade (3->4) and Java JVM Versions(6->8)
>
> Why do you say not to use G1GC? We are using Java 7 & G1GC with Lucene
> 4.8.1 in production. Thanks.
>
> Jim
>
> From: Uwe Schindler [u...@thetaphi.de]
> Sent: Tuesday, January
ct: RE: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
Java 8 update 20 or later is also fine. At current time, always use latest
update release and you are be fine with Java 7 and Java 8. Don't use older
releases and don't use G1 Garbage Collector.
-
Uwe Schindler
e
eMail: u...@thetaphi.de
> -Original Message-
> From: kiwi clive [mailto:kiwi_cl...@yahoo.com.INVALID]
> Sent: Tuesday, January 27, 2015 8:03 PM
> To: java-user@lucene.apache.org
> Subject: Re: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
>
> Hi Hoss,
> Man
;java-user@lucene.apache.org" ; kiwi clive
Sent: Tuesday, January 27, 2015 4:01 PM
Subject: Re: Lucene Version Upgrade (3->4) and Java JVM Versions(6->8)
: I seem to remember reading that certain versions of lucene were
: incompatible with some java versions although I cannot find anyth
: I seem to remember reading that certain versions of lucene were
: incompatible with some java versions although I cannot find anything to
: verify this. As we have tens of thousands of large indexes, backwards
: compatibility without the need to reindex on an upgrade is of prime
there we can use.
I seem to remember reading that certain versions of lucene were incompatible
with some java versions although I cannot find anything to verify this. As we
have tens of thousands of large indexes, backwards compatibility without the
need to reindex on an upgrade is of prime
Hi John,
I just had a look at Mike's benchs[1][2] which don't show any
performance difference from approximately 1 year. But this only tests
a conjunction of two terms so it might still be that latency worsened
for more complex queries.
[1] http://people.apache.org/~mikemccand/lucenebench/AndHigh
Has anyone experienced a latency increase between the above versions?
Mainly in conjunction queries.
Thanks
-John
On Sat, Aug 20, 2011 at 7:00 PM, Robert Muir wrote:
> On Sat, Aug 20, 2011 at 3:34 AM, Trejkaz wrote:
>
>>
>> As an aside, Google's behaviour seems to follow the "old" way. For
>> instance, [[ 限定 ]] returns 640,000,000 hits and [[ 限 定 ]] returns
>> 772,000,000. (Interestingly, [[ "限定" ]] return
On Sat, Aug 20, 2011 at 3:34 AM, Trejkaz wrote:
>
> As an aside, Google's behaviour seems to follow the "old" way. For
> instance, [[ 限定 ]] returns 640,000,000 hits and [[ 限 定 ]] returns
> 772,000,000. (Interestingly, [[ "限定" ]] returns 643,000,000 hits.
> Slightly more than you might expect.)
On Fri, Aug 19, 2011 at 11:05 AM, Chris Hostetter
wrote:
>
> See LUCENE-2458 for the backstory.
>
> the argument was that while phrase queries were historicly generated by
> the query parser when a single (white space deliminated) "chunk" of query
> parser input produced multiple tokens, that logi
See LUCENE-2458 for the backstory.
the argument was that while phrase queries were historicly generated by
the query parser when a single (white space deliminated) "chunk" of query
parser input produced multiple tokens, that logic didn't make sense in CJK
type langauges where whitespace is not
Hi all.
Suppose I am searching for - 限定
In 3.0, QueryParser would parse this as a phrase query. In 3.3, it
parses it as a boolean query, but offers an option to treat it like a
phrase. Why would the default be not to do this? Surely you would
always want it to become a phrase query.
The new p
Hello Lucene users,
On behalf of the Lucene development community I would like to announce the
release of Lucene Java versions 3.0.3 and 2.9.4:
Both releases fix bugs in the previous versions:
- 2.9.4 is a bugfix release for the Lucene Java 2.x series, based on Java
1.4.
- 3.0.3 has the same bug
versions ?
Hi Kannan,
contrib-queryparser code is not compatible with 2.4 release because it uses
the Attribute API, which was only introduced in 2.9.
Regards,
Adriano Crestani
On Wed, Apr 28, 2010 at 8:44 PM, kannan chandrasekaran
wrote:
> Hi All,
>
> I have a question regardin
Hi Kannan,
contrib-queryparser code is not compatible with 2.4 release because it uses
the Attribute API, which was only introduced in 2.9.
Regards,
Adriano Crestani
On Wed, Apr 28, 2010 at 8:44 PM, kannan chandrasekaran
wrote:
> Hi All,
>
> I have a question regarding the new Lucene query pars
Hi All,
I have a question regarding the new Lucene query parser framework in the
contribs project.
My company's project is running on top of 2.4.0 release of Lucene. I am
trying to evaluate the new query parser framework that was added to the
contribs project in the Lucene 2.9.0 release an
e to try it and check if your code works the same(I doubt it
would though).
About having 2 versions of lucene on the same machine, ofcourse yes, it is
as good as having 2 (or more) java jars.
I am presuming that you place your lucene core jar in the project library
directory and not in the jre/lib/ex
Hi,
I am trying to upgrade the version of Lucene from 1.2 to 2.4. Can we do
this directly?
Is it possible to have two versions of Lucene on the same machine.?
Shireesha
This e-mail and any files transmitted with it are for the sole use of the
intended recipient(s) and may
Just to bring closure here: this in fact looks like some sort of JVM
hotspot compiler issue, as best we can tell.
Running java with -Xbatch (forces up front compilation) prevents
(works around) the issue.
I've committed some additional assertions to the particular Lucene
code (merging o
Ian can you attach your version of SegmentMerger.java? Somehow my
lines are off from yours.
Mike
Ian Lea wrote:
Mike
Latest patch produces similar exception:
Exception in thread "Lucene Merge Thread #0"
org.apache.lucene.index.MergePolicy$MergeException:
java.lang.AssertionError: after
Hi Ian,
Sheesh that's odd. The SegmentMerger produced an .fdx file that is
one document too short.
Can you run with this patch now, again applied to head of 2.3
branch? I just added another assert inside the loop that does the
field merging.
I will scrutinize this code...
Mike
I
Ian,
Could you apply the attached patch applied to the head of the 2.3
branch?
It only adds more asserts, to try to pinpoint where exactly this
corruption starts.
Then, re-run the test with asserts enabled and infoStream turned on
and post back. Thanks.
Mike
Ian Lea wrote:
It'
It's failed on servers running SuSE 10.0 and 8.2 (ancient!)
$ uname -a shows
Linux phoebe 2.6.13-15-smp #1 SMP Tue Sep 13 14:56:15 UTC 2005 x86_64
x86_64 x86_64 GNU/Linux
and
Linux phobos 2.4.20-64GB-SMP #1 SMP Mon Mar 17 17:56:03 UTC 2003 i686
unknown unknown GNU/Linux
The first one has a 2.8G
On Tue, Mar 18, 2008 at 7:38 AM, Ian Lea <[EMAIL PROTECTED]> wrote:
> Hi
>
>
> When bulk loading into a new index I'm seeing this exception
>
> Exception in thread "Thread-1"
> org.apache.lucene.index.MergePolicy$MergeException:
> org.apache.lucene.index.CorruptIndexException: doc counts differ
I don't see an attachment here -- maybe the mailing list software
stripped it off. If so can you send directly to me? Thanks.
Mike
Ian Lea wrote:
Documents are biblio records. All have title, author etc. stored,
some have a few extra fields as well. Typically around 25 fields per
doc.
Documents are biblio records. All have title, author etc. stored,
some have a few extra fields as well. Typically around 25 fields per
doc. The index is created with compound format, everything else as
default.
I've rerun the job until failure. Different numbers this time, but
basically the sa
The data is loaded in chunks of up to 100K docs in separate runs of
the program if that helps answer the first question. All buffers have
default values, docs are small but not tiny, JVM is running with
default settings.
Answers to previous questions, and infostream, will follow once the
job has
One question: do you know whether 67,861 docs "feels like" a newly
flushed segment, or, the result of a merge?
Ie, roughly how many docs are you buffering in IndexWriter before it
flushes? Are they very small documents and your RAM buffer is large?
Mike
Ian Lea wrote:
Hi
When bulk l
Can you call IndexWriter.setInfoStream(...) and get the error to
happen and post back the resulting output? And, turn on assertions
(java -ea) since that may catch the issue sooner.
Can you describe you are setting up IndexWriter (autoCommit,
compound, etc.), and what your documents are
Hi
When bulk loading into a new index I'm seeing this exception
Exception in thread "Thread-1"
org.apache.lucene.index.MergePolicy$MergeException:
org.apache.lucene.index.CorruptIndexException: doc counts differ for
segment _4l: fieldsReader shows 67861 but segmentInfo shows 67862
at
or
ltisearcher
across indexes with different formats, some of which have been
accessed via
a secondary classloader?)
I meant that you could keep running of the 2.n code for indices
stored in that format, parallel to running the future version of
Lucene of indices created for those futu
On Apr 23, 2007, at 1:08 AM, Lucifer Hammer wrote:
I'm curious, why is migrating the index not OK when it is OK to
upgrade the software? It doesn't really add up in my head.
We keep our indexed archives on write-once media. If we're forced
to move
our indexes up to a newer format, then we
On 4/23/07, karl wettin <[EMAIL PROTECTED]> wrote:
23 apr 2007 kl. 06.39 skrev Lucifer Hammer:
I'm curious, why is migrating the index not OK when it is OK to
upgrade the software? It doesn't really add up in my head.
We keep our indexed archives on write-once media. If we're forced to move
there's a
migration
path, however, that's not our goal - we'd like to keep our current
2.0archives in
2.0 format, and know that we can read/search them from future
versions of
Lucene.
I'm curious, why is migrating the index not OK when it is OK to
upgrade the software?
d/search them from future versions of
Lucene.
Thanks
Lucifer
On 4/23/07, karl wettin <[EMAIL PROTECTED]> wrote:
23 apr 2007 kl. 06.10 skrev Lucifer Hammer:
> Should/can we expect that all future versions of Lucene will be
> able to read
> older indexes?
Yes.
<http://
23 apr 2007 kl. 06.10 skrev Lucifer Hammer:
Should/can we expect that all future versions of Lucene will be
able to read
older indexes?
Yes.
<http://wiki.apache.org/lucene-java/
LuceneFAQ#head-5ad8d7368624fbe30cc1237d164c5820cf80e46b>
-
Hi,
Is there a goal for lucene to always be able to read indexes written by
older versions of Lucene? For instance, I noticed that I could read 2.0 and
1.9 indexes with a 2.1 Lucene jar. (I also noticed that if I add a document
to one of those older indexes, then they'll be rewritten i
>Am I correct in understanding that you have two seperate applications:
one
>reading hte index and one writing the index and you only upgraded
lucene
>for the application that writes the index?
Yes
>If so, this is not a supported compatibility situation, if the wiki
were
>up right now there is a
Hi,
I suspect what happened is result of a "mis-ordered" upgrade sequence:
The first of the two applications managed to access and upgrade
the index. However the second application then tried to update the
already upgraded index and messed things up.
I think this may even be worse, as one of the
-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.
...what happens is that the 2.X code in the trunk can correctly read your
2.1 index
I believe the Lucene file format changed in version 2.1, and your nightly
.jar file is probably v2.1. See
http://lucene.apache.org/java/docs/fileformats.html#Segments%20File.
I'm afraid I'm not an expert on the related compatibility issues. It has
been my experience that pre-2.1 Lucene cannot read
I have two applications that share some of the same Lucene Indexes. I
recently upgrade the Lucene-core.jar from v2.0 to a nightly build (Feb.
04, 2006 - I was looking for the IndexWriter class that allows you to
merge indexes w/o optimizing).
Now I notice the index is a little different:
P
: I have downloaded the last nightly build. I was looking for an
: interesting method I found in the javadoc (Explanation.getSummary()) but
: I found nothing similar, only getDescription() and getDetails(), which
: were already present in v2.0. Is this method still to be added? Or has
: it been di
Thanks a lot!!!
I have downloaded the last nightly build. I was looking for an
interesting method I found in the javadoc (Explanation.getSummary()) but
I found nothing similar, only getDescription() and getDetails(), which
were already present in v2.0. Is this method still to be added? Or has
Hi Luis,
Chris Hostetter wrote:
> Luis Rodrigo Aguado wrote:
> : I've been looking through the documentation in the official
> : web-site, and the Javadoc belongs to v2.1, that I could not find
> : anywhere, anyone has a clue about where to find it or when will it be
> : officially released?
>
: Date: Fri, 04 Jan 1980 10:49:34 +0100
: Subject: Versions
1) you should fix your clock.
2) ...
: I've been looking through the documentation in the official
: web-site, and the Javadoc belongs to v2.1, that I could not find
: anywhere, anyone has a clue about where to find it or
Hi all,
I've been looking through the documentation in the official
web-site, and the Javadoc belongs to v2.1, that I could not find
anywhere, anyone has a clue about where to find it or when will it be
officially released?
Thanks!
00
: From: Rick Hillegas <[EMAIL PROTECTED]>
: Reply-To: java-user@lucene.apache.org
: To: java-user@lucene.apache.org
: Subject: lucene versions
:
: Hello,
:
: I'm looking into integrating lucene with derby. I'm just starting out so
: I'm afraid I'm going to pepper this li
t;[EMAIL PROTECTED]>
: Reply-To: java-user@lucene.apache.org
: To: java-user@lucene.apache.org
: Subject: lucene versions
:
: Hello,
:
: I'm looking into integrating lucene with derby. I'm just starting out so
: I'm afraid I'm going to pepper this list with some newbie questions
Hello,
I'm looking into integrating lucene with derby. I'm just starting out so
I'm afraid I'm going to pepper this list with some newbie questions.
Here's one: The downloadable lucene distribution has rev level 1.4.3 and
was released a year ago according to
http://lucene.apache.org/java/doc
72 matches
Mail list logo
