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: u...@thetaphi.de

 

From: Alan Woodward <romseyg...@gmail.com> 
Sent: Thursday, March 7, 2019 9:17 AM
To: dev@lucene.apache.org
Subject: Re: [VOTE] Release Lucene/Solr 8.0.0 RC2

 

Is there a way of passing Jetty parameters from the command line?  IOW, can 
Windows users do a rolling upgrade if they run ./solr restart 
-Djetty.module=http or whatever?





On 6 Mar 2019, at 21:57, Uwe Schindler < <mailto:u...@thetaphi.de> 
u...@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:  <mailto:u...@thetaphi.de> u...@thetaphi.de

 

From: Uwe Schindler < <mailto:u...@thetaphi.de> u...@thetaphi.de> 
Sent: Wednesday, March 6, 2019 8:52 PM
To:  <mailto:dev@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 < 
<mailto:u...@thetaphi.de> u...@thetaphi.de>:

Hi,

 

I also checked the RC2. First automated smoke testing with Policeman Jenkins 
resulted in a +1 from Policeman Jenkins:

 

 <https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/15/console> 
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:  <mailto:u...@thetaphi.de> u...@thetaphi.de

 

From: jim ferenczi < <mailto:jim...@apache.org> jim...@apache.org> 
Sent: Wednesday, March 6, 2019 3:37 AM
To:  <mailto:dev@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

 

Reply via email to