Subscribe to this blog

Follow by Email

Pages

Posts

Libraries provided by Netflix, usually look simple, but after a deep dive, you will realize this stuff is pretty complicated. In this article, I want to explain behavior and usage of the circuit-breaker pattern being a part of the Hystrix.

Following the Wikipedia definition "Circuit breaker is used to detect failures and encapsulates logic of preventing a failure to reoccur constantly (during maintenance, temporary external system failure or unexpected system difficulties)." What does it mean?
For example, let's consider the circuit as a connection between two services. It operates normally (aka stays closed) when the connection is stable, and the target service is healthy. We can execute our requests (assume 100 per second) without any problems.
But when our target service is down (what we know after a few unsuccessful tries), it no longer makes any sense to try 100 times per second. So we open our circuit and serve responses from a predefined fallback, as we know that …

I can bet that every Java developer at least heard about L1 (aka EntityManager or Session) cache. But is your level of understanding it good enough? If you're not sure, consider going through this post.

At first, we need to know what the persistence context is. Following EntityManager JavaDoc we know, that:"A persistence context is a set of entity instances in which for any persistent entity identity there is a unique entity instance. Within the persistence context, the entity instances and their lifecycle are managed."
In fact, the first level cache is the same as the persistence context. That means operations such as persist(), merge(), remove() are changing only internal collections in the context and are not synchronized to the underlying database. What is the mosts important here is what happens when you invoke the clear() method. It clears the L1 cache. But we know L1 == persistence context. Does it mean clearing L1 removes all entities? In fact yes - all entities…

Equals and hash code are fundamental elements of every Java object. Their correctness and performance are crucial for your applications. However often we see how even experienced programmers are ignoring this part of class development. In this post, I will go through some common mistakes and issues related to those two very basic methods.
Contract
What is crucial about mentioned methods is something called "contract." There are three rules about hashCode and five about equals (you can find them in the Java doc for Object class), but we'll talk about three essential. Let's start from hashCode(): "Whenever it is invoked on the same object more than once during an execution of a Java application, the hashCode method must consistently return the same integer, provided no information used in equals comparisons on the object is modified."
That means the hash code of an object doesn't have to be immutable. So let's take a look at the code of really simple J…

There are many ways of dividing whole application into packages. Discussions about pros and cons of packaging by feature or by layer can we found on many programming blogs and forums. I want to discuss this topic starting from testability and see if it will drive to any meaningful result.

At the beginning let's try to describe what we usually want to test in our applications across different layers. Let's assume standard three tier architecture. At the bottom we have data layer.

Depending on our attitude to Domain-Driven-Design we'll try to maximize (for rich, business-oriented entities) or minimize (for anemic entities built only from getters and setters) test coverage. In the second approach it's even hard to say about any tests, unless you don't trust Java and want to verify if get can retrieve value assigned before by set invocation. For rich entities we definitely want to verify business logic correctness. But to be honest it almost always can be done by simpl…

Few years ago in Java world it was almost obvious that every "enterprise" class project needed JPA to communicate with database. JPA is a perfect example of "leaky abstraction" described by Joel Spolsky. Great and easy at the beginning but hard to tune and limiting at the end. Hacking and working directly with caches, flushes and native queries is a daily routine for many backend developers involved in data access layer. There are enough problems and workarounds to write a dedicated book "JPA for hackers", but in this article I'll focus only on concurrent entity processing.

Let's assume the situation: we have Person entity which in some business process is updated by some service.

Even today (and it's 2015) we have two versions or Oracle HotSpot JDK - adjusted to 32 or 64 bits architecture. The question is do we really would like to use 32bit JVM on our servers or even laptops? There is pretty popular opinion that we should! If you need only small heap then use 32bits - it has smaller memory footprint, so your application will use less memory and will trigger shorter GC pauses. But is it true? I'll explore three different areas:Memory footprintGC performanceOverall performance
Let's begin with memory consumption.
Memory footprint
It's known that major difference between 32 and 64 bits JVM relates to memory addressing. That means all references on 64bit version takes 8 bytes instead of 4. Fortunately JVM comes with compressed object pointers which is enabled by default for all heaps less than 26GB. This limit is more than OK for us, as long as 32 bit JVM can address around 2GB (depending on target OS it's still about 13 times less). So no wo…

I've always been missing possibility to configure custom headers in JStat. Of course there are a lot of predefined data sets, but it'll be nicer if we could create our own data set. And as you probably already devised I'm writing this post because such functionality is of course available :) Unfortunately I haven't found it in any documentation so now I'll try to fill this gap.

First thing we have to do is to provide custom descriptor with possible JStat options. This descriptor is just a text file containing something we'll call "jstat specification language". To make this custom file available to JStat we should place it in the following path: $HOME/.jvmstat/jstat_options
If you want to view the bundled options please refer to file in OpenJDK repository.

The specification language is pretty similar to json files, and it contains the group of option elements. Each option should be threaten as a set of columns that can be shown in single jstat executi…

Jakub is a software developer for whom coding is a way of life as well as a hobby.

He is focused on continuously improving software delivery processes by introducing new technologies and refining Lean methodologies.

For over 12 years of his professional career, he worked as a software developer, architect, team leader, and manager. He gained experience working on both sides of the delivery process, as a vendor and as a client. Today, he is a speaker, trainer, and CEO the online technical assessment platform, Devskiller.