Hi Tx,
This is just to close the loop. Thank you very much for your helpful
suggestions.
This works fine and solves our problem.
Much appreciated.Clive
From: kiwi clive
To: Trejkaz ; Lucene Users Mailing List
Sent: Wednesday, February 1, 2017 7:37 PM
Subject: Re: How do I write in
From: Trejkaz
To: Lucene Users Mailing List ; kiwi clive
Sent: Wednesday, February 1, 2017 2:53 PM
Subject: Re: How do I write in 3.x format to an upgradeded index using Lucene
4.10
> If we take our old 3.x index and apply IndexUpgrader to it, we end up with a
> 4.10 index.
>
Hi Guys
We have several hundred thousand indexes that have been written in Lucene 3.x
format. I am trying to migrate to Lucene 4.10 without the need to reindex and
the process should be transparent to our customers. Reindexing all our legacy
data is not an option.
The predominant analyzer we c
Hi Guys,
We have an index/query server that contains several thousand fairly hefty
indexes. Each searcher is shared between many 'user-threads' and once opened we
keep the searcher in a cache which is refreshed depending on how often it is
used. Due to memory limitations on the server, we need s
Hi Mike,
Thanks for the very prompt and clear response. We look forward to using the new
(new for us) Lucenene goodies :-)
Clive
From: Michael McCandless
To: Lucene Users ; kiwi clive
Sent: Thursday, May 28, 2015 2:34 AM
Subject: Re: Search Performance with NRT
As long as you
Hi Guys
We are considering changing our Lucene indexer / search architecture from 2
separate JVMs to a single one to benefit from the very latest index views NRT
readers provide.
In the past we cached our IndexSearchers to avoid cold searches every time and
reopened them periodically. In the
;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
Hello guys,
We currently run with Lucene 3.6 and Java6. In view of the fact that Java7 is
soon to be deprecated, we are keen to move to Java8 and also to move to the
latest version of Lucene. I understand Lucene 5 is coming although we are happy
to move to 4.x as there are lots of goodies there
runs (we have 10,000+ shards). If
it were not for the consolidation required, I thin bobo would have been the way
forward.
I appreciate you taking the time to explain the situation.
Clive
From: Shai Erera
To: "java-user@lucene.apache.org" ; kiw
Hello all
Lucene version 3.6.1.
Sorry if this is a really stupid question, but is it possible to use
search-time facetting on an existing lucene index without the need to reindex?
My (limited) understanding is that FacetsCollector will pull facet data from
indexes that have been created with
Thank you Mike,
Much appreciated :-)
From: Michael McCandless
To: java-user@lucene.apache.org; kiwi clive
Sent: Monday, March 18, 2013 4:14 PM
Subject: Re: Lucene 4.1 org.apache.lucene.document.Field Deprecation
You need to create your own FieldType, e.g
Hi chaps,
Lucene 4.1.0:
I notice org.apache.lucene.document.Field(String name, String value,
Field.Store store, Field.Index index, Field.TermVector termVector) is marked as
deprecated while its suggested replacements (TextField and StringField) to not
seem to have support for Term Vectors.
I
Hi Guys,
Apologies if this has been asked before but I could not an appropriate post.
The Lucene Documentation stresses the use of a RawTermFiler when building up
the parentFilter and I was previously using the following in lucene 3.6.0:
Filter parentQueryFilter = new CachingWrappe
Be aware that StandardAnalyzer changed slightly. This is particularly important
if you use it to analyze email addresses and certain text-numeral combinations.
My understanding is that the newer version of StandardAnalyzer is more
consistent with what it should be doing but if you relied on its
Hi Bin Lan,
This bit me too.
You can choose to StandardAnalyzer and set the version number to 2.9.
Otherwise you can try using ClassicAnalyzer which I belive is 'old' Standard
Analyzer before it was tidied up.
Clive
From: Bin Lan
To: java-user@lucene.apac
the top page-size records. This way the ramindex
only has to be small and the database does the heavy lifting. - Although at the
cost of some sql trickery :-)
From: selvakumar netaji
To: java-user@lucene.apache.org; kiwi clive
Sent: Tuesday, November 13
I have used the last solution you mention many times to good effect as you can
sort across the two data sources and merge the results.
Obviously it depends on your architecture, RAM and and the amount of data you
are dealing with.
Clive
From: selvakumar netaj
org; kiwi clive
Sent: Friday, November 9, 2012 10:04 AM
Subject: Re: Lucene 3.6.0 high CPU usage
Are you getting the same, improved or worse performance/throughput?
Has the bottleneck switched from IO to CPU?
--
Ian.
On Thu, Nov 8, 2012 at 12:40 PM, kiwi clive wrote:
> Having played with
of
documents through the indexer and it seams to work admirably although I would
be happier if the load average came down.
Any lucene devs out there who could shed some light on this behaviour ?
Thanks,
Clive
From: kiwi clive
To: "java-user@lucene.apach
difference.
Clive
From: Lance Norskog
To: java-user@lucene.apache.org; kiwi clive
Sent: Sunday, October 28, 2012 11:09 PM
Subject: Re: A large number of files in an index (3.6)
An option: instead of merging continuously as you run, you can optimize with
mind is that the default merge policy has changed in
3.6 from 2.3.2 (I'm almost certain of that). So it's just a hunch but you
may have some unmerged segments left over at the end. Try calling
IndexWriter.close(true) after you're done indexing.
On Fri, Oct 26, 2012 at 10:50 AM, ki
Hello.
We have an index that when creted using lucene2.3.2, has a size of about 4G.
Creating the same index (with the same parameters) with lucene 3.6.0 results in
an 11G index.
Could someone shed some light into why the index is so much larger, given the
same data and the same parameters?
I
I did some tests and found for our need, ClassicAnalyzer was better (backwards
compatible). Our analyzer uses different tokenizers on certain fields but (used
to) fall back to StandardAnalyzer by default. ClassicAnalyzer will meet our
needs but I see we should move onto a newer implementation su
rg/apache/lucene/analysis/standard/StandardTokenizer.html
> http://lucene.apache.org/core/4_0_0-BETA/analyzers-common/org/apache/lucene/analysis/standard/ClassicTokenizer.html
>
> -- Jack Krupansky
>
> -Original Message- From: kiwi clive
> Sent: Wednesday, October 24, 2012 6:42 AM
> To:
Hi all,
Sorry if I'm asking an age old question but we have migrated to lucene 3.6.0
and I see StandardAnalyzer has changed its behaviour, particularly when
tokenizing email addresses. From reading the forums, I understand
StandardAnalyzer was renamed to ClassicAnalyzer - is this the case ?
I
Searcher);
Query toQuery = JoinUtil.createJoinQuery("to", "from", actualQuery,
indexSearcher);
And then use a boolean query to combine it? What is it you want to achieve?
Martijn
On 29 March 2012 14:04, kiwi clive wrote:
> Hi Chaps,
>
> JoinUtil.createJoinQuery() spec
impl
whilst the trunk (4.0) doesn't have this limitation.
Martijn
On 29 March 2012 14:39, Michael McCandless wrote:
> It'll be in both 3.6 and 4.0.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> On Thu, Mar 29, 2012 at 7:55 AM, kiwi clive wrote:
> >
Hi Chaps,
JoinUtil.createJoinQuery() specifies a Query for the from side of the join.
Is it possible to query over both sides of the join (while still providing the
two join fields) ? If not, what is the recommended best practice to do this?
Thanks, and apologies for the dumb questions
C
Hi Guys,
Will this be available in Lucene 3.6 or is it only going into version 4.0 ?
Clive
Hello
I've been looking at the BlockJoinQuery in Lucene 3.4.0 and would like to
clarify my understanding.
Suppose we have a parent document that we index with (say) 4 child documents.
My understanding is that these go in as an atomic unit and allows us to query
and join across the documents.
Hi Mike,
The problem was due to close(). A shutdown was calling close() which seems to
cause lucene to perform a merge. For a busy very large index (with lots of
deletes and updates), the merge process could take a very long time to complete
(hours). Calling close(false) solved the problem as
31 matches
Mail list logo
