4 Asynchronous data and event streams

 

This chapter covers

  • Why streams are a useful abstraction on top of eventing
  • What back-pressure is, and why it is fundamental for asynchronous producers and consumers
  • How to parse protocol data from streams

So far we have been processing events using callbacks, and from various sources such as HTTP or TCP servers. Callbacks allow us to reason about events one at a time.

Processing an incoming data buffer from a TCP connection, from a file, or from an HTTP request is not very different: you need to declare a callback handler that reacts to each event and allows custom processing.

That being said, most events need to be processed as a series rather than as isolated events. Processing the body of an HTTP request is a good example, as several buffers of different sizes need to be assembled to reconstitute the full body payload.

Since reactive applications deal with non-blocking I/O, efficient and correct stream processing is key. In this chapter we’ll look at why streams pose challenges and how Vert.x offers a comprehensive unified stream model.

4.1 Unified stream model

Vert.x offers a unified abstraction of streams across several types of resources, such as files, network sockets, and more. A read stream is a source of events that can be read, whereas a write stream is a destination for events to be sent to. For example, an HTTP request is a read stream, and an HTTP response is a write stream.

4.2 What is back-pressure?

4.3 Making a music-streaming jukebox

4.3.1 Features and usage

4.3.2 HTTP processing: The big picture

4.3.3 Jukebox verticle basics

4.3.4 Incoming HTTP connections

4.3.5 Downloading as efficiently as possible

4.3.6 Reading MP3 files, but not too fast

4.4 Parsing simple streams

4.5 Parsing complex streams

4.6 A quick note on the stream fetch mode