Can you tell me where I could get insight into the testing cycles and results?
On Wed, Sep 26, 2018, 1:03 PM Erick Erickson <erickerick...@gmail.com> wrote: > There are consistent failures under JDK 11 in the automated tests that > Solr/Lucene runs that do not happen for other releases. I personally > haven't tried diving into them to know whether they're test artifacts > or not. > > JDK 9 and JKD 10 also have open issues, especially around Hadoop > integration. > > I would recommend sticking with JDK 8 for the time being, that's the > most tested/used version of Solr. Track > https://issues.apache.org/jira/browse/SOLR-12809 for what progress is > made with more recent Java versions. > > Best, > Erick > On Wed, Sep 26, 2018 at 8:44 AM Markus Jelsma > <markus.jel...@openindex.io> wrote: > > > > Indeed, but JDK-8038348 has been fixed very recently for Java 9 or > higher. > > > > -----Original message----- > > > From:Jeff Courtade <courtadej...@gmail.com> > > > Sent: Wednesday 26th September 2018 17:36 > > > To: solr-user@lucene.apache.org > > > Subject: Re: Java version 11 for solr 7.5? > > > > > > My concern with using g1 is solely based on finding this. > > > Does anyone have any information on this? > > > > > > > https://wiki.apache.org/lucene-java/JavaBugs#Oracle_Java_.2F_Sun_Java_.2F_OpenJDK_Bugs > > > > > > "Do not, under any circumstances, run Lucene with the G1 garbage > collector. > > > Lucene's test suite fails with the G1 garbage collector on a regular > basis, > > > including bugs that cause index corruption. There is no person on this > > > planet that seems to understand such bugs (see > > > https://bugs.openjdk.java.net/browse/JDK-8038348, open for over a > year), so > > > don't count on the situation changing soon. This information is not > out of > > > date, and don't think that the next oracle java release will fix the > > > situation." > > > > > > > > > On Wed, Sep 26, 2018 at 11:08 AM Walter Underwood < > wun...@wunderwood.org> > > > wrote: > > > > > > > We’ve been running G1 in prod for at least 18 months. Our biggest > cluster > > > > is 48 machines, each with 36 CPUs, running 6.6.2. We also run it on > our > > > > 4.10.4 master/slave cluster. > > > > > > > > wunder > > > > Walter Underwood > > > > wun...@wunderwood.org > > > > http://observer.wunderwood.org/ (my blog) > > > > > > > > > On Sep 26, 2018, at 7:37 AM, Jeff Courtade <courtadej...@gmail.com > > > > > > wrote: > > > > > > > > > > Thanks for that... > > > > > I am just starting to look at this I was unaware of the license > debacle. > > > > > > > > > > Automated testing up to 10 is great. > > > > > > > > > > I am still curious about the GC1 being supported now... > > > > > > > > > > On Wed, Sep 26, 2018 at 10:25 AM Zisis T. <zist...@runbox.com> > wrote: > > > > > > > > > >> Jeff Courtade wrote > > > > >>> Can we use GC1 garbage collection yet or do we still need to use > CMS? > > > > >> > > > > >> I believe you should be safe to go with G1. We've applied it in > in a > > > > Solr > > > > >> 6.6 cluster with 10 shards, 3 replicas per shard and an index of > about > > > > >> 500GB > > > > >> (1,5T counting all replicas) and it works extremely well > (throughput > > > > > >> 99%). > > > > >> The use-case includes complex search queries and faceting. > > > > >> There is also this post you can use as a starting point > > > > >> > > > > >> > > > > > http://blog.cloudera.com/blog/2017/06/apache-solr-memory-tuning-for-production/ > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> -- > > > > >> Sent from: > http://lucene.472066.n3.nabble.com/Solr-User-f472068.html > > > > >> > > > > > -- > > > > > > > > > > Jeff Courtade > > > > > M: 240.507.6116 <(240)%20507-6116> > > > > > > > > -- > > > > > > Jeff Courtade > > > M: 240.507.6116 > > > >
