Please confirm compatibility with Spring Boot 2.2

[snicoll]

We're heading towards an RC1 of Spring Boot 2.2 soon, followed by GA in Q4. Can you please confirm full compatibility of the starter with Spring Boot 2.2?

As soon as we hear from you, we can enable the starter again on start.spring.io, see spring-io/start.spring.io#266

Thanks!

[mehdi-vaadin]

I tried Spring Boot 2.2.0.M6. One problem that I have encountered is that spring-boot-maven-plugin doesn't shut down the Java process properly. So, the port is kept busy and I can't run it for the second time or for another module. It gives me this error:

[INFO] --- spring-boot-maven-plugin:2.2.0.M6:start (start-spring-boot) @ spring-skeleton ---
[INFO] Attaching agents: []
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 9001; nested exception is: 
	java.net.BindException: Address already in use (Bind failed)
sun.management.AgentConfigurationError: java.rmi.server.ExportException: Port already in use: 9001; nested exception is: 
	java.net.BindException: Address already in use (Bind failed)
	at sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:480)
	at sun.management.Agent.startAgent(Agent.java:262)
	at sun.management.Agent.startAgent(Agent.java:452)
Caused by: java.rmi.server.ExportException: Port already in use: 9001; nested exception is: 
	java.net.BindException: Address already in use (Bind failed)
	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:346)
	at sun.rmi.transport.tcp.TCPTransport.exportObject(TCPTransport.java:254)
	at sun.rmi.transport.tcp.TCPEndpoint.exportObject(TCPEndpoint.java:411)
	at sun.rmi.transport.LiveRef.exportObject(LiveRef.java:147)
	at sun.rmi.server.UnicastServerRef.exportObject(UnicastServerRef.java:236)
	at sun.rmi.registry.RegistryImpl.setup(RegistryImpl.java:213)
	at sun.rmi.registry.RegistryImpl.<init>(RegistryImpl.java:173)
	at sun.management.jmxremote.SingleEntryRegistry.<init>(SingleEntryRegistry.java:49)
	at sun.management.jmxremote.ConnectorBootstrap.exportMBeanServer(ConnectorBootstrap.java:816)
	at sun.management.jmxremote.ConnectorBootstrap.startRemoteConnectorServer(ConnectorBootstrap.java:468)
	... 2 more
Caused by: java.net.BindException: Address already in use (Bind failed)
	at java.net.PlainSocketImpl.socketBind(Native Method)
	at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
	at java.net.ServerSocket.bind(ServerSocket.java:375)
	at java.net.ServerSocket.<init>(ServerSocket.java:237)
	at java.net.ServerSocket.<init>(ServerSocket.java:128)
	at sun.rmi.transport.proxy.RMIDirectSocketFactory.createServerSocket(RMIDirectSocketFactory.java:45)
	at sun.rmi.transport.proxy.RMIMasterSocketFactory.createServerSocket(RMIMasterSocketFactory.java:345)
	at sun.rmi.transport.tcp.TCPEndpoint.newServerSocket(TCPEndpoint.java:666)
	at sun.rmi.transport.tcp.TCPTransport.listen(TCPTransport.java:335)
	... 11 more

It doesn't happen with 2.1.7.RELEASE. I checked it with the https://github.com/vaadin/skeleton-starter-flow-spring. We have the same problem with integration tests of Vaadin Spring add-on.

[denis-anisimov]

[INFO] --- spring-boot-maven-plugin:2.2.0.M6:start

But this is spring-boot-maven-plugin issue , isn't it ?
Spring boot itself is not related to to the plugin.
May be another version of the plugin can be used with the required Spring boot version.

[snicoll]

2.2 forks the process by default so that could be the reason. I don't really understand what you mean by "not stopping the server". Have you configured stop properly?

@denis-anisimov Spring Boot is related to this plugin and the version must match the Spring Boot version you're using.

[denis-anisimov]

@denis-anisimov Spring Boot is related to this plugin and the version must match the Spring Boot version you're using.

Ah, thanks for info. Good to know.

[mehdi-vaadin]

@snicoll I didn't say "not stopping the server" :). I'm saying "It doesn't shut down the Java process properly and the port 9001 is kept busy". Here is how we configure the plugin: https://github.com/vaadin/skeleton-starter-flow-spring/blob/master/pom.xml#L190

BTW, I just noticed that I provided an incorrect link to the start project. I fixed it.

[snicoll]

How can I reproduce?

[mehdi-vaadin]

I applied the required changes in a sample project here. So, with the following steps, you can reproduce it.

git clone git@github.com:mehdi-vaadin/skeleton-starter-flow-spring.git
cd skeleton-starter-flow-spring
mvn install -DskipTests
mvn verify -P integration-tests

And now, if you run mvn verify -P integration-tests for the second time, it shows the error.

[snicoll]

Thanks for the sample. The application does not seem to shutdown properly and I don't know yet if there is something we should/can do in the plugin itself.

Looking at your sample and the app that is still running after the first execution, I can see this

"webpack" #25 prio=5 os_prio=31 tid=0x00007fe705891000 nid=0x9d07 runnable [0x000070000282e000]
   java.lang.Thread.State: RUNNABLE
	at java.io.FileInputStream.readBytes(Native Method)
	at java.io.FileInputStream.read(FileInputStream.java:255)
	at java.io.BufferedInputStream.read1(BufferedInputStream.java:284)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:345)
	- locked <0x00000007919cdae0> (a java.lang.UNIXProcess$ProcessPipeInputStream)
	at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
	at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
	at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
	- locked <0x0000000791d00240> (a java.io.InputStreamReader)
	at java.io.InputStreamReader.read(InputStreamReader.java:184)
	at java.io.BufferedReader.fill(BufferedReader.java:161)
	at java.io.BufferedReader.readLine(BufferedReader.java:324)
	- locked <0x0000000791d00240> (a java.io.InputStreamReader)
	at java.io.BufferedReader.readLine(BufferedReader.java:389)
	at com.vaadin.flow.server.DevModeHandler.readLinesLoop(DevModeHandler.java:440)
	at com.vaadin.flow.server.DevModeHandler.lambda$logStream$1(DevModeHandler.java:420)
	at com.vaadin.flow.server.DevModeHandler$$Lambda$485/335906378.run(Unknown Source)
	at java.lang.Thread.run(Thread.java:748)

If I kill the process with kill -TERM <pid>, I get the following:

2019-09-17 13:58:30.987  INFO 69961 --- [        webpack] dev-webpack                              : Stopped 'webpack-dev-server'

I strongly suspect that's related to the problem as I can see the same logging at the very end of the Maven build if I disable forking.

[INFO] --- spring-boot-maven-plugin:2.2.0.M6:stop (stop-spring-boot) @ spring-skeleton ---
[INFO] Stopping application...
2019-09-17 13:59:42.426  INFO 70384 --- [           main] inMXBeanRegistrar$SpringApplicationAdmin : Application shutdown requested.
2019-09-17 13:59:42.428  INFO 70384 --- [           main] o.s.s.concurrent.ThreadPoolTaskExecutor  : Shutting down ExecutorService 'applicationTaskExecutor'
[INFO]
[INFO] --- maven-failsafe-plugin:2.22.2:verify (default) @ spring-skeleton ---
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 21.204 s
[INFO] Finished at: 2019-09-17T13:59:42+02:00
[INFO] ------------------------------------------------------------------------
2019-09-17 13:59:42.467  INFO 70384 --- [        webpack] dev-webpack                              : Stopped 'webpack-dev-server'

The only reason you see this with 2.2 is that we've decided to enable forking by default. You can restore the behaviour in 2.1 by configuring the fork attribute explicitly:

<execution>
    <id>start-spring-boot</id>
    <phase>pre-integration-test</phase>
    <goals>
        <goal>start</goal>
    </goals>
    <configuration>
        <fork>false</fork>
    </configuration>
</execution>

[Legioth]

We have the same problem also when the Java process is killed by Eclipse: vaadin/flow#6291. It looks like JVM shutdown hooks are not run.

We will most likely fix this on our end by making the webpack process detect that the Java process is no longer around and then terminate itself.

[mehdi-vaadin]

vaadin/flow#6291 has been fixed. But, the problem still exists and can be reproduced by the instructions mentioned here.

[Legioth]

Seems like this is indeed the opposite of vaadin/flow#6291. In this case, it's the java process that keeps itself alive waiting for the webpack process.

Starting webpack as a daemon thread seems to fix this issue. vaadin/flow#6515

[mehdi-vaadin]

@Legioth You're right. You have fixed the problem.

[snicoll]

@mehdi-vaadin as far as I understand, we're all good now? Is there a CI build with the latest milestone and/or 2.2 snapshot that confirms the current release is working with Spring Boot 2.2?

[mehdi-vaadin]

@snicoll The CI build has been failed. I'm on it right now.

[mehdi-vaadin]

The CI build is green. So, I can confirm that Vaadin is now compatible with Spring Boot 2.2.

[snicoll]

Thanks for letting us know. I've removed the restriction and this should be available again once the build completes.