add service registry events allowing to listen on service references

[ronenhamias]

add service registry events allowing to listen on service references changed

Motivation:

the idea is to be subscribed to specific service reference and not to service endpoint from discovery.
for example in service layer i want to know when a service is available to subscribe to it.

in such case i can subscribe in discovery and start filtering the relevant reference.
but in routing context i dont usually have access to discovery.

by listening on service registry i can subscribe to references and filter / handle service reference discovery.

[segabriel]

maybe better .serialize() need to move to sink like:

FluxSink<RegistryEvent> sink = events.serialize().sink();

[ronenhamias]

what is the reason you think its better?

[segabriel]

we can emit some events from different threads therefor we need that our sink will be with serialize(). And in another hand, to subscribe to events we don't need use redundant .serialize() and it's it is unnecessary for FluxProcessor<RegistryEvent, RegistryEvent> events

[segabriel]

remove redundant creating a set .collect(Collectors.toSet())

[artem-v]

What's the practical purpose? Uses cases?

[ronenhamias]

Motivation:

the idea is to be subscribed to specific service reference and not to service endpoint from discovery.
for example in service layer i want to know when a service is available to subscribe to it.

in such case i can subscribe in discovery and start filtering the relevant reference.
but in routing context i dont usually have access to discovery.

by listening on service registry i can subscribe to references and filter / handle service reference discovery.

[artem-v]

Looks like this doubles functionality that we already have.
This is how:
the ServiceDiscovery already has Flux<DiscoveryEvent> listen() method, so we can listen add/remove and etc.; then in DiscoveryEvent there's a field serviceEndpoint which by turn has Collection<ServiceRegistration> serviceRegistrations field, where ServiceRegistration, by turn, has Collection<ServiceMethodDefinition> methods field.
So we are already all set to build ServiceReference object out of given ServiceEndpoint.

[ronenhamias]

its not same api where from discovery you get service endpoints and not service references

[dmytro-lazebnyi]

@ronenhamias
PR looks interesting, but I'm not sure that I completely understand purpose of this functionality.

the idea is to be subscribed to specific service reference and not to service endpoint from discovery.

What are benefits from knowledge that some particular service reference is added or removed?
I mean, imagine that we have 3 service nodes (references) related to some ExampleService.
What do we achieve if we get event with information that 4th service reference is added or some of this 3 is removed?

[ronenhamias]

@dmytro-lazebnyi
for example you are dependent on this service and you want to subscribe to all (or some) instances of this type once it appears at the cluster.

you need to manage the lifecycle of these services are beeing added removed:

lets imagine i want to subscribe to all quote services in the cluster as they appear for example

becouse new instrument are elastically appearing in the cluster

and i want to make sure i subscribe only once to specific reference.