-
Notifications
You must be signed in to change notification settings - Fork 255
0.5.x FAQs
0.5.x branch is the current release for RxNetty. This is no longer under active development but will have major patches applied and will accept pull requests. It will be superceded by 1.0.x, which will support RxNetty-2.
The binaries for 0.5.x are only available as snapshots at jfrog artifactory, the following snippet can be used to refer to these artifacts with gradle:
repositories {
maven { url 'https://oss.jfrog.org/libs-snapshot' }
}compile 'io.reactivex:rxnetty:0.5.0-SNAPSHOT'RxNetty is a library that is still evolving as it is targetting a space (a reactive networking library) that is not
yet mature. The current stable version works inside Netflix with various applications in production at scale, however,
as and when people used it in different scenarios, they provided feedbacks around missing features and API usability.
Some of the changes to incorporate these feedbacks require backward incompatible changes and hence the need for a
version change that reflects backward incompatible changes.
We will be maintaining 0.4.x branch for a while as moving to 0.5.x is non-trivial. However, all new features will invariably land into 0.5.x and 0.4.x will only get bug-fixes, once 0.5.x is released.
There are a lot of benefits of moving to 0.5.x in terms of new features, which are listed below.
RxNetty preceded the introduction of backpressure in RxJava and
hence the APIs were not written in a way to support backpressure.
All 0.5.x read and write operations supports backpressure, so the underlying netty channel will react to backpressure in
the Rx chain. This means that while reading from a channel, if the consumer is slow, RxNetty will stop reading from
the channel and while writing, if the channel is not ready to write more, RxNetty will propagate backpressure up the
Observable chain which is being written.
(Once 0.5.x is nearing release, we will add documentation around how backpressure works, for now, this class is a good place to start learning about how backpressure is implemented.)
The following noteworthy changes are done to the client and server APIs.
Issues #280, #303 and #317 discusses these changes. The predominant reason for the change was the disparity between what can be done using a builder as opposed to directly creating a client. Now, clients and servers can be modified after creation and each mutation creates a new instance of the client and server, preserving all the properties existent at the time of mutation. This approach makes it easier to use without side-effecting behavior on the existing clients and servers.
0.4.x has a concept of PipelineConfigurators, which is the only way
of adding netty's ChannelHandlers to the client and server. This proved out to be rather inconvenient without adding
tangible benefits. 0.5.x removes this abstraction and allows netty's ChannelHandlers to be added directly to the
client and server. RxNetty maintains the components of the pipeline which are required for RxNetty to function
correctly.
Clients in 0.4.x provided some configuration via ClientConfig, Client and the Builders. This was invonvenient as
the separation between them was not clear. Now, all these different ways of configuring the client behavior is folded
in the client itself, and hence is uniformly accessible.
0.4.x provided no easy way to have a client that could connect/use a homogeneous pool of hosts, which is generally the
case in any mature system. 0.5.x provides a convenient abstraction of ConnectionProvider to provide various connect
mechanisms including pooling, load balancing, etc. An example of load balancer for HTTP clients is available here
0.4.x provided dedicated WebSocket client and servers. This made it impossible for the same client to be used for different protocols over HTTP (SSE, WebSockets, HTTP/2, etc.). 0.5.x provides only a single way of using WebSockets, i.e. by upgrading from HTTP/1.1. This is true to the actual nature of WebSockets protocol and hence provides the most flexible way for handling WebSockets both on client and server. An example of WebSockets is available here
0.4.x auto-releases ByteBuf which created lot of edge cases, when the ByteBuf was not consumed synchronously within
the onNext call from RxNetty. 0.5.x does not auto-release any ByteBuf read from it and hence can easily be used
for both use-cases of sync and async processing. More details are specified in this issue
This feature is not yet available in the snapshot but will be available with the release candidate
This feature is not yet available in the snapshot but will be available with the release candidate
Some features in 0.4.x have not yet made it to 0.5.x, either because they were not mature or were not critical and could be additive on top of the current APIs. The following are the list of the missing features as compared to 0.4.x:
At this moment, the best way to start getting used to the new APIs is by following the available examples. When we are nearing release, we expect to add more documentation on various concepts and usage.
This is the best time to try out this new release and give feedback about usability as we can still make API changes. So, try it out and provide feedback via Github Issues
We are working on stabilizing this release within Netflix by using it in various applications. The stabilization means getting feedback about the APIs as well as bug-fixes. Once, we are confident about the quality of the snapshot, we will release a candidate version. The milestone for this candidate can be tracked here