Production readiness of RSocket

#1

Hi,

I’m wondering what is the status of RSocket with regards to production readiness. The protocol is not yet released, all libraries are versioned 0.x.

compile ‘io.rsocket:rsocket-core:0.11.15’
compile ‘io.rsocket:rsocket-transport-netty:0.11.15’
compile ‘io.rsocket:rsocket-micrometer:0.11.15’
compile ‘io.rsocket.rpc:rsocket-rpc-core:0.2.12’

I’m was playing with java version of RSocket and it fits our use case wonderfully (bidirectional communication of microservices over one connection) and the code is elegant and easy to understand. But the first question I will get when I present it to someone is … it seems that the technology is not ready.

Is there a plan to actually release the libs and protocol spec as 1.0?
Is it actually used somewhere in production?

Thanks
Matous

#2

Hello Matous,

RSocket is production ready. It has actually been in development for several years and is currently in use at Facebook, Alibabi, Pivotal, and others. We have been planning to bump the version to 1.0 for some time now, but decided to wait until we added the warm resumption feature to the java client. This work has been completed and is in the process of being tested now. Once we are happy with the results of that testing we will be bumping the version to 1.0.

1 Like
#3

Hi,

To add to Greg’s comments…

Is there a plan to actually release the libs
Yes - Java RSocket will be 1.0 in the next month or two. The core features are all there for Java, JavaScript, C++, and .NET

Golang is being actively developed right now. RSocket is going to be supported supported in Spring 5.2

and protocol spec as 1.0?
Yes - there hasn’t been any major changes -we’ve been using on the release candidate so its more of a formality now. We have some more protocol extensions planned but there hasn’t been any talk about extending the core protocol. I was going to propose that we just release 1.0.x at our next monthly meeting.

We’re working on compiling an RSocket feature matrix:

Thanks,
Robert

1 Like
#4

Hi, thank you for your answers. Will look forward to that release.

I saw on twitter that RSocket is coming to Spring, glad that it is planned to be merged so soon-ish.

#5

Is there any reference to javadocs for ClientRSocketFactory and ServerRSocketFactory public methods?
I want to learn the functionalities of resume**() methods and their uses.

#6

In fact, there is an error - “io.rsocket.exceptions.RejectedResumeException: unknown resume token” as of version 0.12.2-RC2.

#7

Resumption is something that we are actively working on at the moment across Java, JavaScript, and C++. I don’t think it’s expected to work yet.

#8

Hi,

It will work between C++ and Java, but you need to some setup parameters to make it work. There’s only some more basic in-memory support at the moment. JavaScript resumption support need some changes for it work. Netifi’s broker doesn’t support it yet but we will in the future.

@maksym can help answers some questions about Java resumption as he worked on it.

Thanks,
Robert

#9

Hi,

Is someone working on Python lib ?

#10

“unknown resume token” means resumable session has expired on server, and resumption is impossible. Resumable session duration can be set with Client/ServerRSocketFactory.resumeSessionDuration(Duration), and defaults to 2 minutes. From user’s perspective resumption happens transparently: as soon as dead transport is detected (disconnect, or missing keep-alives), RSocket client tries to reconnect periodically using ResumeStrategy provided inClientRSocketFactory.resumeStrategy - exponential backoff, periodic, or custom one. I will compose file transfer example with current RSocket snapshot 0.12.2-RC3-SNAPSHOT - It should be released by the end of this week.

1 Like
#11

Here is short explanation of resume related methods on RSocketFactory:
ClientRSocketFactory.resume() - enables resumption on client: respective flag and token from ClientRSocketFactory.resumeToken will be set on setup frame.
ClientRSocketFactory.resumeStore(ByteBuf -> ResumableFramesStore) - sets how resumable frames are stored - function of resume token. Currently InMemory only.
ClientRSocketFactory.resumeSessionDuration - stored frames and related state is expired if resumption did not happen
ClientRSocketFactory.resumeStrategy - decides when resumption attempt happens if dead transport is detected (disconnect, missing keep-alives).

1 Like
#12

resumable file transfer example is available here

1 Like
#13

Thanks. The file transfer example is very informative.

I had also developed similar file transfer app over RSocket. It had a requirement that, even if the server goes down momentarily the client should resume file transfer automatically once server is up. Here, I used “spring-retry” to catch connection error and reconnect to server and resume the upload from where it left earlier. The server keeps the state of the uploaded file.

Doubts :

  • Could RSocket protocol handle client resumption after server restarts briefly?
  • If before starting the actual file transfer over a channel, some authentication and metadata transfer is required, what is the best way?

This was my logic and it worked. Please suggest if there is an alternate way.

  • used RequestChannel as it is the client that sends file to server
  • client sends a JSON as the first payload of the Flux to server
  • JSON contains various authentication and metadata
  • server validates and sends JSON response in the same channel
  • both in server and client Flux.switchOnFirst(…) operator is saving my day for this logic to work
  • still I need to have Flux.delaySubscription(…) of some random seconds in the client as I am afraid that the actual file transfer may get started by client before server sends validated response of the first Payload

Now, for some reason, if the server takes more time to validate the JSON, client may completely spend the delay and start sending chunks of the file. This is not desired.

I also do not want to use two TCP connections (RequestResponse and RequestChannel) from client for sending metadata and then sending file chunks. Because, this may create complication when client is multi-threaded.

I guess many would require to send intitial handshaking data to and fro between RSocket server and client. A best practice approach is needed in such scenario.

Thanks,
sumanta

#14

Hello, I created separate topic for discussion of resumable file transfer - Resumable file transfer. Lets keep conversation there