by Bozho | May 4, 2019 | Aggregated, caching, Developer tips, spring, spring-boot
Caching is key for performance of nearly every application. Distributed caching is sometimes needed, but not always. In many cases a local cache would work just fine and there’s no need for the overhead and complexity of the distributed cache. So, in many applications, including plain Spring and Spring Boot, you can use @Cacheable on any method and its result will be cached so that the next time the method is invoked, the cached result is returned. Spring has some default cache manager implementations, but external libraries are always better and more flexible than simple implementations. Caffeine, for example is a high-performance Java cache library. And Spring Boot comes with a CaffeineCacheManager. So, ideally, that’s all you need – you just create a cache manager bean and you have caching for your @Cacheable annotated-methods. However, the provided cache manager allows you to configure just one cache specification. Cache specifications include the expiry time, initial capacity, max size, etc. So all of your caches under this cache manager will be created with a single cache spec. The cache manager supports a list of predefined caches as well as dynamically created caches, but on both cases a single cache spec is used. And that’s rarely useful for production. Built-in cache managers are something you have to be careful with, as a general rule. There are a few blogposts that tell you how to define custom caches with custom specs. However, these options do not support the dynamic, default cache spec usecase that the built-in manager supports. Ideally, you should be able to use any name in @Cacheable and automatically a cache...
by Bozho | Jul 4, 2017 | Aggregated, Developer tips, monitoring, spring-boot
Spring Boot Admin is a cool dashboard for monitoring your spring boot applications. However, setting it up is not that trivial. The documentation outlines two options: Including a client library in your boot application that connects to the admin application – this requires having the admin application deployed somewhere public or at least reachable from your application, and also making your application aware that it is being monitored. Using cloud discovery, which means your application is part of a service discovery infrastructure, e.g. using microservices Both are not very good options for simpler scenarios like a monolithic application being run on some IaaS and having your admin application deployed either on a local machine or in some local company infrastructure. Cloud discovery is an overkill if you don’t already need it, and including a client library introduces the complexity of making the admin server reachable by your application, rather than vice-versa. And besides, this two-way dependency sounds wrong. Fortunately, there is an undocumented, but implemented SimpleDiscoveryClient that let’s you simply run the Spring Boot Admin with some configuration on whatever machine and connect it to your spring boot application. The first requirement is to have the spring boot actuator setup in your boot application. The Actuator exposes all the needed endpoints for the admin application to work. It sounds trivial to setup – you just add a bunch of dependencies and possibly specify some config parameters and that’s it. In fact, in a real application it’s not that easy – in particular regarding the basic authentication for the actuator endpoints. You need a separate spring-security (in addition to your...
Recent Comments