I would like to back port SOLR-13285 also . It seems to affect a few people
On Fri, Mar 8, 2019 at 5:36 AM Uwe Schindler <u...@thetaphi.de> wrote: > > Hi > > > > Thanks for the clarification, that’s exactly how I understood that. The > “solr.http1” flag is just there to make new nodes use HTTP/1.1 to talk to > others temporarily, as this is the common protocol all nodes understand > during a rolling upgrade. The new nodes understand HTTP/2 always, regarless > of this flag. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > From: Đạt Cao Mạnh <caomanhdat...@gmail.com> > Sent: Thursday, March 7, 2019 6:47 PM > To: Solr/Lucene Dev <dev@lucene.apache.org> > Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2 > > > > For clarification: > > But this does not disable the HTTP/2 listener, it just makes SolrJ no longer > use the Http2SolrClient and fall back to the old one. > > This is true and it is not a bug. The reason here is for rolling updates, > since -Dsolr.http1=true nodes can send and accept requests to/from Solr 7.x > and Solr 8 without that flag. As I mentioned in CHANGES.txt for rolling > updates > > Step 1. Some nodes wil be upgraded to Solr 8 with -Dsolr.http1=true, the rest > will still remain on Solr 7.x. They can communicate to each others since only > HTTP/1 is used > > Step 2. All nodes get upgraded to Solr 8 with -Dsolr.http1=true. > > Step 3. Some nodes with -Dsolr.http1=true (A) and the rest (B) without that > flag. A will talk with B using HTTP/1 (possible) and B will talk with A using > HTTP/2 (since HTTP/2 listener is enabled in -Dsolr.http1=true nodes) > > Step 4: All nodes get upgraded to Solr 8 without solr.http1 flag. They will > talk with each other using HTTP/2 now. > > > > On Thu, Mar 7, 2019 at 4:32 PM Uwe Schindler <u...@thetaphi.de> wrote: > > Thanks for the reminder, > > > > I think, you can pass the mentioned “-Dsolr.http1=true” parameter in the > startup script. But this does not disable the HTTP/2 listener, it just makes > SolrJ no longer use the Http2SolrClient and fall back to the old one. But > that only affects the “new” solr servers as a “client” to old servers during > rolling upgrade. > > > > I did a quick check, if the parameter makes its way to solr: yes, after > starting solr with “-Dsolr.http1=true”: > > C:\..\solr-8.0.0\bin>solr start -e techproducts -Dsolr.http1=true > > … it showed the parameter in admin UI under system properties. > > > > But I did not test a full cluster in the short time. The HTTP/2 endpoint of > the started server was still available, but outgoing solr requests should > only go with HTTP1 then. I am sure somebody tested this in Linux, Windows is > same as the system property reached the JVM, so startup scripts handle it > right. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > From: Alan Woodward <romseyg...@gmail.com> > Sent: Thursday, March 7, 2019 9:17 AM > To: dev@lucene.apache.org > Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2 > > > > Is there a way of passing Jetty parameters from the command line? IOW, can > Windows users do a rolling upgrade if they run ./solr restart > -Djetty.module=http or whatever? > > > > On 6 Mar 2019, at 21:57, Uwe Schindler <u...@thetaphi.de> wrote: > > > > I opened a blocker issue: > > https://issues.apache.org/jira/browse/SOLR-13299 > > > > The fix is easy, will commit it soon to all 3 branches. > > > > IMHO, we should respin as non-working startup script on Windows for users of > secured Solr servers is a blocker. > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > From: Uwe Schindler <u...@thetaphi.de> > Sent: Wednesday, March 6, 2019 8:52 PM > To: dev@lucene.apache.org > Subject: RE: [VOTE] Release Lucene/Solr 8.0.0 RC2 > > > > It looks like on Linux the Solr start script correctly sets module in jetty, > so it disables http2 on Java 8. I have not tested this but it looks like on > Windows the if statement is missing. > > If we cannot fix this soon we may release a Bugfix Version later, but this > would prevent Windows users from upgrading. > > So I switch to +/-0 to release. What do others think? > > I will try to fix startup script later, maybe it's easy. > > Uwe > > Am March 6, 2019 7:21:34 PM UTC schrieb Uwe Schindler <u...@thetaphi.de>: > > Hi, > > > > I also checked the RC2. First automated smoke testing with Policeman Jenkins > resulted in a +1 from Policeman Jenkins: > > > > https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console > > SUCCESS! [2:42:28.295475] > > > > The testing was done with Java 8 and Java 9 (this is why it took longer). > > > > I also checked Changes.txt, looks fine (there is only a few typos in the > changes about the switch of Solr to HTTP/2, but that’s not horrible, but we > should improve it, as its one significant change): latter -> later > > > > I also checked the ZIP files of Lucene and Solr. Lucene looks as usual, > MIGRATE.txt is also fine – thanks for adding recent information! JAR files > also look fine, compiled with correct version of Java and patches > multi-release class files are there. > > > > Apache Solr was unzipped and quickly tested on Windows: Startup with Java 8 > and Java 11 worked without any problems from a directory with whitespace in > path. I was able to do a HTTP/2 request with CURL (non-TLS) on both O/S: > > > > Uwe Schindler@VEGA:~ > curl -I --http2 localhost:8983/solr/ > > HTTP/1.1 101 Switching Protocols > > > > HTTP/2 200 > > x-frame-options: DENY > > content-type: text/html;charset=utf-8 > > content-length: 14662 > > > > So, it worked. In the webbrowser it did not use HTTP/2, as browsers require > SSL for that (by default). > > > > Next I enabled TLS support by creating a keystore. Unfortunately Solr did not > start with Java 8. According to the documentation it should still start, but > disable HTTP/2 by default. But it complained about no ALPN processors: > > > > Waiting up to 30 to see Solr running on port 8983 > > java.lang.reflect.InvocationTargetException > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > at java.lang.reflect.Method.invoke(Method.java:498) > > at org.eclipse.jetty.start.Main.invokeMain(Main.java:220) > > at org.eclipse.jetty.start.Main.start(Main.java:490) > > at org.eclipse.jetty.start.Main.main(Main.java:77) > > Caused by: java.security.PrivilegedActionException: > java.lang.reflect.InvocationTargetException > > at java.security.AccessController.doPrivileged(Native Method) > > at > org.eclipse.jetty.xml.XmlConfiguration.main(XmlConfiguration.java:1511) > > ... 7 more > > Caused by: java.lang.reflect.InvocationTargetException > > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native > Method) > > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > > at java.lang.reflect.Constructor.newInstance(Constructor.java:423) > > at org.eclipse.jetty.util.TypeUtil.construct(TypeUtil.java:663) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:858) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newArray(XmlConfiguration.java:936) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1313) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.newObj(XmlConfiguration.java:842) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.itemValue(XmlConfiguration.java:1309) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.value(XmlConfiguration.java:1214) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.access$500(XmlConfiguration.java:326) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1442) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration$AttrOrElementNode.getList(XmlConfiguration.java:1417) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.call(XmlConfiguration.java:780) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:472) > > at > org.eclipse.jetty.xml.XmlConfiguration$JettyXmlConfiguration.configure(XmlConfiguration.java:413) > > at > org.eclipse.jetty.xml.XmlConfiguration.configure(XmlConfiguration.java:311) > > at > org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1558) > > at > org.eclipse.jetty.xml.XmlConfiguration$1.run(XmlConfiguration.java:1512) > > ... 9 more > > Caused by: java.lang.IllegalStateException: No Server ALPNProcessors! > > at > org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.<init>(ALPNServerConnectionFactory.java:53) > > ... 32 more > > Suppressed: java.lang.UnsupportedClassVersionError: > org/eclipse/jetty/alpn/java/server/JDK9ServerALPNProcessor has been compiled > by a more recent version of the Java Runtime (class file version 53.0), this > version of the Java Runtime only recognizes class file versions up to 52.0 > > at java.lang.ClassLoader.defineClass1(Native Method) > > at java.lang.ClassLoader.defineClass(ClassLoader.java:763) > > at > java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) > > at > java.net.URLClassLoader.defineClass(URLClassLoader.java:467) > > at java.net.URLClassLoader.access$100(URLClassLoader.java:73) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:368) > > at java.net.URLClassLoader$1.run(URLClassLoader.java:362) > > at java.security.AccessController.doPrivileged(Native Method) > > at java.net.URLClassLoader.findClass(URLClassLoader.java:361) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:424) > > at java.lang.ClassLoader.loadClass(ClassLoader.java:357) > > at java.lang.Class.forName0(Native Method) > > at java.lang.Class.forName(Class.java:348) > > at > java.util.ServiceLoader$LazyIterator.nextService(ServiceLoader.java:370) > > at > java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:404) > > at java.util.ServiceLoader$1.next(ServiceLoader.java:480) > > at > org.eclipse.jetty.alpn.server.ALPNServerConnectionFactory.<init>(ALPNServerConnectionFactory.java:60) > > ... 32 more > > > > …and Solr did not start. Also passing “-Dsolr.http1=true” did not help. So > it’s impossible to start TLS-enabled Solr with Java 8. > > > > With Java 11, it started perfectly and my curl test worked: > > > > Uwe Schindler@VEGA:~ > curl -k -I --http2 https://localhost:8983/solr/ > > HTTP/2 200 > > x-frame-options: DENY > > content-type: text/html;charset=utf-8 > > content-length: 14662 > > > > I also checked in Chrome browser, this time it uses HTTP/2 to communicate > with the admin interface. Fine! > > > > -1 to release unless the Solr startup scripts automatically disable the > HTTP/2 support on Java 8! > > > > Uwe > > > > ----- > > Uwe Schindler > > Achterdiek 19, D-28357 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > From: jim ferenczi <jim...@apache.org> > Sent: Wednesday, March 6, 2019 3:37 AM > To: dev@lucene.apache.org > Subject: [VOTE] Release Lucene/Solr 8.0.0 RC2 > > > > Please vote for release candidate 2 for Lucene/Solr 8.0.0 > > The artifacts can be downloaded from > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e > You can run the smoke tester directly with this command: > python3 -u dev-tools/scripts/smokeTestRelease.py > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e > > Here’s my +1 > > SUCCESS! [0:56:39.854444] > > > -- > Uwe Schindler > Achterdiek 19, 28357 Bremen > https://www.thetaphi.de > > > > > > > -- > > Best regards, > > Cao Mạnh Đạt > > D.O.B : 31-07-1991 > Cell: (+84) 946.328.329 > E-mail: caomanhdat...@gmail.com -- ----------------------------------------------------- Noble Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
