We have started using the Spring Boot application with Bulkheads ie Resilieance4j ThreadPoolBulkhead. We have added around 10+ Bulkheads in the application.
Now the Java execution time has been increased to 60ms from 20ms. We are using ThreadPool Bulkhead with CompletableFuture. As per the new Relic, we could see that this increase in time is due to CompletableFuture.
Spring Version - 2.2.6.RELEASE
Resilience4j Bulkhead Version - 1.7.0
Any suggestions, please?
Related
I know that Spring Boot 2.7 has an integration with Spring for GraphQL 1.0. However, I cannot find any information at which milestone of Spring Boot 3 the integration with GraphQL is scheduled. Any hint is appreciated.
There is no concrete, official plan right now but our intent is to have something out in time for Spring Boot 3.0. Spring for GraphQL just got out, so we're missing critical feedback to better understand the community.
Since Spring Boot 3.0 is a major version, most projects are also releasing major versions. This might be a bit too soon for Spring for GraphQL and we could consider a 1.1.0 with a limited amount of new features and target a 2.0 later in the 3.x line.
The situation is unusual, but as always the team is listening to the community. When it's official, the plan will materialize as a new milestone and/or in a blog post.
Update: there is now a scheduled 1.1.0 version to be released in time for Spring Boot 3.0
We upgraded from Open JPA -2.4.3 with Spring 4.3.19.RELEASE to Hibernate-
5.4.8.Final with Spring-5.2.6.RELEASE. We had to change ORM provider since spring 5.0 and related Spring Data did not have an OpenJPA vendor adapter. Upgrade caused Performance issues for our Batch Jobs, they were running 10 times slower than before.
We finally ended up migrating the non performing queries to Native SQL Queries.
From performance dumps it Sessions are not being released after the transaction is committed in Hibernate
Question:
Has anyone encounter similar issues and how they resolved it?
One side note, not sure whether its related or not: we have observed is OpenJPA is using OpenJpa is using WeakHashMap and Hibernate is using Concurrent Hashmap.
[1]: https://i.stack.imgur.com/4hE3V.png - Using OpenJPA
[2]: https://i.stack.imgur.com/sXRiw.png - Using Hiberate
Hi I am using #kafkaListener from Spring Boot. I am consuming batch of messages. I am trying to use nack() method from Acknowledgment but looks like Spring Boot 2.1.8 does not support nack() method.
Is there any feature like nack() in Spring Boot 2.1.8
I want to throw an exception for an failure record and replay remaining records in next poll(). How can I achieve this in Spring Boot 2.1.8. Can I use SeekToCurrentBatchErrorHandler? How?
Spring Boot 2.1.x has been end of life for nearly a year; nack() was introduced in spring-kafka 2.3.x (comes with Boot 2.2.x, which is also end-of-life). The last 2.1.x release was 2.1.18.
See github.com/spring-projects/spring-boot/wiki/Supported-Versions
As you can see, Boot 2.3.x goes end of life soon, too.
There is no equivalent of nack() in earlier versions. See the project page for a matrix of spring-kafka/spring-boot versions.
spring.io/projects/spring-kafka#overview
Yes, you can provide similar functionality with the SeekToCurrentErrorHandler but you should really upgrade to a supported release.
I am facing a strange boot time issue. I have the latest version of Jhipster (6.8.0) alongside the latest Stripe Java (19.10.0).
The time the system takes to boot varies between 6-10 minutes on average after adding the Stripe library, where as if you put the Stripe library on a fresh spring boot installation it loads in less than 10 seconds.
I was wondering if anyone has had the same issue, on potentially which library is causing this disturbance at the boot time and how to solve it.
Many thanks
We have customized Spring cloud config as a centralized solution for enterprise as a result of which there are around 700 repos onboarded to our config server. It adds up to approx 7000 spring configuration properties and it will keep increasing. This used to work pretty fast in spring boot 1.5 but post-spring boot 2.0 Its taking a lot of time to map the configuration properties.
I am trying to upgrade it to Spring boot 2.1.8 along with spring cloud config 2.1.4 but application startup time and context refresh time has drastically increased when compared to spring boot 1.5.x.
Is there a way we can switch off relax binding or other mapping features and use it similar to spring boot 1.5?
I don't have an experience of managing such a big amount of properties, however I have some ideas that can be useful and point to the solution:
Why do you think its property resolution/relaxed binding rules? Maybe there are some more beans that get loaded and some of them are slow, all the can "contribute" to the slow startup time.
For modern machines 7000 properties is not such a big amount. So the chances are that even there was some performance degradation between spring boot 1.x and 2.x (in which I hardly believe) - it still won't be a "considerable" amount of time.
Since you've mentioned spring cloud config - it has a rest API that can by itself be checked for performance. If you have an actuator on the cloud config server, there is an endpoint that returns 50 last requests along with their execution times. So please check the execution times and compare between spring boot 1.5.x and 2.0.x
Last but not least - try to profile the application and see which beans are the real time consumers.