I am following Josh Long's presentation at https://www.youtube.com/watch?v=5q8B6lYhFvE&feature=youtu.be . I am following his examples. At about 34 minutes in he demos setting up the Eureka service.
This service uses the config-service. My config service is running and exposes the information the eureka service needs. I have checked my bootstrap.properties and they look correct according to his presentation. However the eureka service does not complete and does not seem to be accessing the config service. My other service does reach the config service and works fine.
The eureka service should come up at http://localhost:8761/ but does not. It is at 8080.
eureka service bootstrap.properties:
spring.application.name= eureka-service
spring.cloud.config.uri= http://localhost:8888
First error:
2016-10-13 18:43:00.088 ERROR 7464 --- [ main] c.n.d.s.t.d.RedirectingEurekaHttpClient : Request execution error
com.sun.jersey.api.client.ClientHandlerException: java.net.ConnectException: Connection refused: connect
Second error
2016-10-13 18:43:00.097 ERROR 7464 --- [ main] com.netflix.discovery.DiscoveryClient : DiscoveryClient_EUREKA-SERVICE/RB-64-PC.Home:eureka-service - was unable to refresh its cache! status = Cannot execute request on any known server
com.netflix.discovery.shared.transport.TransportException: Cannot execute request on any known server
Found the problem. I had accidently added the "config server" dependency into the project when I created it. I am using the site "http://start.spring.io/" as per the video. Adding the config server dependencies kept the initialization from accessing the actual config server running on another port.
Related
I followed steps as mentioned in Azure ServiceBus JMS Sample with below properties
spring.jms.servicebus.connection-string=Endpoint=sb://test-dt.servicebus.windows.net/;SharedAccessKeyName=RootManageSharedAccessKey;SharedAccessKey=key
spring.jms.servicebus.topic-client-id=12345
spring.jms.servicebus.idle-timeout=18000
spring.jms.servicebus.pricing-tier=Standard
however I get below error
ERROR 43904 --- [ntContainer#0-1] org.apache.qpid.jms.JmsConnection : Failed to connect to remote at: amqps://test-dt.servicebus.windows.net:-1
ERROR 43904 --- [ntContainer#0-1] o.s.j.l.DefaultMessageListenerContainer : Could not refresh JMS Connection for destination 'test-topic' - retrying using FixedBackOff{interval=5000, currentAttempts=6, maxAttempts=unlimited}. Cause: handshake timed out after 10000ms
On the other hand, I followed steps as mentioned in ServiceBus without JMS and added transportType as AmqpTransportType.AMQP_WEB_SOCKETS then I am able to connect.
We want to implement using spring boot starter and listener method, instead of calling from (public static void main) method.
Please guide on what am I missing when following first link
ERROR 43904 --- [ntContainer#0-1] org.apache.qpid.jms.JmsConnection : Failed to connect to remote at: amqps://test-dt.servicebus.windows.net:-1
To resolve above error, try as suggested by Anand Sowmithiran:
Check if port 5671 is blocked:
telnet <yournamespacename>.servicebus.windows.net 5671
Note: Clients that use AMQP connections over TCP require ports 5671 and 5672 to be opened in the firewall. Along with these ports, it might be necessary to open additional ports if the EnableLinkRedirect feature is enabled.
You can refer to Troubleshooting guide for Azure Service Bus, AMQP outbound port requirements and Port 5671 Blocked :(. What are other options?
In my Java application, I have kept the server port at: 8090
And the property management.port=9080
Now, in my browser, when I open a random link (http://localhost:9080) on the actuator port, my application throws the following error:
No mapping found for HTTP request with URI [/] in DispatcherServlet with name 'dispatcherServlet'
23/11/2018:18:47:54.350 [http-nio-9080-exec-1] E o.a.c.c.C.[.[.[.[dispatcherServlet] --- Servlet.service() for servlet [dispatcherServlet] threw exception
java.lang.IllegalArgumentException: No converter found for return value of type: class java.util.LinkedHashMap
Whereas, when I put management.port=8090 (same as the server port), this error is not thrown when I open a random link.
Is there a way to add a default request handler on the actuator port when it is different from the server port in a spring boot application?
In a standalone application, the Actuator HTTP port defaults to the same as the main HTTP port. To make the application listen on a different port, set the external property: management.server.port. To listen on a completely different network address (such as when you have an internal network for management and an external one for user applications), you can also set management.server.address to a valid IP address to which the server is able to bind.
I've deployed my Java web application to a AWS server, but I get an 502 proxy error like this when making a get request:
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /product.
Reason: Error reading from remote server
The database connection works fine if the application is deployed locally with an online database.
I've tried to configure .ebextensions and my YAML file looks like these:
option_settings:
option_name: Timeout
value: 1000
This is my draft version of my site and you can see the error code: http://platformaruralpreno.eu-west-2.elasticbeanstalk.com/product
So we have Java microservices written with Spring-Boot, using Consul for service discovery and config management and running in Docker containers. All of it is working, but when a container dies or a service restarts the old service-id never goes away in Consul and the service forever after shows as "Failing" in the Consul UI, even though the new container has registered and shows all Green.
We are not using heartbeat - but I cannot find much documentation on what the difference between heartbeat and healthcheck are for Consul.
Here's my bootstrp.yml
spring:
application:
name: my-service
cloud:
config:
enabled: false
consul:
host: ${discovery.host:localhost}
port: ${discovery.port:8500}
config:
watch:
wait-time: 30
delay: 10000
profile-separator: "-"
format: FILES
discovery:
prefer-ip-address: true
instanceId: ${spring.application.name}:${spring.application.instance_id:${random.value}}
There are other settings to enable heartbeat, but the docs say something about this putting more stress on the Consul cluster.
Has anyone managed to get Consul and Spring Boot/Docker services to actually de-register automatically? It actually doesn't cause any real problems, but it makes the Consul UI pretty useless to actually monitor for up/down services.
Consul doesn't automatically deregister services.
See https://groups.google.com/forum/#!topic/consul-tool/slV5xfWRpEE for the hint about the same question. According to that thread you need to either update the config or perform an Agent API call. Since the agent is the source of truth, you shouldn't try to update via Catalog API. See GitHub for details. They also mention at the Google group that you don't necessarily have to deregister services if the node goes down gracefully, but that doesn't seem to be your use case.
Please have a look at Consul not deregistering zombie services for hints about automating the service de-registration using either the api or tools like registrator.
You have mentioned you are using a docker container to run the microservice. Are you trapping the SIGTERM in your entrypoint script in docker container ? If a SIGTERM is sent, the boot application will get it and you will see the below log showing that the microservice is deregistering with Consul.
2017-04-27 09:20:19.854 INFO 6852 --- [on(6)-127.0.0.1] inMXBeanRegistrar$SpringApplicationAdmin : Application shutdown requested.
2017-04-27 09:20:19.857 INFO 6852 --- [on(6)-127.0.0.1] ationConfigEmbeddedWebApplicationContext : Closing org.springframework.boot.context.embedded.AnnotationConfigEmbeddedWebApplicationContext#afb5821: startup date [Thu Apr 27 09:20:00 EDT 2017]; parent: org.springframework.context.annotation.AnnotationConfigApplicationContext#130c12b7
2017-04-27 09:20:19.859 INFO 6852 --- [on(6)-127.0.0.1] o.s.c.support.DefaultLifecycleProcessor : Stopping beans in phase 2147483647
2017-04-27 09:20:19.863 INFO 6852 --- [on(6)-127.0.0.1] o.s.c.support.DefaultLifecycleProcessor : Stopping beans in phase 0
2017-04-27 09:20:19.863 INFO 6852 --- [on(6)-127.0.0.1] o.s.c.c.s.ConsulServiceRegistry : Deregistering service with consul: xxxxxxxxxxxxx
This blog post discusses this.
Context
We are using Spring Cloud Netflix with Eureka as the service discovery and Zuul for proxying the services and load balance them.
The microservices are implemented using NodeJS and are registered at Eureka using the NPM module eureka-js-client and a custom layer in between that handles the configuration and stuff that is generic for all microservices.
Problem
The problem is that Eureka does not recognize if one service goes down. This is a problem as we are having a development infrastructure with autodeployment that redeploys and restarts the microservices on different ports each time without restarting Eureka (and Zuul).
Therefore after a while we have ten or more instances of one microservice where only one is up but all are recognized as beeing UP.
Solution Approach
I tried setting the heartbeatInterval on the client lesser but that does not help.
I tried setting the renewalThresholdUpdateIntervalMs on the server lesser but that does not help either.
Many more frustrating, non-helping property tries…
Question
How do I configure Eureka to evict instances or to set status to DOWN of the instances that do not send a heartbeat in a reasonable time (not 30 minutes or so)?
Code Snippets
The server itself does not contain mentionable code (just a few annotations to start the Eureka server using Spring Cloud Starter).
The configuration of the Eureka server (I have removed all non-working tries):
server:
port: 8761
spring:
cloud:
client:
hostname: localhost
eureka:
instance:
address: 127.0.0.1
hostname: ${spring.cloud.client.hostname}
The client configuration that is sent to the server (using eureka-js-client):
{
instance : {
instanceId : `${CONFIG.instance.address}:${CONFIG.instance.name}:${CONFIG.instance.port}`,
app : CONFIG.instance.name,
hostName : CONFIG.instance.host,
ipAddr : CONFIG.instance.address,
port : {
'$' : CONFIG.instance.port,
'#enabled' : true
},
homePageUrl : `http://${CONFIG.instance.host}:${CONFIG.instance.port}/`,
statusPageUrl : `http://${CONFIG.instance.host}:${CONFIG.instance.port}/info`,
healthCheckUrl : `http://${CONFIG.instance.host}:${CONFIG.instance.port}/health`,
vipAddress : CONFIG.instance.name,
secureVipAddress : CONFIG.instance.name,
dataCenterInfo : {
'#class' : 'com.netflix.appinfo.InstanceInfo$DefaultDataCenterInfo',
name : 'MyOwn'
}
},
eureka : {
host : CONFIG.eureka.host,
port : CONFIG.eureka.port,
servicePath : CONFIG.eureka.servicePath || '/eureka/apps/',
healthCheckInterval : 5000
}
}
after a while we have ten or more instances of one microservice where
only one is up but all are recognized as beeing UP.
Eureka has a 'self preservation' mode. Where if less than 85% of instances heartbeats are registering, it will not evict any instances. You should be able to see a warning on the eureka dashboard.