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
Related
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?
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.
Anyone else seeing build performance issues with Spring Boot 1.4.3? Our previous builds with SpringBoot 1.4.2 were taking about 48 seconds with the following gradle command:
gradlew clean build
After only migrating to Spring Boot 1.4.3 (and therefore pulling in all the associated libraries), they're taking about 3 minutes and 47 seconds.
In our project we have to update the spring jars to the latest provided across our company.
In this process I updated spring jars from 3.1.1 to 3.2.4 and spring security jars(spring-security-config,spring-security-core,spring-security-taglibs,spring-security-web) from 3.1.1 to 3.1.4
Once this update is done, My application is behaving in a strange manner.
If I am idle on the application for few secs (10sec), I am getting access denied and my application is redirecting to login page.
I rolled back spring security related jar back to 3.1.1 after which it is behaving good.
But I have to update security jars also
Can someone let me know the reason why I am ending in that scenario with spring security 3.1.4 jars?
we had a same issue one of my senior developer has workaround by pinging or hitting all the application URL before reaching the idle window time for 10s or 15s , then application was stable now , but this was an very annoying behavior!..
we are using spring-security for 3.1.0.release...
We have an application that is currently running spring 2.5.6 and mule 2.2.1. We have decided to go ahead and upgrade the app to use spring 3.2 we also upgraded spring security to 3.1. I understand that Mule 2.2.1 uses spring 2.5.6 for configuration and so forth. We were to re-factor our code and build the entire project. However after deploying the application and starting the server, my server started in about 6 seconds instead of the normal 30 seconds and then I noticed that none of my services were not loaded. Unfortunately after days of investigating I cannot find where everything fails, as there are no errors in any of the logs including spring and mule logs. My question is it possible to get these to play together or should I just forget about getting this to work.
I read this post http://lifeinide.blogspot.com/2012/07/spring-3-and-mule-2-initialized-by.html and followed these instruction and still was not able to get it work. Mule says it started up just fine without any errors but I can hit any of my services. Any help? Thanks
Thanks #genjosanzo for the pointer. It helped met dig into this issue better and eventually make it work.
#mtanzania,
We had a similar need like yours - need to make Mule 2.2.1 work with Spring 3.2.x releases. Upgrade to Mule 3 involved rewrite of Mule extensions such as exception handling strategies, a RabbitMQ Mule transport etc. Upgrade to Mule 3 was therefore ruled out.
In order to make this work, you need to rewrite/update 3 java files from your module:
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:2.2.1
with implementations from :
groupId:org.mule.modules
artifactId:mule-module-spring-config
version:3.4.0
To be more specific, you need these classes to be updated/upgraded: MuleBeanDefinitionDocumentReader.java, MuleApplicationContext.java and SpringXmlConfigurationBuilder.java
With these updated versions, you can continue to create the MuleContext like:
SpringXmlConfigurationBuilder springConfigBuilder = new SpringXmlConfigurationBuilder(muleConfigPaths);
MuleContext context = new DefaultMuleContextFactory().createMuleContext(springConfigBuilder)
The modified implementations are here : Mule in Trooper and sample class that uses this is here : Trooper Mule container
Mule uses some internal spring API to parse the mule configuration and creates the correspondent beans.
For this reason the upgrade might work with spring 3.0.x but I'm pretty sure that something got broken with spring 3.1.x (i.e. this code has been introduced to maintain backward compatibility).
How about upgrading mule as well? Most of the 2.2.x syntax is still supported and many new feature has been introduced in newer mule versions.
FWIW, the above answer from #regunathb is right on. Patching in those three classes works. However, it is important to note that the 3.4 version of those classes from mule-module-spring-config will not work as-is. You must get the modified versions of the classes that #regunathb posted on GitHub, otherwise you'll end up with various incompatibilities between 3.4 and 2.2.1.