You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by jim ferenczi <ji...@apache.org> on 2019/03/06 02:37:24 UTC
[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]
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Kevin Risden <kr...@apache.org>.
+1
SUCCESS! [1:24:46.307985]
Kevin Risden
On Wed, Mar 6, 2019 at 6:09 AM Ignacio Vera <iv...@gmail.com> wrote:
> +1
>
>
> SUCCESS! [1:18:56.419526]
>
> On Wed, Mar 6, 2019 at 11:53 AM Adrien Grand <jp...@gmail.com> wrote:
>
>> +1
>> Smoke tester passed.
>> Changes look good.
>> Lucene javadocs look good.
>> I'm getting a warning on the Solr javadocs due to the fact that
>> checkJavaDocs.py noticed that
>>
>> solr/contrib/analytics/src/java/org/apache/solr/analytics/plugin/package-info.java
>> has a title but no description, I don't think it requires a respin
>> though it would be nice to address it for the next release.
>>
>> On Wed, Mar 6, 2019 at 11:40 AM Andrzej Białecki
>> <an...@lucidworks.com> wrote:
>> >
>> > +1
>> >
>> > SUCCESS! [1:22:21.262768]
>> >
>> > On 6 Mar 2019, at 03:37, jim ferenczi <ji...@apache.org> wrote:
>> >
>> > 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]
>> >
>> >
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Ignacio Vera <iv...@gmail.com>.
+1
SUCCESS! [1:18:56.419526]
On Wed, Mar 6, 2019 at 11:53 AM Adrien Grand <jp...@gmail.com> wrote:
> +1
> Smoke tester passed.
> Changes look good.
> Lucene javadocs look good.
> I'm getting a warning on the Solr javadocs due to the fact that
> checkJavaDocs.py noticed that
>
> solr/contrib/analytics/src/java/org/apache/solr/analytics/plugin/package-info.java
> has a title but no description, I don't think it requires a respin
> though it would be nice to address it for the next release.
>
> On Wed, Mar 6, 2019 at 11:40 AM Andrzej Białecki
> <an...@lucidworks.com> wrote:
> >
> > +1
> >
> > SUCCESS! [1:22:21.262768]
> >
> > On 6 Mar 2019, at 03:37, jim ferenczi <ji...@apache.org> wrote:
> >
> > 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]
> >
> >
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Adrien Grand <jp...@gmail.com>.
+1
Smoke tester passed.
Changes look good.
Lucene javadocs look good.
I'm getting a warning on the Solr javadocs due to the fact that
checkJavaDocs.py noticed that
solr/contrib/analytics/src/java/org/apache/solr/analytics/plugin/package-info.java
has a title but no description, I don't think it requires a respin
though it would be nice to address it for the next release.
On Wed, Mar 6, 2019 at 11:40 AM Andrzej Białecki
<an...@lucidworks.com> wrote:
>
> +1
>
> SUCCESS! [1:22:21.262768]
>
> On 6 Mar 2019, at 03:37, jim ferenczi <ji...@apache.org> wrote:
>
> 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]
>
>
--
Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Andrzej Białecki <an...@lucidworks.com>.
+1
SUCCESS! [1:22:21.262768]
> On 6 Mar 2019, at 03:37, jim ferenczi <ji...@apache.org> wrote:
>
> 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 <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 <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e/>
>
> Here’s my +1
> SUCCESS! [0:56:39.854444]
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Alan Woodward <ro...@gmail.com>.
+1
SUCCESS! [1:40:54.194706]
> On 6 Mar 2019, at 02:37, jim ferenczi <jimczi@apache.org <ma...@apache.org>> wrote:
>
> 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 <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 <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e/>
>
> Here’s my +1
> SUCCESS! [0:56:39.854444]
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by jim ferenczi <ji...@gmail.com>.
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 <ji...@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 <uw...@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: uwe@thetaphi.de
>>
>>
>>
>> *From:* Uwe Schindler <uw...@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 <uw...@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: uwe@thetaphi.de
>>
>>
>>
>> *From:* jim ferenczi <ji...@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
>>
>
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by jim ferenczi <ji...@gmail.com>.
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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* Uwe Schindler <uw...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* jim ferenczi <ji...@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
>
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Noble Paul <no...@gmail.com>.
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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: Đạt Cao Mạnh <ca...@gmail.com>
> Sent: Thursday, March 7, 2019 6:47 PM
> To: Solr/Lucene Dev <de...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: Alan Woodward <ro...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: Uwe Schindler <uw...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: jim ferenczi <ji...@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: caomanhdat317@gmail.com
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <http://www.thetaphi.de/>
eMail: uwe@thetaphi.de
From: Đạt Cao Mạnh <ca...@gmail.com>
Sent: Thursday, March 7, 2019 6:47 PM
To: Solr/Lucene Dev <de...@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 <uwe@thetaphi.de <ma...@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 <http://www.thetaphi.de/>
eMail: uwe@thetaphi.de <ma...@thetaphi.de>
From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com> >
Sent: Thursday, March 7, 2019 9:17 AM
To: dev@lucene.apache.org <ma...@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 < <ma...@thetaphi.de> uwe@thetaphi.de> wrote:
I opened a blocker issue:
<https://issues.apache.org/jira/browse/SOLR-13299> 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/> http://www.thetaphi.de
eMail: <ma...@thetaphi.de> uwe@thetaphi.de
From: Uwe Schindler < <ma...@thetaphi.de> uwe@thetaphi.de>
Sent: Wednesday, March 6, 2019 8:52 PM
To: <ma...@lucene.apache.org> 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 < <ma...@thetaphi.de> uwe@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> 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/> 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/> http://www.thetaphi.de
eMail: <ma...@thetaphi.de> uwe@thetaphi.de
From: jim ferenczi < <ma...@apache.org> jimczi@apache.org>
Sent: Wednesday, March 6, 2019 3:37 AM
To: <ma...@lucene.apache.org> 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> 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/> 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/> https://www.thetaphi.de
--
Best regards,
Cao Mạnh Đạt
D.O.B : 31-07-1991
Cell: (+84) 946.328.329
E-mail: <ma...@gmail.com> caomanhdat317@gmail.com
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Đạt Cao Mạnh <ca...@gmail.com>.
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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* Alan Woodward <ro...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* Uwe Schindler <uw...@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 <uw...@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: uwe@thetaphi.de
>
>
>
> *From:* jim ferenczi <ji...@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-1991Cell: (+84) 946.328.329E-mail: caomanhdat317@gmail.com
<ca...@gmail.com>*
RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <http://www.thetaphi.de/>
eMail: uwe@thetaphi.de
From: Alan Woodward <ro...@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 < <ma...@thetaphi.de> uwe@thetaphi.de> wrote:
I opened a blocker issue:
<https://issues.apache.org/jira/browse/SOLR-13299> 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/> http://www.thetaphi.de
eMail: <ma...@thetaphi.de> uwe@thetaphi.de
From: Uwe Schindler < <ma...@thetaphi.de> uwe@thetaphi.de>
Sent: Wednesday, March 6, 2019 8:52 PM
To: <ma...@lucene.apache.org> 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 < <ma...@thetaphi.de> uwe@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> 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/> 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/> http://www.thetaphi.de
eMail: <ma...@thetaphi.de> uwe@thetaphi.de
From: jim ferenczi < <ma...@apache.org> jimczi@apache.org>
Sent: Wednesday, March 6, 2019 3:37 AM
To: <ma...@lucene.apache.org> 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> 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/> 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/> https://www.thetaphi.de
Re: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Alan Woodward <ro...@gmail.com>.
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 <uw...@thetaphi.de> wrote:
>
> I opened a blocker issue:
> https://issues.apache.org/jira/browse/SOLR-13299 <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 <http://www.thetaphi.de/>
> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>
> From: Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>>
> Sent: Wednesday, March 6, 2019 8:52 PM
> To: dev@lucene.apache.org <ma...@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 <uwe@thetaphi.de <ma...@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 <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/ <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 <http://www.thetaphi.de/>
>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>
>> From: jim ferenczi <jimczi@apache.org <ma...@apache.org>>
>> Sent: Wednesday, March 6, 2019 3:37 AM
>> To: dev@lucene.apache.org <ma...@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 <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 <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 <https://www.thetaphi.de/>
RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <http://www.thetaphi.de/>
eMail: uwe@thetaphi.de
From: Uwe Schindler <uw...@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 <uwe@thetaphi.de <ma...@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/> http://www.thetaphi.de
eMail: uwe@thetaphi.de <ma...@thetaphi.de>
From: jim ferenczi <jimczi@apache.org <ma...@apache.org> >
Sent: Wednesday, March 6, 2019 3:37 AM
To: dev@lucene.apache.org <ma...@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> 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/> 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
RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Uwe Schindler <uw...@thetaphi.de>.
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 <uw...@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/> http://www.thetaphi.de
>
>eMail: uwe@thetaphi.de
>
>
>
>From: jim ferenczi <ji...@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>
>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/>
>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
RE: [VOTE] Release Lucene/Solr 8.0.0 RC2
Posted by Uwe Schindler <uw...@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/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: jim ferenczi <ji...@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> 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/> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.0.0-RC2-rev3d5c48ce0edbda1f43ed630911073cae3486df6e
Here’s my +1
SUCCESS! [0:56:39.854444]