RSocket components fail to load when using Webflux and Spring lazy initialization.

[ccellist]

Version: Spring Boot 2.2.0.M5
Module: spring-boot-starter-rsocket

When enabling lazy initialization for spring beans (spring.main.lazy-initialization=true) rSocket components fail to load with the following exception (stack trace abbreviated):

Caused by: java.lang.IllegalStateException: block()/blockFirst()/blockLast() are blocking, which is not supported in thread reactor-http-nio-2
	at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:77) ~[reactor-core-3.3.0.BUILD-20190823.142502-144.jar:3.3.0.BUILD-SNAPSHOT]
	at reactor.core.publisher.Mono.block(Mono.java:1541) ~[reactor-core-3.3.0.BUILD-20190823.142502-144.jar:3.3.0.BUILD-SNAPSHOT]
	at com.arayastudio.quickchat.config.RSocketConfig.rSocket(RSocketConfig.java:30) ~[classes/:na]
	at com.arayastudio.quickchat.config.RSocketConfig$$EnhancerBySpringCGLIB$$13ab571d.CGLIB$rSocket$0(<generated>) ~[classes/:na]
	at com.arayastudio.quickchat.config.RSocketConfig$$EnhancerBySpringCGLIB$$13ab571d$$FastClassBySpringCGLIB$$5e97efe0.invoke(<generated>) ~[classes/:na]
	at org.springframework.cglib.proxy.MethodProxy.invokeSuper(MethodProxy.java:244) ~[spring-core-5.2.0.BUILD-20190823.152058-14.jar:5.2.0.BUILD-SNAPSHOT]

This happens specifically when spring-boot-starter-webflux is also a dependency. What's happening is Spring attempts to load the rSocket components inside of a non-blocking thread when someone hits the app using a webflux-enabled controller. This triggers Schedulers.isInNonBlockingThread() to return true which throws the exception. Opening this issue at the request of Andy Wilkinson (@wilkinsona) who indicated RSocket components need to be marked as never lazy.

Sample project can be found at https://github.com/ccellist/quickchat-rsocket. Build and run both client and server apps, then try hitting the client with curl -XPOST -H 'Accept: application/json' -H 'Content-Type: application/json' http://localhost:8081/chat -d 'Hello' to trigger the exception.

[philwebb]

See also #16615

[wilkinsona]

Thanks for opening this, @ccellist. Much appreciated.

[ccellist]

Happy to help @wilkinsona.

[shpall]

Hello.

In my case i need to create new connections in runtime to some new hosts over RSocket. My solution was to create bean of type Mono<RSocket> (with cache()) instead of RSocket. Maybe this information can help somebody.

@wilkinsona maybe, if applicable, we can use reactive bean?

[wilkinsona]

In this particular case the bean that cannot be lazy is defined in user configuration. Here's the definition from the sample (updated to align with removal of MIME type from MetaDataExtractor):

@Bean
public RSocket rSocket() {
    return RSocketFactory
        .connect()
        .mimeType(WellKnownMimeType.MESSAGE_RSOCKET_ROUTING.toString(), MimeTypeUtils.APPLICATION_JSON_VALUE)
        .frameDecoder(PayloadDecoder.ZERO_COPY)
        .transport(TcpClientTransport.create(7000))
        .start()
        .block();
}

The problem can then be avoided by adding @Lazy(false) to the definition:

@Bean
@Lazy(false)
public RSocket rSocket() {
…

It may still make sense to exclude any io.rsocket.RSocket bean from being lazy as it's almost certainly going to have been created using an RSocketFactory and require a call to block().

[bclozel]

After chatting with @wilkinsona , we've decided not to change the current behavior.

Since 2.2.0.M5 Spring Boot improve its RSocket support, so your application could be improved with a few changes. You could delete the RSocketConfig entirely, and create a requester like this:

@Component
public class YourService {

	private final Mono<RSocketRequester> requesterMono;

	public YourService(MyCustomProperties properties, RSocketRequester.Builder builder) {
		this.requesterMono = builder
				.dataMimeType(MediaType.APPLICATION_CBOR)
				.connectTcp(properties.getHost(), properties.getPort()).retry(5).cache();
	}

	public Mono<User> findUser(String login) {
		return this.requesterMono.flatMap(req ->
				req.route("find.user.{login}", login)
						.retrieveMono(User.class));
	}

This is creating the connection lazily and you can also add retry/error handling/etc as reactor operators.

In general, creating an RSocket as a bean might not be a good solution since you can't really handle errors/retries or even properly close the connection as part of the application lifecycle.

Right now you can write a wide variety of RSocket applications with Spring Boot without creating such beans:

• a client requester can be created and used as explained above
• an RSocket standalone server is managed by Spring Boot and creating the RSocket connection for you as part of the server lifecycle
• a requester that talks to a client can be injected by Spring Framework in a controller handler as a method parameter

I'm closing this issue for now; we might reopen this issue in the future if we see that best practices or Spring Boot support evolve in that matter.

Thanks!