Trying to upgrade from spring boot 1 to 2, The problem I'm facing is with tracing
In spring boot 1, we are using sleuth Trace that seems like deprecated in the spring boot 2 and suggesting to use 'brave'.
One of the problems is our another microservices are using spring boot 1, how I can carry the Span in spring boot 2? It is deprecated.
I tried to use the sleuth old version, but getting conflicts and spring application is failing to start
If one of your applications is using sleuth 1.x and the other 2.x they will be able to pass and continue the tracing context. In the wiki page here we describe how to migrate from one version to another https://github.com/spring-cloud/spring-cloud-sleuth/wiki/Spring-Cloud-Sleuth-2.0-Migration-Guide
Related
Does the Apache Ignite operate on a spring framework basis?
Can I register a spring controller in classpath at server remote node and use it?(using component , like #Controller)
Apache Ignite is integrated with Spring but isn't based on it.
You can register spring beans when starting remote node (using normal spring approach) and then use them from e.g. compute or distributed services.
I'm not sure if you can register beans remotely in runtime, but I don't see why not.
wanted to try some new stuff and decided to build next micro-app in Ktor + Koin + Exposed. Everything looks really nice but I found one problem that is actually destroying the whole idea.
App needs DB access and the connection cannot be stored within repository but should be encrypted on config-server. Every other micro-app is suing spring boot and fetches configs with lib spring-cloud-config-client but I don't know if it's even possible to use that somehow from Ktor app. Anyone had the same problem and managed to fix it somehow?
Cfg4j seems to be an alternative to Spring Cloud Config Server.
https://github.com/cfg4j/cfg4j
Other than that, there are a few articles and some questions on SO about integrating Spring Cloud Config Server with non Spring Boot projects.
Spring Cloud Config Client Without Spring Boot
Also, I am working on an external configuration parser for Kotlin and am considering to implement similar functionality.
I had used Spring framework in my apps and while it is nice conceptually, it is not suitable for real-time apps due to its run-time overhead. For instance, http://apache-ignite-users.70518.x6.nabble.com/Failed-to-map-keys-for-cache-all-partition-nodes-left-the-grid-td23510.html shows the actual run-time Spring stack.
The Spring features that Ignite uses for loading application-defined beans are just many layers wrapped around simple Java reflection features. So Why Ignite uses Spring instead of straight Java'reflection ?
To make Ignite more performant, is there plan with Ignite to switch from Spring framework to Java reflection features ?
Similarly, if Ignite uses Spring Boot to handle port requests, why does it not use a light-weight framework such as www.sparkjava.com ?
Ignite uses Spring only to convert XML configuration files into configuration beans during startup. This way Ignite provides a convenient well-known way of configuring instead of introducing a custom one. In the runtime, after node is started, Spring is not used for anything.
In the thread you provided it's actually other way around - Spring invokes Ignite. Apparently, that's a Spring application with an embedded Ignite node.
I'm working with a Spring Boot 2.0.2 application and I want to configure RabbitMq to retry failed messages 3 times, with an interval between each retry.
Previously on Spring Boot 1.5.1 I have successfully setup this on application.properties:
spring.rabbitmq.listener.retry.enabled=true
spring.rabbitmq.listener.retry.initial-interval=45000
spring.rabbitmq.listener.retry.max-attempts=3
spring.rabbitmq.listener.retry.multiplier=1.3
spring.rabbitmq.listener.retry.max-interval=80000
I've tried do the same on Spring Boot 2.0.2 but it doesn't work. I've read that these properties have changed in Spring Boot 2.0, but even after updating the properties, it still doesn't work:
spring.rabbitmq.listener.direct.retry.enabled=true
spring.rabbitmq.listener.direct.retry.initial-interval=45000
spring.rabbitmq.listener.direct.retry.max-attempts=3
spring.rabbitmq.listener.direct.retry.multiplier=1.3
spring.rabbitmq.listener.direct.retry.max-interval=80000
Am I missing something?
The default container type is simple.
Use spring.rabbitmq.listener.simple.retry.enabled=true unless you decide to use the direct container type instead.
See Choosing a Container.
The DMLC was added in Spring AMQP 2.0; the boot properties were deprecated in a later 1.5.x release, switching to the ...simple... properties in preparation for Boot 2.0.
I'm trying to deploy a Mule application which uses Hazelcast to cache the result of some methods that are frequently used. However, while deploying the application I got the following error:
java.lang.ClassCastException: Cannot cast com.hazelcast.client.txn.ClientTxnPortableHook to com.hazelcast.nio.serialization.PortableHook
at java.lang.Class.cast(Class.java:3176) ~[?:1.7.0_79]
at com.hazelcast.util.ServiceLoader$1.next(ServiceLoader.java:97) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.load(PortableHookLoader.java:48) ~[hazelcast-3.1.6.jar:3.1.6]
at com.hazelcast.nio.serialization.PortableHookLoader.(PortableHookLoader.java:41) ~[hazelcast-3.1.6.jar:3.1.6]
I've tried to use the loader override function by placing the next setting in mule-deploy.properties:
loader.override=-com.hazelcast
The Mule application uses Hazelcast 3.5, and Mule 3.6.2 EE uses Hazelcast 3.1.6. Can you tell me a possible solution?
I have reviewed the link provided by Enrique (ClassCastException when casting to the same class) and it was useful because there were two different classpaths, but there were other aspects to be considered in the solution of the problem:
The Hazelcast versions were different. The Mule application used Hazelcast 3.5, and Mule 3.6.2 EE used Hazelcast 3.1.6.
There was not log configuration for Hazelcast in the mule server.
Because I really need to use the Hazelcast 3.5, it was not a choice to downgrade the Hazelcast to 3.1.6. So, I had to replace the version of the Hazelcast in the mule server to 3.5 and remove this library from the Mule application. And then I had to made a lot of tests to discard possible incompatibility issues. The tests were successful.
For the log configuration for Hazelcast in the mule server, I had to add the next JVM parameter to the mule server wrapper:
wrapper.java.additional.44=-Dhazelcast.logging.type=log4j
I used "log4j" because I was using Log4j2. You can see more information about this configuration in the next link:
http://docs.hazelcast.org/docs/3.5/manual/html/logging.html