How to enable the client to support reactive

[zhaojiq]

Hi ,
I'll use Kubernetes or OpenShift clients in reactive frameworks(such as projectreactor or rxjava2 and so on.) that typically make asynchronous calls easier and consume fewer threads. Typically, Kubernetes api responsed in a relatively short period of time, but when Kubernetes has a problem, the time becomes uncontrollable. Also because it is a synchronous pattern, a limited number of threads in the reactive framework maybe cause other businesses to be blocked.

If we don't have time for reactive support for the time being, I'd be happy to contribute to this feature.

[rohanKanojia]

@zhaojiq : I think it might be quite involved effort. Would you like to elaborate a bit on how you plan to add this reactive support? You can also go ahead and create PR before discussing, we can discuss there also.

[zhaojiq]

@rohanKanojia Yes, it's going to do a lot of things, and it seems easier to reconstruct a reactive version of the client based on okhttp3. So do we have such a plan? (reusing our design and models, and some methods are turned into a reactive implementation.) Or do you think it's necessary?

[manusa]

Hi @zhaojiq

A few months back I created a PoC for a Kubernetes Client with a different approach to that of the existent clients.

Besides reasons like having low-level access to the REST API and less opinionated configurations and helpers (which are really good for most of the users, but a problem for a few), another motivation was to have reactive support from the start.

For list-like endpoints you will get reactive watchers (using ReactiveX), here you will find some examples of its usage:

• PodQuickstart.java#L80
• PodQuickstart.java#L142
• PodExec.java#L48

And also vanilla Java Stream support:

• TopNodes.java#L60

Coming back to your question, I think adding Reactive support for the client is possible but it would be quite an involved challenge given its current state and code generation methods.
I'm not sure that the procedures involved in the examples for the PoC could be easily added to Fabric8's client as a whole. Maybe it could be achieved if done little by little (e.g. adding this as a feature in #2010)

[zhaojiq]

Thx @manusa

I'll try to write a sample implementation. So
do we have any inclination in the framework selection of Reactive? Like Rx Java or Reactor or others.

[stale]

This issue has been automatically marked as stale because it has not had any activity since 90 days. It will be closed if no further activity occurs within 7 days. Thank you for your contributions!

[aleboulanger]

any update about this topic ?

[shawkins]

@aleboulanger with 6.0 the core of the client and 2 of the http client implementations (jdk and jetty) are mostly reactive and make conservative use of threads - the okhttp client of course still does not. So with 6.0 and the jdk client you can for example create as many informers as you want and they will all share the same jdk client worker pool, rather than holding multiple threads per informer.

However that core logic has not been exposed directly to the end user.