or disrupt operations in the Solr
> cluster.
>
> The vulnerability is fixed from Solr 6.6.1 onwards.
>
> Mitigation:
> 6.x users should upgrade to 6.6.1
>
> Credit:
> This issue was discovered by Hrishikesh Gadre of Cloudera Inc.
>
> References:
> https://issues.apac
Hi, wanted to check if anyone can help guide with most stable version
between
6.3 and 6.6.1
Which should I choose ?
And, are there any performance tests that one can look at for each release?
Regards
Lars
ng:
>
> - Client timeouts whenever a solr pod stops and starts again, we currently
> try to solve this with better readiness probes, no success yet
> - Sometimes solr collections do not recover completely after a pod restart
> and we manually have to force recovery, still not investigated
Hi, I wanted to hear if anyone successfully got solr cloud running on
kubernetes and can share challenges and limitations.
Can't find much uptodate github projects, would be great if you can point
out blogposts or other useful links.
Thanks in advance.
Newest docs:
https://lucene.apache.org/solr/guide/6_6/securing-solr.html
On Wed, 23 Aug 2017 at 19:20, Lars Karlsson
wrote:
> Such setup is not supported, interfering inter node communication, start
> here on how to secure Solr:
>
> https://cwiki.apache.org/confluence/display/s
Such setup is not supported, interfering inter node communication, start
here on how to secure Solr:
https://cwiki.apache.org/confluence/display/solr/Securing+Solr
On Wed, 23 Aug 2017 at 14:41, Scott Stults <
sstu...@opensourceconnections.com> wrote:
> Radhakrishnan,
>
> I'm not sure offhand whe
Agree, but saying
"but Solr is generally not considered to be durable across crashes or kill
-9."
Such statements are misleading, even Cassandra can loose data in such case.
and talking about RDBMS and ACID = non scalable persistence and dealing
with replication hell.
On Sat, 12 Aug 2017 at 17:
Yet another reason to stick to Solr:
https://aphyr.com/posts/323-call-me-maybe-elasticsearch-1-5-0
On Mon, 7 Aug 2017 at 15:40, Charlie Hull wrote:
> On 05/08/2017 12:28, GW wrote:
> > For The Guardian, Solr is the new database | Lucidworks
> > <
> https://www.google.ca/url?sa=t&rct=j&q=&esrc=s
I doubt your statement, you can learn more about why you should prefer Solr
here:
https://aphyr.com/posts/322-call-me-maybe-mongodb-stale-reads
On Sat, 5 Aug 2017 at 01:16, Francesco Viscomi wrote:
> Hi all,
> why i have to choose solr if mongoDb is easier to learn and to use?
> Both are NoSql
Can you reproduce with 4G heap?
On Wed, 26 Jul 2017 at 23:11, Markus Jelsma
wrote:
> Hello Mikhail,
>
> Spot on, there is indeed not enough heap when our nodes are in this crazy
> state. When the nodes are happy, the average heap consumption is 50 to 60
> percent, at peak when indexing there is
Another option that I normally find easier is attaching to existing Solr
instance and do remote debugging.
It require changing the JVM options and restarting Solr, then from eclipse
choose Remote Java Application.
On Thu, 13 Jul 2017 at 19:50, Rainer Gnan
wrote:
> Hello community,
>
> my aim is
; >> 2> indexing continues
> >> 3> the network glitch repairs itself
> >> 4> the Solr instance reconnects.
> >> 5> the index is synchronized if necessary
> >>
> >> Anyone else wants to chime in?
> >>
> >>
> >> Be
er and when it goes "active", then it should again start serving
> queries.
>
> Best,
> Erick
>
> On Thu, Jul 6, 2017 at 2:04 PM, Lars Karlsson
> wrote:
> > Hi all, please help clarify how solr will handle network segmented
> replica
> > meanwhile c
Hi all, please help clarify how solr will handle network segmented replica
meanwhile configuration and reload of cores/nodes for one collection is
applied?
Does the replica become part of the collection after connectivity is
restored?
Hence the node is not down, but lost ability to communicate to
14 matches
Mail list logo
