Adrien and Cao reviewed the patch so I am going to merge and backport to 8.0. I'll build a new RC with the fix and initiate a new vote later today. We can consider this vote as closed and not passing.
Le jeu. 7 mars 2019 à 09:20, jim ferenczi <jim.feren...@gmail.com> a écrit : > Thanks for testing Uwe. Let's build a RC3 if the fix is ready. You can > ping me when the merge is done and I'll build a new RC, what do you think ? > > Le mer. 6 mars 2019 à 22:57, Uwe Schindler <u...@thetaphi.de> a écrit : > >> 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 >> >
