Hi I have installed Redis on AWS-EC2 instance. I am able to ping the instance from my local machine.
I have opened all ports on my EC2 instance so i should be able to connect and ping the Redis Server.
I am able to ping the EC2 server using the IP(public)
I want to hit the Redis server from my Windows local machine running Spring boot application(with Redission)
In my spring boot I have configured the file(Json) with Single Server Configurations. This is as described in the link below -
https://github.com/redisson/redisson/wiki/2.-Configuration
{
"singleServerConfig":{
"idleConnectionTimeout":10000,
"connectTimeout":10000,
"timeout":3000,
"retryAttempts":3,
"retryInterval":1500,
"password":null,
"subscriptionsPerConnection":5,
"clientName":null,
"address": "redis://<EC2-IP>:6379",
"subscriptionConnectionMinimumIdleSize":1,
"subscriptionConnectionPoolSize":50,
"connectionMinimumIdleSize":24,
"connectionPoolSize":64,
"database":0,
"dnsMonitoringInterval":5000
},
"threads":16,
"nettyThreads":32,
"codec":{
"class":"org.redisson.codec.FstCodec"
},
"transportMode":"NIO"
}
Then i am instantiating bean in my spring boot app-
#Bean(name="redissonClient",destroyMethod="shutdown") public
RedissonClient redissonClient() { return Redisson.create(config); }
However, i am getting an exception below -
2019-11-18 14:54:54.432 WARN 81628 --- [isson-netty-1-6] io.netty.channel.DefaultChannelPipeline : An exceptionCaught() event was fired, and it reached at the tail of the pipeline. It usually means the last handler in the pipeline did not handle the exception.
io.netty.handler.codec.DecoderException: CommandDecoder.decode() must consume the inbound data or change its state if it did not decode anything.
at io.netty.handler.codec.ReplayingDecoder.callDecode(ReplayingDecoder.java:379) ~[netty-codec-4.1.27.Final.jar:4.1.27.Final]
at io.netty.handler.codec.ReplayingDecoder.channelInputClosed(ReplayingDecoder.java:329) ~[netty-codec-4.1.27.Final.jar:4.1.27.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelInputClosed(ByteToMessageDecoder.java:359) ~[netty-codec-4.1.27.Final.jar:4.1.27.Final]
at io.netty.handler.codec.ByteToMessageDecoder.channelInactive(ByteToMessageDecoder.java:342) ~[netty-codec-4.1.27.Final.jar:4.1.27.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:245) [netty-transport-4.1.27.Final.jar:4.1.27.Final]
at io.netty.channel.AbstractChannelHandlerContext.invokeChannelInactive(AbstractChannelHandlerContext.java:231) [netty-transport-4.1.27.Final.jar:4.1.27.Final]
at io.netty.channel.AbstractChannelHandlerContext.fireChannelInactive(AbstractChannelHandlerContext.java:224) [netty-transport-4.1.27.Final.jar:4.1.27.Final
The link below points that this is fixed - https://github.com/redisson/redisson/issues/1566
and occurs when we can not communicate to the redis server.
As I have all ports opened on EC2 i don't think communication should be a problem for redis on port 6379. Still i am facing the issue. please help if any one has any idea or if i am missing something.
Thanks
Related
There are two microservices (microservice-A & microservice-B), written in Spring boot, are talking to each other through the Feign Client and the services are registered in K8S Native service registry
Whenever a fresh deployment of a microservice-A is happening, the microservice-B that is already running in kubertnetes fails to make HTTP call to the freshly deployed service-A and below is the exception
feign.RetryableException: No route to host (Host unreachable) executing GET http://microserice-a/api/v1/myresources
This issue is getting resolved immediately after restarting the microservice-B.
When we googled for solutions, we got to see this link https://github.com/spring-cloud/spring-cloud-netflix/issues/769 and an user had given the below comment there
I suspect the root cause is that FeignClient keeps an old list of service providers and the Ribbon cannot move correctly to the next node if one node has been destroyed
Not sure if that is correct root cause. Please comment If anyone has faced similar issue and solved it?
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 deploy Spring Boot microservices using Docker using Appmesh and EC2. I have deployed two sample microservices (https://github.com/amitgct/appmesh-hello) namely: caller-service and called-service using docker on a single EC2 instance and configured appmesh accordingly by following guide https://docs.aws.amazon.com/app-mesh/latest/userguide/getting-started-ec2.html. Currently, my applications are running on ec2 but they cannot communicate with each other and getting error on calling called-service from caller-service i.e. Unknown host. Can anyone tell me how can I specify hostname and register service with that host on EC2 and App mesh. (Note: I don't want to use kubernetes, ECS, AWS cloud map, AWS Route53) . If can provide example also then very thankful to you. Please help.
https://www.appmeshworkshop.com/servicediscovery/
here's a step by step process shown, and this is for http protocol...
but if you change the listeners section in virtual routes to tcp then it should work for TCP messages as well - for those systems which works on tcp protocol - example Akka Clusters
I'm trying to start two spring-boot (1.3.2.RELEASE) app instances on my dev machine. The app uses elasticsearch embedded (1.5.2) through spring data elasticsearch (1.3.2.RELEASE).
I configured instances to use different ports (-Dserver.port=8081), and this works well for my other app without elasticsearch.
So, my first instance starts normally, with second instance start I'm getting
Error: Exception thrown by the agent : java.rmi.server.ExportException: Port already in use: 54022; nested exception is:
java.net.BindException: Address already in use
I've tried to get more info from the logs, but it didn't help.
logging.level.org.elasticsearch=TRACE
I even tried
logging.level.root=TRACE
No mention about the port 54022. Google doesn't help much either.
Update: I start my instances in STS. When shutting down the instance (red square button in the console view) I see that STS connects to 54022 port. Maybe it's some kind of shutdown port?
andrey:~$ lsof -i tcp:54022
STS 447 andrey 36u IPv6 0xf4ba94cfea1e25e5 0t0 TCP localhost:49424->localhost:54022 (CLOSE_WAIT)
This problem is specific to STS IDE (Spring Tool Suite). This is not reproducible if you run the app from console.
54022 is JMX Port by STS.
To solve the issue go to Run > Run Configurations... > Spring Boot App > <your_run_config> > Spring Boot (Tab).
Toggle Enable Live Bean support or change the JMX Port.
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