-
Notifications
You must be signed in to change notification settings - Fork 13
Routing Based On Route Metadata Tags Not Working Properly #8
Description
I am using ...
Spring Boot: 2.2.0.RELEASE
Spring Cloud: Hoxton.BUILD-SNAPSHOT
Spring Cloud RSocket: 0.2.0.BUILD-SNAPSHOT
Sample project: here
In my setup reservation-service-client
communicates with reservation-service
via RSocket and the service-gateway
.
reservation-service
registers with the following route metadata tags (see reservation-service/src/main/resources/application.yml
):
spring:
cloud:
gateway:
rsocket:
client:
service-name: reservation-service
route-id: 400
tags:
instance_name: reservation-service-1
version: 1.0-RELEASE # <-- I want to route based on that version.
broker:
host: localhost
port: 7002
reservation-service-client
declares forwarding information like that(see reservation-service-client/src/main/resources/application.yml
):
spring:
cloud:
gateway:
rsocket:
client:
service-name: reservation-service-client
route-id: 500
forwarding: # Routing / forwarding hints to the Gateway broker.
"[create.reservation.{vrsn}]":
service_name: reservation-service
version: "{vrsn}-RELEASE"
... where {vrsn}
is resolved to 2.0
as coded in reservation-service-client
's ReservationServiceClient
like so:
public Mono<ReservationConfirmation> createReservation(CreateReservationRequest request) {
String version = "2.0";
return rsocketRequester.route("create.reservation.{vrsn}", version)
.data(request)
.retrieveMono(ReservationConfirmation.class)
.log();
}
Thus, the client should be forwarded to a reservation-service
instance of version 2.0-RELEASE
(which is not available). However, that is not the case, and client is getting forwarded to a service instance of version 1.0-RELEASE
.
When the client sends the request via the gateway to the service, you can see output in the gateway logs, that the forwarding metadata is properly available and {vrsn} was resolved properly as well, yet the gateway simply forwards to the reservation-service
instance of version 1.0-RELEASE
although the client routing metadata states otherwise.
Expected behaviour in this case (imo) would be to respond with max backpressure from the gateway since the service is not (yet) available.
To reproduce:
- start
service-gateway
- start
reservation-service
- start
reservation-service-client
- send a POST request to
http://localhost:9999/reservation/create/ReservationName
(Web endpoint of client that will send the RSocket request)