Tomasz Nurkiewicz around Java and concurrency

Spring framework 4.2 GA is almost released, let's look at some new features it provides. The one that got my attention is a simple new class SseEmitter - an abstraction over sever-sent events easily used in Spring MVC controllers. SSE is a technology that allows you to stream data from server to the browser within one HTTP connection in one direction. It sounds like a subset of what websockets can do. However since it's a much simpler protocol, it may be used when full-duplex is not necessary, e.g. pushing stock price changes in real-time or showing progress of long-running process. This is going to be our example. Imagine we have a virtual coin miner with the following API: public interface CoinMiner { BigDecimal mine() { //... } } Every time we call mine() we have to wait few seconds and we get around 1 coin in return (on average). If we want to mine multiple coins, we have to call this method multiple times: @RestController public class MiningCont

Few weeks ago I attended GOTO Amsterdam conference . Beautiful venue , great food but most importantly, couple of interesting talks that caught my attention. Out of two days and five to six tracks I want to comment couple of sessions. "Challenges in Implementing MicroServices" by Fred George Yet another microservices talk, you might say. But this one was slightly more in-depth and practical. [Slides are available], let me comment slide 10, copied here: Summary principles of MicroServices Very, very small Team size of one to develop/maintain Loosely coupled (including flow) Multiple versions acceptable (encouraged?) Self-monitoring of each service Publish interesting "stuff" (w/o explicit requirements) "Application" seems to be a poor conceptualization I don't quite buy the " micro-" or even "nano-" services trend. The service shouldn't be as small as possible, it should encapsulate business component, typ

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 bu

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.curre

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 FileSystemPoin

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

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