I have a micro-service written in spring boot and registered with Eureka. All I need to do is test the circuit breaker using Hystrix i.e I have an endpoint which will fetch me some data from the db and in case if anything goes wrong i have a fallback method to execute which gives me a mocked response. Everything works fine with the code I have written.
Thee problem I face is that during start of my application it successfully registers with eureka with status UP. The moment I shutdown my database to test the circuit breaker Eureka marks the service as down but still the service works fine.
I really could not understand the reason why Eureka says the service as DOWN.
Related
I have two stateless service.
I'm trying to run an integration test, with the real implementation when i have it deployed to a cluster. I can see that service 2 does its job and service one sends the event correctly.
The scenario i want to achieve is for service 1 to publish an event which service 2 receives, which in turn runs a method, like writing to file.
when i create a service in the unit test level, i can publish the event but never reaches service 2.
How can i simulate communication between services?
service 1 can be a fake object, as long it fires the correct event to service 2.
at the moment i'm creating a method and just call the action in service 2 directly, this verifies that action service 2 is working but it doesn't check that service 1 is really talking to service 2.
You can use https://github.com/loekd/ServiceFabric.Mocks for that purpose.
I've built up a Spring Cloud Config Server integrated using Spring Cloud Bus via Kafka for refreshing properties dynamically. I've another application that is Spring Cloud Gateway that consumes those properties and refreshes them dynamically.
One of the things I'm struggling with is if I (unintentionally) update a bad property (for example: spring.cloud.gateway.routes[0].predicates[0]=Path=/demo/{demoId\:[0-9]+}, here backslash is something that is wrong here) in a Spring Gateway route.
The routing breaks in Spring Cloud Gateway with the error something like unable to initialize bean GatewayProperties and things starts behaving weirdly.
Two questions:
Is there a way to ignore bad config refresh events? Probably skipping refresh event that has a bad config.
If it's possible, Is there a way to evaluate those properties even before those are applied to the Spring context?
I am trying to setup an environment with Docker containers in which I run Spring Cloud Applications. I am using Zuul as gateway and Eureka for service discovery.
Now, what I am trying to do, is when I send SIGTERM signal through docker stop command and the Java process is shutting down, I need to catch somehow this event, put the service OUT_OF_SERVICE in Eureka registry, then wait some time, and then shut it down, as mentioned by #spencergibb here: Make Spring Cloud app to wait for eureka clients to remove it before fully shutting down
Do you happen to know how to do this?
You can use actuator's shutdown endpoint /actuator/shutdown to gracefully shutdown spring cloud application, consider doing that in an JVM shutdown hook.
I'm going to write a quick little SF service to report endpoints from a service to a load balancer. That part is easy and well understood. FabricClient. Find Services. Discover endpoints. Do stuff with load balancer API.
But I'd like to be able to deal with a graceful drain and shutdown situation. Basically, catch and block the shutdown of a SF service until after my app has had a chance to drain connections to it from the pool.
There's no API I can find to accomplish this. But I kinda bet one of the services would let me do this. Resource manager. Cluster manager. Whatever.
Is anybody familiar with how to pull this off?
From what I know this isn't possible in a way you've described.
Service Fabric service can be shutdown by multiple reasons: re-balancing, errors, outage, upgrade etc. Depending on the type of service (stateful or stateless) they have slightly different shutdown routine (see more) but in general if the service replica is shutdown gracefully then OnCloseAsync method is invoked. Inside this method replica can perform a safe cleanup. There is also a second case - when replica is forcibly terminated. Then OnAbort method is called and there are no clear statements in documentation about guarantees you have inside OnAbort method.
Going back to your case I can suggest the following pattern:
When replica is going to shutdown inside OnCloseAsync or OnAbort it calls lbservice and reports that it is going to shutdown.
The lbservice the reconfigure load balancer to exclude this replica from request processing.
replica completes all already processing requests and shutdown.
Please note that you would need to implement startup mechanism too i.e. when replica is started then it reports to lbservice that it is active now.
In a mean time I like to notice that Service Fabric already implements this mechanics. Here is an example of how API Management can be used with Service Fabric and here is an example of how Reverse Proxy can be used to access Service Fabric services from the outside.
EDIT 2018-10-08
In order to abstract receive notifications about services endpoints changes in general you can try to use FabricClient.ServiceManagementClient.ServiceNotificationFilterMatched Event.
There is a similar situation solved in this question.
I'm a bit confused with this configuration. My Spring Boot app with #EnableDiscoveryClient has spring.cloud.consul.host set to localhost. I'm running a Consul Agent on the host where my Boot app is running, but I've a few questions (can't seem to find my answers in the documentation).
Can this config accept multiple values?
If so, I'd prefer to set the values to a list of Consul server addresses (but then, what's the point of running Consul Agents at all, so this doesn't seem practical, which means I'm not understanding something here)
If not, are we expected to run a Consul Agent on every node a Boot app with #EnableDiscoveryClient is running? (this feels wrong as well; for one, this would seem like a single point of failure even though one agent should be able to tell everything about the cluster; what if I can't contact this one agent?)
What's the best practice for this configuration?
Actuallly this is Consul itself to solve your problem. An agent is runing on every server to handle clustering, failures, sharing data, autodiscovery etc. for you so that you don't neen to know the other hosts in your Spring Boot configuration. Spring Boot app always connects to the agent running on the same machine.
See https://www.consul.io/docs/agent/basics.html