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
Related
I'm working with spring cloud consul as a config server and service discovery tool in test environment. according to the consul documentation, consul server need to be at least 3 to 5 recommended servers, and consul will automatically choose a leader server with internal election. The problem is in consul cluster, which server I need to choose to connect in my spring boot service? if leader server changed, what will happen to my service? what is the best practice of using consul server in a real production environment?
I need to mention that, I already studied consul website documentation, but what I need is a real example for architecture and best practice for production environment. note that my services have high TPS due to USSD transactions in a telecom company. Thanks in advance.
I have tried to connecting to consul server and I'm using it in a test environment as config and service discovery tool. I have nearly 100 service to use consul as their config and discovery server within an internal network with 100 VMs and containers.
I expect a architecture for production environment to use consul in real production environment with pros and cons.
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 am trying to build a batch service in an existing application that has server.port=8080 property configured in application.properties file. When I run the batch process and Spring Batch trying to bring up remote partitions(separate JVMs), spring cloud deployer local throws error saying
"\r\n\r\n***************************\r\nAPPLICATION FAILED TO START\r\n***************************\r\n\r\nDescription:\r\n\r\nThe Tomcat connector configured to listen on port 8080 failed to start. The port may already be in use or the connector may be misconfigured.\r\n\r\nAction:\r\n\r\nVerify the connector's configuration, identify and stop any process that's listening on port 8080, or configure this application to listen on another port.
Is there a way to make the framework generate random ports for worker partitions being the server.port property that is already configured in the application.properties as is?
Thanks.
A Spring Batch remote partitioning setup requires a message broker for the communication between the manager and workers, but it does not require any web capabilities. You seem to be deploying all your apps locally (manager and workers) as web applications, hence the port conflict when multiple workers are deployed.
You have at least two options:
Either set a random server port for each app (See how Spring Boot allows you to do that here)
Or, if the number of workers is fixed, set ports to distinct values statically.
I have a development environment in windows where I can access the spring build in both IP Address and Hostname(PC-Name) for my Eureka Config Server / Client. When I move it to the RedHat environment it does not recognize the URL if it is a hostname.
My main goal is to change the eureka client status page to point to the hysterix monitor for the eureka client's hysterix stream. The value of ${spring.cloud.client.hostname} resolves to the hostname. I was wondering what is the way to make it the current IP of the eureka client?
To be exact here is an example of what I want am trying to do.
eureka:
instance:
preferIPAddress: true
statusPageUrlPath: http://${spring.cloud.client.hostname}:${eureka.cloud.config.port}/hystrix/monitor?stream=http%3A%2F%2F${spring.cloud.client.hostname}%3A${server.port}%2Factuator%2Fhystrix.stream
It just so happen that the client and the server are both in the same machine so I am contented in using the client hostname for both the Eureka Config Server path and the Eureka Client hystrix stream.
Note that I already set the preferIPAddress to true but the generated hostname is still the value of "/etc/hostname". I saw some solution that explicitly specifies the IP Address in the Eureka Client Instance. But I prefer to make it dynamic so that the same code can run smoothly on either Development and Deploy environment.
What can I do so that the hostname can also be recognized the same as the ip address?
The answer has dawn upon me just now. I just changed the following to this.
${spring.cloud.client.hostname}
↓↓↓↓↓↓↓↓↓↓↓↓
${spring.cloud.client.ip-address}
I was thrown to a wrong conclusion because other sites would tell me to use this configuration ${spring.cloud.client.ipAddress} which does not work.
Probably there was a change in Finchley / Spring boot 2.0 version. If anyone can give me a link to a documentation or discussion describing the configuration change, it would be helpful.
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