The _source field contains the original JSON document body that was passed at index time. The _source field itself is not indexed (and thus is not searchable), but it is stored so that it can be returned when executing fetch requests, like get or search.

_source is parsed and loaded in memory during indexation and most of the time during the request. In order to construct the result list, the coordinator node fetches the documents, they are transferred on the network, loaded in memory, parsed, aggregated, then returned.

This quicky will only focus on the impact of the _source size on the performance, not on the memory and the network pressure.

The Takipi benchmark ‘How Misusing Streams Can Make Your Code 5 Times Slower’ contains interesting but unexplained results:

• The first one is the autoboxing/unboxing issue as stated by Sergey Kuksenko comment.
• The second one is the difference between the “lambda” and “stream” benchmark: the first one is 5 times slower than the last one whereas the code is quite similar.

This quicky tests how jOOQ, Hibernate and JDBC perform against each other on a simple query / scenario involing Plain Old SQL, jOOQ, Hibernate Named Query and Spring Data JPA.

This article will present a pattern to achieve fair consuming with RabbitMQ, an AMQP implementation using a deficit weighted round robin scheduler.

This article is not about RabbitMQ Priority Queue Support. A consumer bounds to a RabbitMQ priority queue will always consume first the messages with the highest priority. It doesn’t ensure that a message with a low priority will be processed, high priority messages may predate the processing slots.

Continuous Release process allows an artifact to be continuously releasable and promotable to the upper environment.

The topic has been covered by a large amount of articles, so why this new one? Continuous release of an Application (eg. executable jar, war) is indeed well covered but not the continuous release of the dependencies (eg. jar library) of an Application.

In this article we will cover both topics and we will get ride of the release pipeline I describe in my previous article Jenkins Workflow - Pipeline de release to rely solely on a slightly modified continuous integration pipeline. I will end the article with a description of the Continuous Integration pressure paradigm.