Tomasz Nurkiewicz around Java and concurrency

I don't like RESTful principles and APIs. In recent years it is seen as universal protocol for inter-process communication, especially in distributed systems. However I see many deficiencies of REST and there are alternatives that work well for certain use cases. Obviously there is no one size fits all, I just want to emphasize that REST architecture is flawed in a number of ways.
Bloated, human readable format that demands extra compression The de facto standard format for REST is JSON. At least it's way better than SOAP with its XML and envelopes. Either lots of network bandwidth is wasted (can be an issue with mobile devices or large data centers) or CPU is spent on compression and decompression. A lovely quote:
[the] internet is running in debug mode source It's a serious issue, ask high-frequency traders how hard parsing text-based FIX is. There are plenty of well-established binary protocols that are both easy to parse and use little memory, e.g. Protocol buffers, Av…

Classical producer-consumer pattern is relatively simple in Java since we have java.util.concurrent.BlockingQueue. To avoid busy waiting and error-prone manual locking we simply take advantage of put() and take(). They both block if queue is full or empty respectively. All we need is a bunch of threads sharing reference to the same queue: some producing and others consuming. And of course the queue has to have a limited capacity, otherwise we will soon run out of memory in case of producers outperforming consumers. Greg Young couldn't emphasize enough this rule during Devoxx Poland:

Never, ever create an unbounded queue

Producer-consumer using BlockingQueue Here is a simplest example. First we need a producer that puts objects in a shared queue:

import lombok.Value; import lombok.extern.slf4j.Slf4j; @Slf4j @Value class Producer implements Runnable { private final BlockingQueue<User> queue; @Override public void run() { try { while (!Thread.currentThread().is…

As far as HTTP is concerned, what client is downloading is just a bunch of bytes. However client would really like to know how to interpret these bytes. Is it an image? Or maybe a ZIP file? The last part of this series describes how to give a hint to the client what she downloads.

Set Content-type response header Content type describes MIME type of resource being returned. This header instructs web browser how to treat stream of bytes flowing from the download server. Without this header browser is clueless of what it actually received and simply displays content as if it was a text file. Needless to say binary PDF (see screenshot above), image or video displayed like a text file doesn't look good. The hardest part is to actually obtain media type somehow. Luckily Java itself has a tool for guessing media type based on extension and/or contents of the resource:

import com.google.common.net.MediaType; import java.io.*; import java.time.Instant; public class FileSystemPointer imple…

In the age of botnets that you can rent for few hundred bucks and run your very own distributed-denial-of-service attack, having emergency switches that selectively turn off expensive functionality or degrade performance gratefully is a huge win. Your application is still operational while you mitigate the problem. Of course such safety measure are also valuable under peaks or business hours. One of such mechanisms applying to download servers is throttling download speed dynamically. In order to prevent distributed denial of service attack and excessively high cloud invoices, consider built-in download throttling, that you can enable and fine-tune at runtime. The idea is to limit maximum download speed, either globally or per client (IP? Connection? Cookie? User agent?).

I must admit, I love java.io design with lots of simple Input/OutputStream and Reader/Writer implementations, each having just one responsibility. You want buffering? GZIPing? Character encoding? File system writing?…

HEAD is an often forgotten HTTP method (verb) that behaves just like GET, but does not return body. You use HEAD in order to check the existence of a resource (it should return 404 in case of absence) and make sure you don't have a stale version in your cache. In that case you expect 304 Not Modified, while 200 means the server has more recent version. You can e.g. use HEAD to efficiently implement software updates. In that case ETag is your application version (build, tag, commit hash) and you have a fixed /most_recent endpoint. Your software sends HEAD request with current version in ETag. If there were no updates, server will reply with 304. In case of 200 you can ask user whether she wants to upgrade without downloading the software yet. Finally requesting GET /most_recent will always download the most recent version of your software. The power of HTTP!

In servlets HEAD is implemented by default in doHead() which you are suppose to override. The default implementation just del…