hanged, please refer to "files under tlog directory " section below. Not sure
those information is useful or not.
Thank you!
--Michael Hu
--- beginning for issuing core commit ---
$ curl
'http://localhost:8983/solr/myconection_myshard_replica_t7/update?commit=true'
{
"responseHeade
tries"
section, and the log entry repeats continuously for every auto commit after
reload. I hope this log entry can provide some information for the issue.
Please help and suggestion what I may do incorrectly. Or this is a known issue,
is there a way I can fix or work-around it?
Thank you
Congratulations and thank you, Jan! It is so exciting that Solr is now a
TLP!
Mike McCandless
http://blog.mikemccandless.com
On Thu, Feb 18, 2021 at 1:56 PM Anshum Gupta wrote:
> Hi everyone,
>
> I’d like to inform everyone that the newly formed Apache Solr PMC
> nominated and elected Jan
Yes, Congratulations and a big thank you Jan!
On Thu, Feb 18, 2021 at 1:56 PM Anshum Gupta wrote:
>
> Hi everyone,
>
> I’d like to inform everyone that the newly formed Apache Solr PMC nominated
> and elected Jan Høydahl for the position of the Solr PMC Chair and Vice
> President. This
Ah! that's significant. The latency is likely due to building the
OrdinalMap (which maps segment ords to global ords) ... "dvhash" (assuming
the relevant fields are not multivalued) will very likely work; "dvhash"
doesn't map to global ords, so doesn't need to build the OrdinalMap (which
gets
Apologies, I missed deducing from the request url that you're already
talking strictly about single-shard requests (so everything I was
suggesting about shards.preference etc. is not applicable). "dvhash" is
still worth a try though, esp. with `numFound` being 943 (out of 185
million!). Does this
creation and
array allocation, if either/both of those contribute to the latency you're
finding).
Michael
On Fri, Feb 5, 2021 at 4:42 PM mmb1234 wrote:
> Hello,
>
> I am seeing very slow response from json faceting against a single core
> (though core is shard leader in a collection).
t;
> One thing I can add is I tried dvhash with a string multi-valued field, it
> worked and didn’t throw any error but I don’t know if it got silently
> ignored or just worked.
>
> Sent from Mail for Windows 10
>
> From: Michael Gibney
> Sent: 05 February 2021 20:52
> To
On Fri, Feb 5, 2021 at 12:49 PM Michael Gibney
wrote:
> > Performance and resource is still affected by 30M unique values of T
> right?
> Yes. The main performance issue would be the per-request allocation of a
> 30M-element `long[]` for "dv" or "uif" methods
ugh (for non-numeric
single-valued field) I think the situation you describe (high-cardinality
field, known low-cardinality for the particular domain) sounds like a
perfect use-case for dvhash.
Michael
On Fri, Feb 5, 2021 at 11:56 AM ufuk yılmaz
wrote:
> Hello,
>
> I’m using Solr 8.4
I'm not sure about _performance_, but I'm pretty sure you don't want to be
faceting on docValued SortableTextField (and faceting on non-docValued
SortableTextField, though I think technically possible, works against
uninverted _indexed_values, so ends up doing something entirely different):
EDIT: "the equivalent terms are separated by commas (as they should be)" =>
"the equivalent terms are _not_ separated by commas (as they should be)"
On Fri, Jan 15, 2021 at 10:09 AM Michael Gibney
wrote:
> Shaun,
>
> I'm not 100% sure, but don't give up on this
I know you're asking about nodes, not replicas; but depending on what
you're trying to achieve you might be as well off routing requests based on
replica. Have you considered the various options available via the
`shards.preference` param [1]? For instance, you could set up your "write"
replicas
s
meaning "DM == 'diabetes mellitus'", which iiuc _is_ what you want)?
(see the note about ensuring proper comma-separation in my earlier response)
Michael
On Fri, Jan 15, 2021 at 9:52 AM Shaun Campbell
wrote:
> Hi Michael
>
> Thanks for that I'll have a study later. It's just re
The equivalent terms on the right-hand side of the `=>` operator in the
example you sent should be separated by a comma. You mention you already
tried only-comma-separated (e.g. one line: `SRN,Stroke Research Network`)
and that that yielded unexpected results as well. I would recommend
ighlighter response. I tried using the same
syntax on the hl.fl param but with no success. Has anybody an idea on how to
achieve this?
Best regards
Michael Aleythe
upgrading if you have the (human) bandwidth to do so. Good luck!
Michael
On Tue, Jan 12, 2021 at 8:39 AM Jeremy Smith wrote:
> Thanks Michael,
> SOLR-13336 seems intriguing. I'm not a solr expert, but I believe
> these are the relevant sections from our schema definition:
>
>
Hi Jeremy,
Can you share your analysis chain configs? (SOLR-13336 can manifest in a
similar way, and would affect 7.3.1 with a susceptible config, given the
right (wrong?) input ...)
Michael
On Mon, Jan 11, 2021 at 5:27 PM Jeremy Smith wrote:
> Hello all,
> We have been stru
"type": "range",
"field": "t",
"sort": { "t": "asc" },
"start": "2018-05-02T17:00:00.000Z",
"end": "2020-11-16T2
Arturas,
I think your syntax is wrong for the range subfacet? -- the configuration
of the range facet should be directly under the `tt` key, rather than
nested under `t_buckets` in the request. (The response introduces a
"buckets" attribute that is not part of the request syntax).
Micha
ng
something?)
https://issues.apache.org/jira/browse/SOLR-14921
On Tue, Nov 17, 2020 at 11:00 AM Jason Gerlowski wrote:
>
> Thanks Michael,
>
> I agree - JSON Facets is a better candidate for the functionality I'm
> looking for. In my case specifically though, I think I'm pegged to
>
Answering a slightly different question perhaps, but you can
definitely do this with the "JSON Facet" API, where there's much
cleaner separation between different facets (and output is assigned to
arbitrary keys).
Michael
On Tue, Nov 17, 2020 at 9:36 AM Jason Gerlowski wrote:
an
> demonstrate need.
>
> If you issue a debug=timing you’ll see the time each component
> takes, and there’s a separate entry for faceting so that’ll give you
> a clue whether it’s worth the effort.
>
> Best,
> Erick
>
> > On Oct 30, 2020, at 8:10 AM, Michael Gibney
Michael, sorry for the confusion; I was positing a *hypothetical*
"exists()" function that doesn't currently exist, that *is* an
aggregate function, and the *does* stop early. I didn't account for
the fact that there's already an "exists()" function *query* that
behaves very
goryId:6061\" }, event:{ type : query, q:
\"+categoryId:21465\" }, poi:{ type : query, q:
\"+(+categoryId:6000 -categoryId:(6061 21493 8510))\" }, authors:{
type : query, q: \"+categoryId:(21205 21206)\" }, partners:{
type : query
, set stored=false, docValues=true,
useDocValuesAsStored=true, and achieve the desired behavior?
Michael
On Thu, Oct 29, 2020 at 6:17 AM Srinivas Kashyap
wrote:
>
> Thanks Dwane,
>
> I have a doubt, according to the java doc, the duplicates still continue to
> exist in the field
So trying to stop your facet query as soon
> as it matches a hit for the first time seems like an odd thing to do.
>
> So what’s the “X”? In other words, what is the problem you’re trying
> to solve at a high level? Perhaps there’s a better way to figure this
> out.
>
> Best,
uot;
Is there any possibility to modify my request to ensure that the facet
query stops as soon as it matches a hit for the first time?
Thanks!
Michael
I'm trying to get a simple text listing of my collections (so that I can do
some shell scripting loops [for example calling SOLR Cloud Backup on each]).
I'm getting an exception when I simply append the "=csv" to the end of the
collection's LIST api (eg:
(and only when sort=index).
So this is unlikely to help (though it's impossible to say without
more specific information about the actual requests you're trying to
run).
Michael
On Fri, Oct 23, 2020 at 12:52 AM wrote:
>
> Im dong a nested facet (
> https://lucene.apache.org/solr/g
Damien,
Are you able to share the actual json.facet request that you're using
(at least just the json.facet part)? I'm having a hard time being
confident that I'm correctly interpreting when you say "a json.facet
query on nested facets terms".
Michael
On Thu, Oct 22, 2020 at 3:52 AM
Hi all,
Hopefully someone can provide insight.
We are looking to see if there are any viable options for S3 or similar
for index/data storage.
Preferably (if possible) shared between nodes for dynamic scalability needs.
-Mike/NewsRx
inconsistent results, or attempt to
look up results via the equivalent of a "table scan" over docValues (I
think the last of these is what actually happens, fwiw) ... but none
of these options is likely desirable.
Michael
On Mon, Oct 19, 2020 at 1:42 PM uyilmaz wrote:
>
> Thanks! T
Thanks for the help everyone. I'm hopeful for the PR, Tomás. That looks to be
exactly what I was looking for!
Best,
Michael Carroll
On 9/11/20, 8:44 PM, "Tomás Fernández Löbbe" wrote:
*** External email: use caution ***
I created
htt
have to. If we can’t modify the configset
wholesale this way, is it possible to create a new configset and swap the old
collection to it?
Best,
Michael Carroll
(forgiving readability challenges) an
example of pre-parsed input that suffers particularly from performance
degradation?
On Thu, Aug 20, 2020 at 2:28 PM Elaine Cario wrote:
>
> Thanks Michael, I took a look, but we don't have any pf or pf1,2,3 phrase
> params set at all. Also, we don't add
.).
I'll be curious to hear what you find, and eager to be corrected if
the above speculation is off-base!
Michael
On Wed, Aug 19, 2020 at 10:56 AM Elaine Cario wrote:
>
> Hi Solr experts,
>
> We're in the process of upgrading SolrCloud from 6.4.2 to 8.3.1, and our
> performance tes
r nature of the "hub" and the
equivalent/final nature of the "spokes" in a way that
"primary/secondary" doesn't really; and it avoids implying an active
role in cluster maintenance for the "hub" (cf. "publisher", which
could be misleading in this regar
orthogonal to the "facet.method=enum"/filterCache discussion, as
tag/ex only affects the DocSet domain over which facets are calculated
... I think that step is pretty cleanly separated from the actual
calculation of the facets. I'm not 100% sure on that, so proceed with
caution, but it could def
ouldn't actually *do* anything,
but will help ensure that things are behaving as you expect them to!
Michael
On Wed, Jun 17, 2020 at 4:31 AM James Bodkin
wrote:
>
> Thanks, I've implemented some queries that improve the first-hit execution
> for faceting.
>
> Since turni
atic? More generally, it's of course true that Solr won't parse
this input as SQL, but as Isabelle pointed out, there are still
potentially lots of meta-characters (in addition to quite a few short,
common terms).
Michael
On Thu, Jun 11, 2020 at 7:43 AM Guilherme Viteri wrote:
>
> Hi I
,
Michael Aleythe
Team --(sr)^(ch)--
Java Entwickler | STERNWALD SYSTEMS GMBH
Fon +49 351 31 40 6010
Fax +49 351 31 40 6001
E-Mail michael.aley...@sternwald.com<mailto:michael.aley...@sternwald.com>
Skype michael.aley...@sternwald.com<mailto:michael.aley...@sternwald.com>
Web www.sternw
Hi Wei,
SOLR-14471 has been merged, so this issue should be fixed in 8.6.
Thanks for reporting the problem!
Michael
On Mon, May 11, 2020 at 7:51 PM Wei wrote:
>
> Thanks Michael! Yes in each shard I have 10 Tlog replicas, no other type
> of replicas, and each Tlog replica is an indivi
distributed requests.
On Mon, May 11, 2020 at 1:49 PM Michael Gibney
wrote:
>
> Wei, probably no need to answer my earlier questions; I think I see
> the problem here, and believe it is indeed a bug, introduced in 8.3.
> Will file an issue and submit a patch shortly.
> Michael
>
>
Wei, probably no need to answer my earlier questions; I think I see
the problem here, and believe it is indeed a bug, introduced in 8.3.
Will file an issue and submit a patch shortly.
Michael
On Mon, May 11, 2020 at 12:49 PM Michael Gibney
wrote:
>
> Hi Wei,
>
> In considering this
the
behavior is like on Solr 8.3? (there were different changes introduced
to potentially relevant code in 8.3 and 8.4, and knowing whether the
behavior you're observing manifests on 8.3 would help narrow down
where to look for an explanation).
Michael
On Fri, May 8, 2020 at 7:34 PM Wei wrote:
Depending on how you're measuring performance (and whether your use case
benefits from caching), it might be worth looking into stable replica
routing (configured with the "replica.base" sub-parameter of the
shards.preference
not.
Thanks for your help!
Michael Cooper
experience. I hope that
these Trie fields are going to stay in the product for Solr 9, I know they were
supposed to be removed in Solr 8 but there must have been a reason they were
not.
Michael Cooper
There are many layers to this, but for the config you posted (applying
index-time WDGF configured to both split and catentate tokens), the
fundamental issue is that Lucene doesn't index positionLength, so the
graph structure (and token adjacency information) of the token stream
is lost when it's
t;
Closed:
https://issues.apache.org/jira/browse/SOLR-12011
https://issues.apache.org/jira/browse/SOLR-9366
Cheers,
Michael
Am Do., 13. Feb. 2020 um 19:19 Uhr schrieb Chris Hostetter <
hossman_luc...@fucit.org>:
>
> : We think this is a bug (silently dropping commits even if the client
&g
LID_STATE,
"Cluster is in degraded state -
not all replicas acknowledged the commit."
+ achievedRF + "/" +replicaRoutes.size());
}
}
Cheers
Michael
Am Do., 6. Feb. 2020 um 12:18 Uhr schrieb Michae
Possibly worth mentioning, although it might not be appropriate for
your use case: if the fields you're interested in are configured with
docValues, you could use streaming expressions (or directly handle
thread-per-shard connections to the /export handler) and get
everything in a single shot
plica - so technically we could
reproduce the error in a two node cluster.
Cheers,
Michael
Am Do., 6. Feb. 2020 um 01:42 Uhr schrieb Chris Hostetter <
hossman_luc...@fucit.org>:
>
> I may be missunderstanding something in your setup, and/or I may be
> miss-remembering thing
y other value
- Errors appear to happen more frequently if we have more load (more
collections with the same test)
Cheers,
Michael
SOLR-13807
Michael
On Wed, Jan 22, 2020 at 7:16 AM Toke Eskildsen wrote:
>
> On Sun, 2020-01-19 at 21:19 -0500, Mehai, Lotfi wrote:
> > I had a similar issue with a large number of facets. There is no way
> > (At least I know) your can get an acceptable response time from
> &
not supporting the
MaxPermSize parameter.. So I have reverted to 32 bit and Solr runs fine for
searches but I cannot do updates to the cores.
Can anybody with experience of this please assist?
Regards
Michael
the systemwide setting (configured via solr.xml),
a warning message will be logged, but the attempted configuration will
otherwise have no affect (the lower systemwide value will still be the
effective limit).
Michael
On Wed, Dec 18, 2019 at 9:48 PM Nick D wrote:
>
> Michael,
>
> Thank
queries (which
in your case sounds like most queries?) (see SOLR-13336)
Michael
On Tue, Dec 17, 2019 at 4:16 PM Nick D wrote:
>
> Hello All,
>
> We recently upgraded from Solr 6.6 to Solr 7.7.2 and recently had spikes in
> memory that eventually caused either an OOM or almost 1
I wonder if this might be similar/related to the underlying problem
that is intended to be addressed by
https://issues.apache.org/jira/browse/LUCENE-8985?
btw, I think you only want to use FlattenGraphFilter *once* in the
indexing analysis chain, towards the end (after all components that
emit
I was able to resolve this. I had left out the trailing "/" from the filepath,
so Solr wasn't seeing it as a local directory.
On 11/19/19, 2:45 AM, "Dominique Bejean" wrote:
Hi Michael,
It seems Sorl really don't find any solrconfig.xml file or a
conf
-5F4_configsets-2Dapi.html=DwIFaQ=mV61MqUbMWY-LlirxZJvJg=8W5Kk7fJg_C2taHlYyXZLinEFeEtcUcFddYrS5aUhiE=czV2n50m-v9_w3N63i-jYUsBfnCtCKeE3wNXq3KVerU=8GQix9ABHkY0tm7kPKL_GEXCi-G4PKRjJjN-FqQcRVI=
> Am 18.11.2019 um 15:48 schrieb Michael Becker :
>
> I’ve run into an issue when attempting to
command is appending local directory to default confdir
Hi Michael,
It seems Sorl really don't find any solrconfig.xml file or a
conf/solrconfig.xml file in the local path you specified. The last try is to
look in "/opt/solr-6.5.1/server/solr/configsets/", but obviously it doesn't work has
I’ve run into an issue when attempting to configure Zookeeper. When running the
zk upconfig -d command specifying a local directory where the solrconfig.xml
files are located, I get the following error:
“Could not complete upconfig operation for reason: Could not find
solrconfig.xml at
?
I’m trying to simulate data, Index that would trigger, result in this type of
ShardRequest
Michael
Going to back to the initial question, the wording is a little ambiguous
and it occurs to me that it's possible there's a misunderstanding of what
autoGeneratePhraseQueries does. It really only auto-generates phrase
*subqueries*. To use the example from the initial request, a query like
(black
.
___
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
(203) 931-5381 - mobile
http://web.yale.edu <http://web.yale.edu/>
On 9/9/19, 6:53 AM, "Vadim Ivanov" wrote:
Hi,
Latest jdbc driver 7.4.1
, but I try not to run very old versions of any software.
2. Is there a way to fix this and keep the installation out-of-the-box or at
least almost out of the box?
___
Michael Friscia
Office of Communications
Yale School of Medicine
(203) 737-7932 - office
We pass ExecutorService to Lucene's IndexSearcher at Amazon (for customer
facing product search) and it's a big win on long-pole query latencies, but
hurts red-line QPS (cluster capacity) a bit, due to less efficient
collection across segments and thread context switching.
I'm surprised it's not
https://lucene.apache.org/solr/guide/8_1/distributed-requests.html#configuring-the-shardhandlerfactory
Michael
On Fri, Aug 16, 2019 at 9:40 AM Shawn Heisey wrote:
> On 8/16/2019 3:51 AM, Mark Robinson wrote:
> > I am trying to understand the socket time out and conne
That is the way we do it here - also helps a lot with not needing x2 or
x3 disk space to handle the merge:
public void solrOptimize() {
int initialMaxSegments = 256;
int finalMaxSegments = 4;
if (isShowSegmentCounter()) {
log.info("Optimizing ...");
}
Very likely: https://issues.apache.org/jira/browse/SOLR-13336
Individual queries should still fail, but should fail fast, without
the broader impact seen prior to 8.1.
Does that describe the behavior you're seeing now with 8.1.1?
Michael
On Thu, May 30, 2019 at 11:55 AM Markus Jelsma
wrote
Is it possible set up an existing SolrCloud cluster as the master for
legacy replication to a slave server or two? It looks like another option
is to use Uni-direction CDCR, but not sure what is the best option in this
case.
--
Michael Tracey
ld
both be evaluated before ("a" "b"), leaving the impression of a gap
between tokens, causing the match to be missed.
On Fri, May 17, 2019 at 12:29 PM Michael Gibney
wrote:
>
> The SpanNearQuery in association with "a.b." input and WDGF is
> expected behav
The SpanNearQuery in association with "a.b." input and WDGF is
expected behavior, since WDGF causes the query to search ("ab")|("a"
"b"), as 1 or 2 tokens, respectively. The "a. b." input
(whitespace-separated) is tokenized simply as "a" "b" (2 tokens) so
sticks with the more straightforward
Hello,
Indeed, you cosmetic fix looks great -- I'll push that change. Thanks for
noticing and raising!
Mike McCandless
http://blog.mikemccandless.com
On Tue, Apr 16, 2019 at 12:04 AM zhenyuan wei wrote:
> Hi，
>With current newest version, 9.0.0-snapshot，In
>
Hi everybody,
is it correct that local parameters ( q={!edismax qf=MEDIA_ID v=283813390} ) in
solr only work with the lucene query parser defined for the main query? I tried
with dismax/edismax but it did not work. The documentation is not clear on this
point.
Best regards
Michael Aleythe
the
performance of main query only (i.e., no other components, like facets,
etc.)?
Michael
On Mon, Apr 8, 2019 at 3:28 AM Ash Ramesh wrote:
> Hi Toke,
>
> Thanks for the prompt reply. I'm glad to hear that this is a common
> problem. In regards to stop words, I've been thinking about trying that
&
lelize query processing to a certain extent, which I expect might
speed things up for your use case.
On Fri, Mar 29, 2019 at 1:13 PM Erie Data Systems
wrote:
> Michael,
>
>
> select/?=12=title+description=once+upon+a+time+in+the+west=*=true=desc=250=20=1=1=title=2=edismax=off=on=json=tru
Can you post the query that's actually built for some of these inputs
("parsedquery" or "parsedquery_toString" output included for requests with
"debug=query" parameter)? What is performance like if you turn off pf
(i.e., no implicit phrase searching)?
Michael
On
Would you be willing to share your query-time analysis chain config, and
perhaps the "debug=true" (or "debug=query") output for successful queries
of a similar nature to the problematic ones? Also, re: "only times out on
extreme queries" -- what do you consider to be an "extreme query", in this
I'll second Emir's suggestion to try disabling swap. "I doubt swap would
affect it since there is such huge free memory." -- sounds reasonable, but
has not been my experience, and the stats you sent indicate that swap is in
fact being used. Also, note that in many cases setting vm.swappiness=0 is
Are you basing your conclusion (that it's not working as expected) on the
scores as reported in the debug output? If you haven't already, try adding
"score" to the "fl" param -- if different (for a given doc) than the score
as reported in debug, then it's probably working as intended ... just a
Tangentially related, possibly of interest regarding solr-internal cache
hit ratio (esp. with a lot of replicas):
https://issues.apache.org/jira/browse/SOLR-13257
On Mon, Feb 25, 2019 at 11:33 AM Walter Underwood
wrote:
> Don’t worry about one and two character queries, because they will almost
of problematic
queries (and perhaps relevant analysis chain configs)?
Michael
On Fri, Feb 22, 2019 at 11:00 AM Gregg Donovan wrote:
> FWIW: we have also seen serious Query of Death issues after our upgrade to
> Solr 7.6. Are there any open issues we can watch? Is Markus' findings
> around
or another method?
Thanks, Michael
where slop>0, so setting ps=0 would
probably also help.
Michael
On Fri, Feb 8, 2019 at 5:57 AM Markus Jelsma
wrote:
> Hello (apologies for cross-posting),
>
> While working on SOLR-12743, using 7.6 on two nodes and 7.2.1 on the
> remaining four, we stumbled upon a situation
Hey Erik,
thanks a lot for your suggestion. It lead me on the rigth path. What actually
did the trick was, sending the tab as unicode:
IPTC_2_080_KY:"\u0009bus\u0009bahn" matched perfectly.
Best,
Michael
-Ursprüngliche Nachricht-
Von: Erick Erickson
Gesendet: Dienstag, 11
tbahn and " bus bahn" but nothing matches. Does
anybody know what to do?
Regards
Michael
work with the update processor. (NOTE: the cast happens for
Solr 7.5 as well)
Can you suggest a way so that I can get notification when a new field is added
into schema.?
Thank you for your help!
--Michael
Would you supply the snippet for the custom HttpClient to get it to
honor/use proxy?
Thanks!
On 10/10/2018 10:50 AM, Andreas Hubold wrote:
Thank you, Shawn. I'm now using a custom HttpClient that I create in a
similar manner as SolrJ, and it works quite well.
Of course, a fix in a future
should I be looking at?
Thanks,
Michael
Is there an easy way to compare schemas?
When upgrading nodes, we are wanting to compare the "core" and
"automatically mapped" data types between our existing schema and the
new manage-schema available as part of the upgraded distrubtion.
correctly, otherwise NEW CENTURY BANCORP, INC.
would match CENTURY BANCORP, INC..
-Michael
Am 21.09.2018 um 15:00 schrieb marotosg:
> Hi,
>
> I have to search for company names where my first requirement is to find
> only exact matches on the company name.
>
> For instance if I sear
expected.
Thanks,
Michael
-Ursprüngliche Nachricht-
Von: Shawn Heisey
Gesendet: Freitag, 7. September 2018 17:58
An: solr-user@lucene.apache.org
Betreff: Re: Solr 7.4 and log4j2 JSONLayout
On 9/6/2018 7:46 AM, Michael Aleythe, Sternwald wrote:
> I'm trying to edit the log4j2 logg
Hey,
I tried solr/server/lib/ext and solr/server/lib. I also tried without them but
it doesn't change anything.
Best regards
Michael
-Ursprüngliche Nachricht-
Von: Varun Thacker
Gesendet: Donnerstag, 6. September 2018 16:23
An: solr-user@lucene.apache.org
Betreff: Re: Solr 7.4
st regards
Michael Aleythe
Michael Aleythe
Team --(sr)^(ch)--
Java Entwickler | STERNWALD SYSTEMS GMBH
Fon +49 351 31 40 6010
Fax +49 351 31 40 6001
E-Mail michael.aley...@sternwald.com
Skype michael.aley...@sternwald.com
Web www.sternwald.com
STERNWALD SYSTEMS GMBH
Pohlandstraße 19, 01309 Dresde
Can someone advise me how to solve this issue, please?
Thank you so much!
--Michael
From: Michael Hu (CMBU)
Sent: Friday, August 17, 2018 1:22 PM
To: solr-user@lucene.apache.org
Cc: Mohsin Beg
Subject: Re: Solr core corrupted for version 7.4.0, please help
Can someone advise me how to solve this issue?
Thank you!
--Michael
From: Michael Hu (CMBU)
Sent: Thursday, August 16, 2018 6:14 PM
To: solr-user@lucene.apache.org
Cc: Mohsin Beg
Subject: Solr core corrupted for version 7.4.0, please help!
Environment
dvise how to resolve this issue?
Thank you so much!
--Michael
stack trace:
2018-08-16 23:02:31.212 ERROR (qtp225472281-4098) [
x:aggregator-core-be43376de27b1675562841f64c498] o.a.s.u.SolrIndexWriter Error
closing IndexWriter
java.nio.file.NoSuchFileException:
/opt/solr/volumes/data1/4cf8
1 - 100 of 1917 matches
Mail list logo
