Mark Harwood [markharw...@yahoo.co.uk]:
> Given a large range of IDs (eg your 300 million) you could constrain
> the number of unique terms using a double-hashing technique e.g.
> Pick a number "n" for the max number of unique terms you'll tolerate
> e.g. 1 million and store 2 terms for every prima
From: Mark Harwood [markharw...@yahoo.co.uk]
> Good point, Toke. Forgot about that. Of course doubling the number
> of hash algos used to 4 increases the space massively.
Maybe your hashing-idea could work even with collisions?
Using your original two-hash suggestion, we're just about sure to get
On Fri, 2010-10-22 at 11:23 +0200, eks dev wrote:
> Both of these solutions are just better way to do it wrong :) The real
> solution
> is definitely somewhere around ParallelReader usage.
The problem with parallel is with updates of documents. The IndexWriter
takes terms and queries for deleti
is might
turn out to be a very good thing for Lucene or it might seriously hamper
development. My gut feeling says the latter, but then again, I'm biased
by being firmly in the low-level group.
Regards,
Toke Eskildsen
-
To
of projects can benefit, but I would very much like to hear some
thoughts on this.
Thank you for listening,
Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: de
ead.
Thank you for sharing your test & measurements,
Toke Eskildsen
Environment:
lucene-3.6.1
cat /proc/cpuinfo | tail ...
processor : 15
vendor_id : GenuineIntel
cpu family : 6
model : 45
model name : Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz
stepping
Claudio Ranieri and I briefly discussed collator based sorting for
facets in the thread "Problem with accented words sorting" on the
solr-user mailing list. Here's the idea:
Solr faceting supports sorting by either count or index order. Claudio
and I both need the order to be collator-based. My un
On Tue, 2012-09-11 at 17:23 +0200, Robert Muir wrote:
> Just a concern where things could act a little funky:
>
> today for example, If I set strength=primary, then its going to fold
> Test and test to the same unique term,
> but under this scheme you would have Test and test as two terms.
>
> thi
On Mon, 2012-09-24 at 06:11 +0200, Robert Muir wrote:
> Artifacts are here: http://s.apache.org/lusolr40rc0
Sorry to interrupt as a non-voter, but I am afraid that
https://issues.apache.org/jira/browse/SOLR-3875 might be a blocker for
4.0. Maybe a veteran could take a quick look?
- T
My low-memory sorting/faceting-hacking requires terms to be accessed by
ordinals. With Lucene 4.0 I cannot depend on TermsEnums supporting ord()
and seek(long), so the code switches to a cache that keeps track of
every X terms if they are not implemented. When the terms for an ordinal
is requested,
g
recommendation of using ordinal-supporting codec might very well be the
best solution.
Thanks for helping,
Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
previously delivered marker. Maybe the TermState could hold a reference
to the BytesRef itself, if it is needed by the implementation?
Regards,
Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additi
On Tue, 2011-04-12 at 11:41 +0200, Gregor Heinrich wrote:
> Hi -- has there been any effort to create a numerical representation of
> Lucene
> indices. That is, to use the Lucene Directory backend as a large
> term-document
> matrix at index level. As this would require bijective mapping betwee
On Sat, 2011-07-09 at 05:44 +0200, Shai Erera wrote:
> The taxonomy is global to the index, but I think it will be
> interesting to explore per-segment taxonomy, and how it can be used to
> improve indexing or search perf (hopefully both).
I have struggled with this for some time and still haven't
nly if I had a
place to make a public repository (which admittedly is easy enough with
GitHub et al).
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additio
On Tue, 2012-11-13 at 19:50 +0100, Yonik Seeley wrote:
> The original version of Solr (SOLAR when it was still inside CNET) did
> this - a multiValued field with a single value was output as a singe
> value, not an array containing a single value. Some people wanted
> more predictability (always a
On Wed, 2012-11-14 at 14:46 +0100, Robert Muir wrote:
> On Tue, Nov 13, 2012 at 11:41 PM, Toke Eskildsen
> wrote:
> > Dynamically changing response formats sounds horrible.
>
> I don't understand how this is related with my proposal to
> automatically use a different
was
http://www.tomshardware.com/reviews/ssd-reliability-failure-rate,2923-3.html
It is a bit old and does not speak well for the Vertex 2 series.
> So just to conclude: Lucene kills SSDs :-)
I am an accomplice to murder!? Oh Noes!
- Toke Eskildsen, happily using an old 160GB Intel X25 SSD with 11TB
written and 3
On Sat, 2012-12-01 at 17:18 +0100, Per Steffensen wrote:
> With change/merge-tracking in both system, the important thing must be
> that you do not have to throw the tracked information away before in
> you attempt to get your changes into the main repository.
People write commit messages in many
4 AFAIR). Try calling 'ulimit -a' and
check that "max user processes" is sufficiently large.
If the limit is fairly low, your reboot might explain why switching to
1.7.0_10 seemed to be the solution, as you probably had less running
app
endent on a specific maximum line width
to be consistent.
With that in mind, I suggest that the code style recommendation is
expanded with the notion that a maximum of x characters/line should be
used, where x is something more than 80. Judging by a quick search, 120
chars seems to be a common ch
p.
It is natural that developers sees Solr as the most important component
and that makes us somewhat blind to the situations where Solr is just
another cog in a complex machinery. As the choice of how Solr is
deployed is highly relevant for users and maintenance guys, hearing
their point of view
ot;Solr is primarily intended for large scale projects but
can also be used for small scale"
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
f by default.
What is gained by logging queries outside of the standard logging
framework? Wouldn't it be better to create a logger with an agreed-upon
name, such as "queries" or "interaction"?
- Toke Eskildsen
---
Steve Rowe [sar...@gmail.com]:
> From now on, only people who appear on
> http://wiki.apache.org/solr/ContributorsGroup will be able to
> create/modify/delete wiki pages.
TokeEskildsen would like to be added to the list and would like spammers to
suffer greatly.
---
ndalone JAR?
- Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
2000+ line patch that has not been reviewed.
It seems a bit forced to add it to 7.6, but on the other hand it will
be tested thoroughly as part of the release process. What is the best
action here?
- Toke Eskildsen, Royal Danish Library
luctance to
upgrade to new major versions.
Thanks,
Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
From: Gus Heck wrote:
> Precommit appears to be failing related to this series of commits
Thank you. I clearly did not perform this step, even if I thought I did.
I apologize and will correct it right away.
Toke Eskildsen
-
Toke Eskildsen wrote:
> Gus Heck wrote:
>> Precommit appears to be failing related to this series of commits
> I apologize and will correct it right away.
Fixed. ant precommit now passes for me on master.
Thanks for the note Gus,
To
Doc Values, maybe I could be explained
what the problem is or directed towards more information?
- Toke Eskildsen, Royal Danish Library
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: de
I don't see any disagreement about improving docValues in the ways
> you suggest.
You are right about that. I apologize if I was being unclear: It is not the
concrete patch I am asking about, that's just how this started. I am asking for
background on why it is considered misuse to
ields!
> So I think as usual, "it depends".
I would like to think so, as that implies that it does make sense to consider
if changes to Doc Values codec representation causes a performance regression,
when using them to populate documents.
- Toke Eskildsen
Cc: to Daniel as the thread is a month old.
- Toke Eskildsen, Royal Danish Library
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
it did not solve your problem.
Cc: to Kranthi as he might have mailinglist-related delivery problems.
- Toke Eskildsen, royal Danish Library
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands,
essentially wasted: Queueing would give the same throughput with
lower memory requirements.
By the logic above, maxThreads of 100 or maybe 200 would be an
appropriate default for Jetty with Solr. So why the 10,000?
- Toke Eskildsen, State an
o you know if a limitation on threads is on the radar for Solr 5?
Thank you,
Toke Eskildsen, State and Univeristy Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands
ources if there is no
real limit on burst rate.
- Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
reads are
> created by this. Tomcat and Jetty default to allowing 200 threads.
> Solr will not scale with container defaults, which is why the example
> sets maxThreads to 1.
Are you talking about performance or deadlocks?
Shawn Heisey [s...@elyograg.org] wrote:
On 4/27/2014 12:29 AM, Toke Eskildsen wrote:
>> Are you talking about performance or deadlocks?
> Deadlocks. It's not a performance thing -- with only 200 threads
> allowed, Jetty will refuse to start the additional threads that a lar
e nice to have it as par of the Solr server
instead of outside.
Regards,
Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
e
number of unique facet values or something third like I/O.
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
not understand the logic here: When my request is for mincount > 0,
when does it ever make sense to have terms with count=0 returned from
any shard?
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mai
nature of SOLR-5894, having mincount >= 1 is essential there,
but it seems like it would provide a speed-up to all distributed
faceting with a sparse result set.
Regards,
Toke Eskildsen, State and University Library, Denmark
---
ysee...@gmail.com [ysee...@gmail.com] On Behalf Of Yonik Seeley
[yo...@heliosearch.com] wrote:
> On Mon, Jun 16, 2014 at 8:39 AM, Toke Eskildsen
> wrote:
>> I do not understand the logic here: When my request is for mincount > 0,
>> when does it ever make sense to ha
uff and no real
explanations, then I at least know that I can stop searching.
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
> minute (about a factor 60 faster) - and not requiring nearly as many
> resources from the system while performing the search.
Can you outline what you are doing?
Related to that, why are you running 50+ shards on each machine, when
you're doing search across all shards? Why not fewer shard
Solr setups at Lucene/Solr Revolution, I try to adopt a "sounds
insane, but it's probably correct"-mindset.
Anyway, setup accepted, problem acknowledged, your possibly re-usable solution
not understood.
- Toke Eskildsen
ght be too small for top-1000 to be really interesting as ID-resolving
would not take up as much of the overall processing time. But it would
make it possible to scaling that number up (top-1 or above).
- Toke Eskildsen, State and University Library, Denmark
--
t; one of them you will still be able to benefit from doing the other
> one.
I noticed that. Multiplying solutions are awesome.
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@
=*. If a field is referenced
explicitly with fl=myfield and is DocValued but not stored, return
the DocValued value.
* State that DocValued fields, that are not stored, should be returned
with a flag: resolvedv=true
- Toke Eskildsen, State and University Library, Denmark
iki or in the reference guide (my Google-fu
is weak).
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
eld" parser returns a
ValueSource, providing FunctionValues that, unfortunately for us, are
limited to single-value. We'll have to extract the multi-values
explicitly with faceting or export, as Joel suggests, for the time
being.
-
ledge - much difference between 2 or 4
(or 10) segments.
- Toke Eskildsen
From: Tom Burton-West [tburt...@umich.edu]
Sent: 25 February 2015 18:11
To: dev@lucene.apache.org
Subject: Fwd: Optimize maxSegments="2" not working right with Solr 4.10.2
determine with certainty, I could use a way of
performing a best-guess.
On a similar note, does Lucene have a concept of single and multi-value
stored fields or do I have to infer that by iterating all the documents
and check each one?
- Toke Eskildsen, State and University Library, Denmark
m existing stored/DV fields, in an NRT manner.
Thanks for the pointer. As far as I can see, the demo is very explicit
about the type of DocValues being long, so no auto-guessing there. It's
a very interesting idea though, with seamless DV-enabling.
Thank you,
Toke Eskildsen
On Mon, 2014-12-15 at 11:33 +0100, Michael McCandless wrote:
> On Mon, Dec 15, 2014 at 4:53 AM, Toke Eskildsen
> wrote:
[Toke: Limit on faceting with many references]
> Hmm that's probably the DocTermOrds 16 MB internal addressing limit?
Yes, we've hit that one before.
ty spirit of Solr. But I am sure it
was marked "Experimental" somewhere in the code and that the removal
obeyed the stated rules.
Anyway, done is done and as we have no future need for "Disk". But
thanks for the suggested fix.
> You could copy the code too to use newer Luc
in(rows, maxDoc)
# ScoreDoc Objects temporarily , which can trigger excessive garbage
# collection.
# Alternative: Use pagination
(https://cwiki.apache.org/confluence/display/solr/Pagination+of+Results)
- Toke Eskildsen, State and University L
I'll take a closer look on how the debug mechanism ties into
Solr. If sanity checking fits well, I'll try and make a proof of concept
and a JIRA.
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe
k out branch_7x and cherry-pick the changed files, check that
everything works and commit.
My I-think-I-am-doing-the-right-thing confidence level is rising, but
I'll keep asking for sanity-checks for some time.
- Toke Eskilds
file in isolation.
Ah yes. That's me being overly cautious of (non-existing) unrelated
changes. Cherry-pick with hash is the clean way.
Thank you,
Toke Eskildsen, Royal Danish Library
-
To unsubscribe, e-mail: dev-unsubscr...
equest be closed? Will an accept be
reflected at the Apache repo or should one close the pull-request
without accept, and commit the code directly to the Apache-repo (by
whatever method is easiest for transferring code between git repos)?
Thank you,
Toke Eskild
cifically for Lucene/Solr.
I'll try creating a patch from git tomorrow for SOLR-11240 and take it from
there.
Related to that I am unsure about Affect/Fix versions in JIRA. The SOLR-11240
issue is present in Solr 5+, so I just picked the latest released minor version
for 5 & 6 + master.
use the
drop-down) and that I to stay clear of any 'x'-versions, should they be
created by others.
Thank you,
Toke Eskildsen, Royal Danish Library
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
st phase: Resolving a term count is just a matter of
resolving its ordinal, then doing a lookup in the counter structure.
Unfortunately that does not work for Numerics.
- Toke Eskildsen, State and University Library, Denmark
with a standard FixedBitSet.
Does this sound reasonable? Should I open a JIRA? Attempt a patch?
- Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
s/1955322/at-what-point-is-it-worth-reusing-arrays-in-java
In the case of an update-tracked structure, the cost of zeroing is
linear to the amount of changed values. This makes it even harder to
determine the best strategy as it will be tied to concrete index size
and query pattern.
- Toke Eskil
et and agree that it looks very promising.
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
a good idea. Any feedback is very welcome.
I know very little writing plugins, so I am in no position to qualify
how much alba helps with that: From what I can see in your GitHub
repository, it seems very accessible though.
Thank you for sharing,
Toke Eskildsen, State and University Library,
ed named filter would (guessing here) be a
matter of writing a small alba-annotated class that takes the filter-ID
as input and returns the corresponding custom-made Filter, which really
is just a list of docIDs underneath (probably represented as a bitmap).
- Toke Eskildsen, State and Univer
ank you for bringing it to my attention,
Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
tside contributions?
- Toke Eskildsen
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Thank you for the invitation and the warm welcome.
I am a 43 year old Danish man, with a family and a job at the Royal Danish
Library, where I have been working mostly with search-related technology for 10
years.
I have done a fair bit of Lucene/Solr hacking during the years, with focus on
sp
That did not take long...
The initiation rite of adding my name to the committers list went well
until it was time to publish. The Publish lucene site at
https://cms.apache.org/lucene/publish
shows nothing under "Authors:" and when I press "View Diff", the
browser waits until I close the tab. I tr
page got published? I never got past the "Publish
lucene site"-page and my current sort-correction is still in staging.
Maybe someone else OK'ed the change?
Thank you,
Toke Eskildsen, Danish Royal Library
-
To
Jan Høydahl wrote:
> https://ci.apache.org/builders/lucene-site-production
[...]
> Toke, could you report this to INFRA perhaps? Looks like it has been failing
> for several days...
I have been in contact with INFRA (Gavin McDonald on the HipChat-channel) and
he kicked something loose that has
On Wed, 2017-02-15 at 22:37 +, Toke Eskildsen wrote:
> Jan Høydahl wrote:
> > https://ci.apache.org/builders/lucene-site-production
> [...]
> have been in contact with INFRA (Gavin McDonald on the HipChat-
> channel) and he kicked something loose that has been running for 3
is scenario be supported if uninversion is removed?
- Toke Eskildsen, State and University Library, Denmark
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
looking for a way
that a random end-user can easily do faceting on analyzed terms,
leveraging all the nice build-in filters in Solr.
- Toke Eskildsen, State and University Library, Denmark
om source X, remove if
that source is deprecated",
"type", "ImportantText",
"stored", "true",
...
},
...
}
It would be great to have the content from such a documentation field
pop up in the schema browser in the GUI.
- Toke Eskildsen, State and University Library, Denmark
he sentinels gets shadowed by overall processing. It only works
well when hitcount is near top-N, where "near" is one of those things that are
really hard to measure properly.
- Toke Eskildsen
-
To unsubs
On Sat, 2015-04-18 at 10:07 +0300, Shai Erera wrote:
> Our dev-tools/eclipse configure the project to break lines on 80
> characters. Are there objections to change it to 120?
Line length was discussed back in 2013 (search for "Line length in
Lucene/Solr code") and AFAIR the conclusion was not to
[
https://issues.apache.org/jira/browse/LUCENE-2735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927635#action_12927635
]
Toke Eskildsen commented on LUCENE-2735:
I tried making an extra tes
[
https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12928309#action_12928309
]
Toke Eskildsen commented on SOLR-792:
-
As I read the code, the implementation perfor
[
https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929401#action_12929401
]
Toke Eskildsen commented on SOLR-792:
-
The current interface does not allow for ne
[
https://issues.apache.org/jira/browse/SOLR-792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12929606#action_12929606
]
Toke Eskildsen commented on SOLR-792:
-
I'd be interested to hear what the focu
[
https://issues.apache.org/jira/browse/LUCENE-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toke Eskildsen updated LUCENE-2369:
---
Attachment: LUCENE-2369.patch
Bugfixes and maintenance. This patches against Lucene trunk
Toke Eskildsen created SOLR-3875:
Summary: Document boost does not work correctly when using
multi-valued fields
Key: SOLR-3875
URL: https://issues.apache.org/jira/browse/SOLR-3875
Project: Solr
[
https://issues.apache.org/jira/browse/LUCENE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989662#comment-12989662
]
Toke Eskildsen commented on LUCENE-2843:
I see that
[
https://issues.apache.org/jira/browse/LUCENE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989679#comment-12989679
]
Toke Eskildsen commented on LUCENE-2843:
Thank you. I will use the Fixe
[
https://issues.apache.org/jira/browse/LUCENE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12989691#comment-12989691
]
Toke Eskildsen commented on LUCENE-2843:
Robert, there is already OrdTermS
[
https://issues.apache.org/jira/browse/LUCENE-2369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toke Eskildsen updated LUCENE-2369:
---
Attachment: LUCENE-2369.patch
Maintenance patch bringing the code up to date with Lucene
[
https://issues.apache.org/jira/browse/LUCENE-2843?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12990477#comment-12990477
]
Toke Eskildsen commented on LUCENE-2843:
Michael, I think I'll use a
: 4.0
Environment: Fast IO when huge hierarchies are used
Reporter: Toke Eskildsen
Hierarchical faceting with slow startup, low memory overhead and fast response.
Distinguishing features as compared to SOLR-64 and SOLR-792 are
* Multiple paths per document
* Query-time
[
https://issues.apache.org/jira/browse/SOLR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Toke Eskildsen updated SOLR-2412:
-
Attachment: SOLR-2412.patch
Alpha-level patch (aka Proof Of Concept). Works with trunk@1066767
[
https://issues.apache.org/jira/browse/SOLR-2412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007411#comment-13007411
]
Toke Eskildsen commented on SOLR-2412:
--
The syntax for calling is kept close to
[
https://issues.apache.org/jira/browse/SOLR-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007497#comment-13007497
]
Toke Eskildsen commented on SOLR-2403:
--
Dividing by shard count is fairly risky
[
https://issues.apache.org/jira/browse/SOLR-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13007513#comment-13007513
]
Toke Eskildsen commented on SOLR-2403:
--
My first example was hills, while the se
[
https://issues.apache.org/jira/browse/SOLR-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13009627#comment-13009627
]
Toke Eskildsen commented on SOLR-2396:
--
A rough idea: It seems that ICU Collator
1 - 100 of 316 matches
Mail list logo
