I have a Eureka Server and a Service consumer which get registered when i use Eureka server with Default:8761 port but fails when i change eureka server port to 9000.
I have already specified eureka.client.service-url.defaultZone=http://localhost:9000/eureka in both the eureka server and the consumer application.properties files
Related
This entire code is available at: https://github.com/Naresh-Chaurasia/API-MicroServices-Kafka/tree/master/Microservices-CQRS-SAGA-Kafka/DiscoveryService
I have following spring-boot setup.
Client/Postman is calling API gateway (which is also acting as load balancer).
The API gateway and Products are spring boot application/Microservices with are registered with Eureka
Discovery Service (Also Spring Boot Application).
I run the applications in following order: Eureka discovery service, Products, API Gateway
In the pom.xml file for Products, I have following entry:
<dependency>
<groupId>org.axonframework</groupId>
<artifactId>axon-spring-boot-starter</artifactId>
<version>4.4.7</version>
</dependency>
I am using following Axon Server: AxonServer-4.5.5.jar to run the Axon Server, and the axonserver.properties entry is as follows:
server.port=8026
axoniq.axonserver.name=My Axon Server
axoniq.axonserver.hostname=localhost
axoniq.axonserver.devmode.enabled=true
The default port for Axon server is 8024. I have tried running it on 8024, 8025, 8026 by updating the axonserver.properties file. The Axon server is running on localhost.
Every time I change the port in Axon server by updating the axonserver.properties file, the Product Microservice identifies the Axon server, even though Axon Server is not running on default port. I do not specify Axon server port in the Product Microservice.
My Question is: Even though I NOT am Specifying the port in Product Microservice, how is it that the Product Microservice identifies the correct port.
I believe you are missunderstanding the ports here.
Axon Server has 3 ports:
server.port: HTTP port for the Axon Server console. Default is 8024;
port: gRPC port for the Axon Server node. Default is 8124;
internal-port: gRPC port for communication between Axon Server nodes within a cluster (Axon EE only). Default is 8224.
So, a default AF application will always try to connect to an Axon Server running at 8124, which is the gRPC port. The 8024 port is used for you to access AS dashboard (and other more specific things, like the Rest API endpoints).
To add a bit more, you can check the ref-guide for the full list of properties and configuration here: https://docs.axoniq.io/reference-guide/axon-server/administration/admin-configuration/configuration#configuration-properties
I'm new to Axon server. I tried to work with Axon server with spring boot.
I installed the axon server on one of my cloud instances. when I run the spring boot application, the application finds the local Axon server. but there is no local one in my case.
I couldn't find a method to configure the IP address in the property file. if you know how to configure the remote host of the Axon server in Spring boot application please help me to do it.
The error like below,
Requesting connection details from localhost:8124
Connecting to AxonServer node [localhost:8124] failed: UNAVAILABLE: io exception
Failed to get connection to AxonServer. Scheduling a reconnect in 2000ms
Thanks.
To configure the location of Axon Server, add the following property to the application.properties file:
axon.axonserver.servers=<hostname/ip address>:<port>
If you are running Axon Server on the default port, you can omit the port number.
I'm using spring cloud eureka for microservice registration in a dockerised environment on aws.
As i'm using dockers ephemeral port mapping the port exposed on the container host is unknown. To overcome that i've a custom EurekaInstanceConfigBean that asks the docker daemon on the host for the assigned port so i can use that to register with eureka.
That all works fine until registration starts. The EurekaDiscoveryClientConfiguration contains a #EventListener(EmbeddedServletContainerInitializedEvent.class) that overrides the external port i've assigned in my custom EurekaInstanceConfigBean and sets it back to the local port inside the container.
I think the listeners purpose is to support auto port assignment in case of server.port=0 but in my setup it's breaking things.
The question is: Can i somehow stop the EurekaDiscoveryClientConfiguration to override my manually set port? Can i somehow use my own EurekaDiscoveryClientConfiguration?
You could use host networking and thus the docker container uses the network stack of the host which makes the service accessible on it's IP addresses.
I used this by utilizing docker-compose. The services all have random ports despite the edge services which are working as reverse proxy (in my case zuul based). these edge services have stable ports.
My microservice with #EnableTurbine config:
turbine:
clusterNameExpression: new String('default')
appConfig: bestallning
bestallning is a #SpringCloudApplication, hystrix.stream is enabled. It registers in eureka and turbine app can find it. But it has management.port set to 8092 and server.port 8082. hystrix.stream binds to management.port
Turbine now tries to fetch hystrix.stream from server.port of bestallning, not management.port that hystrix.stream is bound to.
Fetching instance list for apps: [bestallning]
Fetching instances for app: bestallning
Received instance list for app: bestallning, size=1
Retrieved hosts from InstanceDiscovery: 1
Found hosts that have been previously terminated: 0
Hosts up:1, hosts down: 0
Url for host: http://143.237.21.196:8082/hystrix.stream default
Could not initiate connection to host, giving up: [{"timestamp":1460035761979,"status":404,"error":"Not Found","message":"No message available","path":"/hystrix.stream"}]
Stopping InstanceMonitor for: 143.237.21.196 default
Is it possible to have turbine look for hystrix.stream using the correct port?
I think you'd have to write your own InstanceDiscovery (and create a #Bean of that type). Might be a useful feature in the existing implementations though, so please open an issue in Spring Cloud Netflix.
We've three Spring Boot applications:
Eureka Service
Config Server
Simple Web Service making use of Eureka and Config Server
I've set up the services so that we use a Eureka First Discovery, i.e. the simple web application finds out about the config server from the eureka service.
When started separately (either locally or by starting them as individual docker images) everything is ok, i.e. start config server after discovery service is running, and the Simple web service is started once the config server is running.
When docker-compose is used to start the services, they obviously start at the same time and essentially race to get up and running. This isn't an issue as we've added failFast: true and retry values to the simple web service and also have the docker container restarting so that the simple web service will eventually restart at a time when the discovery service and config server are both running but this doesn't feel optimal.
The unexpected behaviour we noticed was the following:
The simple web service reattempts a number of times to connect to the discovery service. This is sensible and expected
At the same time the simple web service attempts to contact the config server. Because it cannot contact the discovery service, it retries to connect to a config server on localhost, e.g. logs show retries going to http://localhost:8888. This wasn't expected.
The simple web service will eventually successfully connect to the discovery service but the logs show it stills tries to establish communication to the config server by going to http://localhost:8888. Again, this wasn't ideal.
Three questions/observations:
Is it a sensible strategy for the config client to fall back to trying localhost:8888 when it has been configured to use discovery to find the config server?
When the eureka connections is established, should the retry mechanism not now switch to trying the config server endpoint as indicated by Eureka? Essentially putting in higher/longer retry intervals and periods for the config server connection is pointless in this case as it's never going to connect to it if it's looking at localhost so we're better just failing fast.
Are there any properties that can override this behaviour?
I've created a sample github repo that demonstrates this behaviour:
https://github.com/KramKroc/eurekafirstdiscovery/tree/master