Skip to content

Latest commit

 

History

History
91 lines (77 loc) · 5.88 KB

QQE-378.md

File metadata and controls

91 lines (77 loc) · 5.88 KB
Raw

QQE-378 - HTTP module / REST use-cases - Development topics compressions Brotli4j and Snappy

Links

Jira : QQE-378

Brotli4J PR: quarkus-qe/quarkus-test-suite#1717

Snappy PR: quarkus-qe/quarkus-test-suite#1799

Scope of the testing with Brotli4J

Within the Quarkus framework, we have the option to leverage various compression strategies, including Gzip, Snappy, and Brotli4j. Notably, Brotli4J, being a part of Vert.x, is inherently supported by Quarkus.

Given the absence of existing test coverage for Brotli4J within this context, we have identified a need to encompass this area within our testing scope.

  • Test whether Brotli4J compression library functions correctly within Quarkus, particularly in the context of REST endpoints using the Quarkus REST extension.
  • The test coverage will be verified for JVM, native mode, dev mode and Openshift.
  • To use Brotli4J in quarkus compression we will need:
    • Utilize Vert.x http server options to add Brotli4J compressor support.
    • Ensure that the server is configured to respect the Accept-Encoding header of br to automatically compress the response body with Brotli4j compression and send it back to the client.

Brotli4J Test scenarios

  • Compression Enabled, Response Compressed and Decompressed
    • Set up a Quarkus application with the Brotli4J compression library.
    • Enable quarkus http configuration compression quarkus.http.enable-compression=true.
    • The response is compressed if the Content-Type header is set and the value is a compressed media type as configured specification in the next point.
    • Specify the media types supported to compress quarkus.http.compress-media-types.
    • Note that the REST extension also make it possible to enable/disable compression declaratively using the annotations io.quarkus.vertx.http.Compressed and io.quarkus.vertx.http.UnCompressed.
    • Add the Brotli compressor using .addCompressor(io.netty.handler.codec.compression.StandardCompressionOptions.brotli()).
    • Send a request to a REST endpoint with the .header("Accept-Encoding", "br") and verify that the response is compressed using Brotli.
    • Verify for decompression, that we can use quarkus.http.enable-decompression when is it enabled, vert.x will decompress the request’s body if it’s compressed.
  • Compression Disabled, Response Not Compressed (Uncompressed)
    • Disable quarkus http configuration compression quarkus.http.enable-compression=false.
    • Send a request to a REST endpoint and verify that the response is not compressed.
    • The resource method is never compressed if is annotated with @io.quarkus.vertx.http.Uncompressed.
  • JSON Payloads, Compression Works up to 8192 bytes
    • Create a JSON payload of varying sizes up to 8192 bytes.
    • Send a request to a REST endpoint with the JSON payload and verify that the response is compressed using Brotli.
    • Create a JSON payload of more of 8192 bytes and check the error.
  • Different Media Types, Compression Applied Correctly
    • Create a plain text payload.
    • Create an XML payload.
    • Send a request to a REST endpoint with each payload and verify that the response is compressed using Brotli4J.
  • Dev Mode
    • Check that the application and tests work properly with @DevModeQuarkusApplication
  • Native Mode
    • Verify that the tests are executed and pass with the Native profile.

Scope of the testing with Snappy

Snappy can be used for message compression in Apache Kafka on outgoing channels. It works on both JVM and Native environments by configuring the application.properties file as follows:

mp.messaging.outgoing.${name.of.topic}.compression.type=snappy
quarkus.kafka.snappy.enabled=true

Checking compression in Kafka is not straightforward because you configure producers with the compression.type property to compress records written to Kafka. These records are stored compressed in the broker. When consumers read these records, the compression type is automatically detected and decompressed. To verify that compression is enabled or being used, you need to examine the Kafka Docker container logs. In our case, this involves looking at the Strimzi Kafka container logs for the topic "test". The test coverage will be verified for JVM, native mode, dev mode and Openshift.

Snappy Test scenarios

  • Compression enable

    • Check that compression key in the Kafka logs (compresscodec) has got snappy value.
    • Measure and verify the size of the compressed message bytes to ensure compression has occurred.
    • Verify integrity of message when the consumer read from kafka after decompression that occurs internally.

  • JSON payload

    • Send a big json payload to Kafka and check that Snappy compression works properly.
    • Compare the size of the compressed payload with the original to ensure compression efficiency.

  • Dev Mode

    • Check that the application and tests works properly with @DevModeQuarkusApplication.

  • Native Mode

    • Verify that the tests are executed and pass with the Native profile.

  • Openshift scenario.

    • Verify that the tests are executed and pass on Openshift.

Links to the resources

Contacts