SocketAcceptorInterceptor receive an unexpected payload object rather than receive a setup payload object

We create a client and server with reconnection feature. The server register a interceptor to receive the setup payload and then deserialized for authentication.

Client have another daemon thread called Thread A and send data by rsocket periodically. The sended payload data we call it payload-A.

After server is stopped and we can see the priodically sended data is failed as what we expected. After the server is started again, client begin to reconnect to the server. We can see the socket acceptor receive the setup payload data, but it is not the setup data we generated by method getAuthInfo() method. The server sidecar acceptor receive an unexpected normal payload data which is very strange.

Related server and client code:

// client 
        requesterMono = rsocketRequesterBuilder.setupRoute(SETUP_ROUTE)
            .setupData(new ObjectMapper().writeValueAsString(getAuthInfo()))
            .dataMimeType(MimeTypeUtils.parseMimeType(WellKnownMimeType.APPLICATION_JSON.getString()))
            .rsocketConnector(connector -> connector.acceptor(responder).fragment(MTU_BYTE_SIZE)
                .keepAlive(Duration.ofSeconds(KEEP_ALIVE_INTERVAL_SEC), Duration.ofSeconds(KEEP_ALIVE_MAX_TIME_SEC))
                .reconnect(Retry.fixedDelay(Integer.MAX_VALUE, Duration.ofSeconds(RSOCKET_RETRY_INTERVAL_SECONDS))
                    .doAfterRetry(retrySignal -> log.warn("RSocket client is reconnecting to get the newest connection...."))))
            .connect(TcpClientTransport.create(TcpClient.create()
                .option(ChannelOption.CONNECT_TIMEOUT_MILLIS, TCP_CONN_TIMEOUT)
                .option(ChannelOption.TCP_NODELAY, true)
                .option(ChannelOption.SO_KEEPALIVE, true)
                .host(consoleDomain)
                .port(SERVER_PORT)
                .secure(ssl -> ssl.sslContext(sslContext))));

// register a socket acceptor interceptor to receive the authentication setup payload object in the server side
    protected SocketAcceptorInterceptor genAcceptorAuthInterceptor() {
        SocketAcceptorInterceptor interceptor = acceptor -> (setup, sendingSocket) -> {
            try {
                log.info("receive an task connection try to init.");
                LocalTaskAuthInfo authInfo = new ObjectMapper().readValue(setup.getDataUtf8(), LocalTaskAuthInfo.class);

              //ignore some non-related code...
                return acceptor.accept(setup, sendingSocket);
            } catch (Exception e) {
                String errMsg = "try to accept a connection error.msg:" + ExceptionUtils.getRootCauseMessage(e);
                log.warn(errMsg, e);
                exceptionService.saveException(new SidecarRuntimeException(e));
                return Mono.error(new RSocketAuthException(errMsg));
            }
        };
        return interceptor;
    }



//server
 RSocketServer.create(routeHandler.responder()).fragment(RSocketConnConstans.MTU_BYTE_SIZE)
            .interceptors(registry -> registry.forSocketAcceptor(interceptor))
            .bind(TcpServerTransport.create(TcpServer.create()
                .option(EpollChannelOption.SO_KEEPALIVE, true)
                .option(EpollChannelOption.TCP_NODELAY, true)
                .secure(ssl -> ssl.sslContext(sslContext))
                .port(Integer.valueOf(consoleConfig.getRsocketConsolePort()))
                .doOnConnection(
                    t -> log.info("New sidecar CONNECTED. Pay attention that this is maybe a resumed connection..."))))
            .subscribe();

Expected Behavior

Receive setup payload in the socket acceptor

Actual Behavior

Receive a normal payload data.

Steps to Reproduce

Unfortuncately that we can’t reproduce it stablely. The issue occur sometimes after server is restarted. Usually after the server is restarted everything goes well.

Possible Solution

May be this is a parallel bug. It occur now and then. I know this issue may ba a little difficult. Is there any suggestion that I can take to set the breakpoint. This issue’s key point is to find out why the normal paryload data replace the setup payload data and then cause the deserialization problem.

Your Environment

• RSocket version(s) used: rsocket-core-1.0.2 and springboot-starter-rsocket 2.3.4.RELEASE
• Platform (eg. JVM version (javar -version) or Node version (node --version)): OpenJDK 1.8
• OS and version (eg uname -a): Mac OS 10.15.4

[rstoyanchev]

@KaimingWan after some more looking, we found the problem. The fix is available in snapshots. Not sure if you’re able to confirm the fix with 1.0.4-SNAPSHOT via https://oss.jfrog.org/artifactory/oss-snapshot-local – that would be very helpful, but either way this fix should help to address the issue.

[KaimingWan]

@OlegDokuka Thanks for your explanation. I find 1.0.4 has been released yesterday and we have changed to this version. Respect for you guys’s efficient work~