Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support for Multiple RSocket Handlers #974

Open
rstoyanchev opened this issue Jan 22, 2021 · 4 comments · May be fixed by #997
Open

Support for Multiple RSocket Handlers #974

rstoyanchev opened this issue Jan 22, 2021 · 4 comments · May be fixed by #997
Labels
enhancement
Milestone
1.x Backlog

Comments

@rstoyanchev
Copy link
Contributor

rstoyanchev commented Jan 22, 2021 •
edited
Loading

RSocketConnector and RSocketServer can be configured with a SocketAcceptor that handles all requests. A framework can build on this low level mechanism and decide how to route requests internally. However there is no easy way to have multiple frameworks, e.g. rsocket-rpc-java and spring-messaging, side by side in the same application.

Given the existence of the Routing Metadata Extension, RSocket Java could provide a mechanism to delegate requests to one of multiple RSocket handlers depending on the route. This could be as simple as a route prefix that helps to decide which RSocket should handle the request.
@rstoyanchev rstoyanchev mentioned this issue Jan 22, 2021
Closed
@OlegDokuka OlegDokuka added this to the 1.x Backlog milestone Jan 22, 2021
@OlegDokuka
Copy link
Member

OlegDokuka commented Jan 22, 2021 •
edited
Loading

Drafted a diagram of a possible design of the implementation
image

  1. Decode given metadata to find encoded route via MetadataDecoder (note, a requester side should use a MetadataEncoder to encode route in the payload metadata
  2. Find a Handler Function based on string route in the Router
  3. Handle found function depends on the interaction type

@yschimke
Copy link
Member

Playing devil's advocate - Isn't this the point of the framework code above rsocket? Should this be part of the base library?

I know it's awkward if rsocket-rpc-java and spring-messaging are peers that are unaware of the other, but seems like something would need to configure how to decide where to delegate calls to. That logic seems likely to be similar to any framework like spring or rsocket-rpc.

No strong opinion here against, just probing.

@OlegDokuka
Copy link
Member

Actually, this logic is in rsocket-rpc as of now, but, after a few discussions, @bsideup and I ended up that rsocket-router logic should sit in a different place than rpc. Thus it is either should be rsocket-router-java or rsocket-java with submodule rsocket-router

@yschimke
Copy link
Member

Makes sense. So I'd change my argument to be that it shouldn't be that routing has pride of place in rsocket-java. But a module allowing frameworks to coexist, has an attraction.

@OlegDokuka OlegDokuka linked a pull request Mar 13, 2021 that will close this issue
Draft
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement
Projects
None yet
Milestone
1.x Backlog
Development

Successfully merging a pull request may close this issue.

implements standard Router API rsocket/rsocket-java
3 participants
@yschimke @rstoyanchev @OlegDokuka