Spring Boot version 2.5.2
spring-cloud version 2020.0.3
WARNING at the time of application startup --
2021-07-10 12:30:58.286 WARN 21316 --- [ main] iguration$LoadBalancerCaffeineWarnLogger : Spring Cloud LoadBalancer is currently working with the default cache. You can switch to using Caffeine cache, by adding it and org.springframework.cache.caffeine.CaffeineCacheManager to the classpath.
Why this log line is printed as Warning? Is it bad to use Spring Cloud LoadBalancer's default cache?
The answer is provided in this GitHub issue spring-cloud 1050
More specifically this explanation can help you understand if it's bad to use the default cache or not, based on your project:
I would say Caffeine has definitely been much more used and tested in production, while the default solution, which at this point is Evictor, is a solution based on a ConcurrentMap implemented as a hash-map with added TTL support. I would recommend using Caffeine in a production application. However, if you would like to stick to the default solution, you would need to consider if based on the predicted cache entry volume and the TTL settings that you would be applying, a concurrent HashMap would be enough.
Related
In Grails 2 we used the "External configuration plugin", which included the method checkNow() for checking and refreshing values from an external config file.
Does it exist a simple approach for doing something similar in Grails 4+? I have seen references to Spring Cloud Config Server, but it seems a bit overkill for me. All I really want to do is be able to (now and then) update a config value in runtime. It could also be purely by a few lines of code, and does not have to originate from changes in the config file. This would avoid having to restart our server for minor changes in config. Thanks!
I'm replying to myself with a ridiculously simple answer: "just change it". Using the console plugin (or any other form of code execution), I can just assign grailsApplication.config.any.property a new value. It won't persist and it won't update any listeners or anything. But it is a glaringly obvious solution that I just assumed wouldn't work due to the getProperty() calls (I interpreted the name as reading from file) and googled discussions about Spring Cloud Config.
So, move on... nothing to see here. Just mild embarrassment :-P
I noticed that my app running in Kubernetes doesn't actually get registered in grafana unless I add the following deployer properties:
deployer.*.kubernetes.podAnnotations=prometheus.io/path:/actuator/prometheus,prometheus.io/port:8080,prometheus.io/scrape:true
Is that supposed to be the case? If so, how can I add add these deployer properties to always be there for every deployment without having to manually add it in the Freetext section before deployment.
Thank you! That helped me track down the answer. I tried putting those properties in (and I might have messed up putting them in) but they kept showing up as app properties and not deployer properties. Then I tried something very similar in the skipper config:
data:
application.yaml: |-
spring:
cloud:
skipper:
server:
platform:
kubernetes:
accounts:
default:
podAnnotations: 'prometheus.io/path:/actuator/prometheus,prometheus.io/port:8080,prometheus.io/scrape:true'
...
And it worked beautifully. Sabby, thanks again!
What you're attempting to accomplish can be solved with the help of "global" property configuration in SCDF.
See: Common Application Properties
However, please note that this method will apply the desired configurations to every stream application that SCDF deploys on the targeted platform. IMO, it is a valid use of it since you'd need metrics scraping for all the deployed apps anyway.
Also, as a FYI, a similar property is available for Task apps.
I deployed spring-cloud-dataflow-server-cloudfoundry to SAP Cloud Fondry with environments below:
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_URL:https://api.cf.sap.hana.ondemand.com
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_ORG:{org}
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_SPACE:{space}
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_DOMAIN:{doamin}
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_USERNAME:username
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_PASSWORD:password
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_SKIP_SSL_VALIDATION:false
SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_STREAM_SERVICES: mq
And import stream starter apps using bulk import applications.
And I create stream using "time-source-rabbit-1.3.0.RELEASE.jar" and "log-sink-rabbit-1.3.0.RELEASE.jar".
But I cannot deploy stream.
The status is "partial" fianlly, and apps' runtime are failed.
My question is:
1. Whether spring-cloud-dataflow-server-cloudfoundry can be used in SAP cloud foundry like I used?
2. When deploy stream in cloudfoundry using spring-cloud-dataflow-server-cloudfoundry dashboard, should I set any other necessary properties?
Thanks in advance.
Looking at the manifest.yml, it appears that org, space, and domain weren't replaced with SAP-CF specific values. Pay attention to the following note in the ref. guide.
Now we can configure the app. The following configuration is for Pivotal Web Services. You need to fill in {org}, {space}, {email} and {password} before running these commands.
If you have them replaced with your environment specific properties, the next step is to check the SCDF-server's logs. There will be particular details as to why the deployment failed if it did.
Now to answer your questions.
For #1, it is hard to say without logs or environment details. We don't actively test against SAP distribution of Cloud Foundry. As far as the distribution is compatible with Diego 1.7.1 and over, it should work. We also publish the CF compatible versions in project site. Perhaps this could be useful to compare the SAP CF environment and its foundation versions.
For #2, no, you don't need any other properties.
I have a Spring Cloud Config app with the Spring Cloud Security dependencies. I'm trying to hit the /encrypt endpoint to encrypt a password.
According to the docs at http://cloud.spring.io/spring-cloud-config/spring-cloud-config.html#_key_management I believe I need to set a symmetric key using "encrypt.key". But I can't figure out where to put this; all combinations I've tried result in {"description":"No key was installed for encryption service","status":"NO_KEY"} when I attempt to POST to /encrypt.
If I POST a key to /key, the /encrypt works perfectly, so I'm pretty sure that everything else is setup correctly. It also works fine using the environment variable ENCRYPT_KEY, or by using a system property encrypt.key. I just can't figure out where to place the encrypt.key within a configuration file. Is there a sample on this?
Thanks #pVilaca, this is indeed what the documentation says, but setting the key in application.properties or application.yml won't work.
Through experimentation I've found that the only place you can set the encrypt.key property is an ENCRYPT_KEY environment variable, a system property, bootstrap.properties, bootstrap.yml, or calling the /key endpoint.
Not sure why application.properties or application.yml don't work in this case. Setting this key must have more of an impact on the startup process than it would appear.
Setting Spring Cloud Version to 'Brixton.SR5' worked for me. For some reason, setting 'encrypt.key' in either application.properties/yml or bootstrap.properties/yml in later Spring Cloud Version does not work anymore.
check properties tag of pom.xml file. If you are using version 2 or 3 of Dalston, change it to:
<spring-cloud.version>Dalston.SR1</spring-cloud.version>
and it should be working fine. In my case i was using version 3 and changing it to version 1 resolved the issue for me.
Reference:
https://github.com/spring-cloud/spring-cloud-config/issues/767
If you're using spring cloud with spring boot, that is the method that is described on the documentation that you mentioned, you've two 'main' properties files.
bootstrap.[properties,yml]
To modify the startup behaviour you can change the location of the config server using bootstrap.properties (like application.properties but for the bootstrap phase of an application context)
application.[properties,yml]
where the "application" is injected as the "spring.config.name" in the SpringApplication (i.e. what is normally "application" in a regular Spring Boot app)
source: Spring Cloud Config Documentation
So, it should be enough to set the encrypt.keyin your application.[properties,yml] file (or the alternative name if specified)
I'm investigating Grails vs. other Agile web frameworks, and one key use case I'm trying to support is the ability to modify controllers and install plugins post deployment. It appears that this isn't possible with Grails, but I want to make sure before I write it off.
As far as modifying controllers goes, it would be sufficient if the Groovlet behavior existed (compile-on-demand).
As far as plugin installs go, I understand this may be a long shot, but I thought I'd check to be sure.
For your information, I need this because I work on a product that requires a little site-specific customization, such as adding validation of simple meta-data, integrating with customer security environments, and maybe even including new controllers/pages quickly.
Out of the box, no, grails doesn't really support what you want. There may be ways to customize it but I've never looked into it. A PHP framework might be more of your ally since there is no real deployment process other than copying PHP files to a location.
That said, I personally would prefer a strict set of deployment policies. And honestly, deploying changes with Grails is as simple as running the 'grails war' command and copying that war to your servlet container. The site's downtime is negligible and if you have multiple web servers with a load-balancer, your customers should never see down time due to deployments.
Although it's not recommended for complex coding; You could execute groovy code from a string that you could store in database or a file on the fly at run time:
check out Groovy template engine:
http://groovy.codehaus.org/Groovy+Templates
but even then, you are still limited on what you can do or can't do let alone debugging will lack. you may want to consider an interpreted language; few to mention PHP/Perl/Coldfusion.