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
>

Reply via email to