Request processing error; nested exception is fake.Exception RetryableException: Connection timeout expired when executing GET http://fraud:8081/api/v1/fraud-check/6

[codersergg]

I'm doing a microservices deployment in k8s. Zipkin shows error: Request processing error; nested exception is fake.Exception RetryableException: Connection timeout expired when executing GET http://fraud:8081/api/v1/fraud-check/6 . Rabbitmq is not working. I can't figure out what's going on.

https://github.com/codersergg/microservices-and-distributed-systems

NAME READY STATUS RESTARTS AGE pod/customer-5b8d7cd7dd-7ppkv 1/1 Running 2 (22m ago) 45m pod/fraud-bc6fb777c-6fkdp 1/1 Running 2 (22m ago) 43m pod/notification-79997f988c-snwx7 1/1 Running 2 (22m ago) 44m pod/postgres-0 1/1 Running 2 (22m ago) 55m pod/rabbitmq-0 1/1 Running 4 (22m ago) 55m pod/zipkin-0 1/1 Running 2 (22m ago) 55m

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service/customer LoadBalancer 10.104.88.212 127.0.0.1 80:31989/TCP 45m service/fraud NodePort 10.102.20.243 80:30348/TCP 43m service/kubernetes ClusterIP 10.96.0.1 443/TCP 56m service/notification NodePort 10.101.126.40 80:31045/TCP 44m service/rabbitmq NodePort 10.97.190.10 15672:31672/TCP,5672:30672/TCP 55m service/zipkin LoadBalancer 10.107.29.196 127.0.0.1 9411:31734/TCP 55m

NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps/customer 1/1 1 1 45m deployment.apps/fraud 1/1 1 1 43m deployment.apps/notification 1/1 1 1 44m

NAME DESIRED CURRENT READY AGE replicaset.apps/customer-5b8d7cd7dd 1 1 1 45m replicaset.apps/fraud-bc6fb777c 1 1 1 43m replicaset.apps/notification-79997f988c 1 1 1 44m

NAME READY AGE statefulset.apps/postgres 1/1 55m statefulset.apps/rabbitmq 1/1 55m statefulset.apps/zipkin 1/1 55m

[fallousamb]

Hello I'm facing the same problem while registring a customer Did you resolve your problem ? Thanks !

[DmitriKonnovNN]

Hi! I hope you guys managed to resolve this issue. To everyone who's currently struggling with this annoying problem,my understanding of the issue. First of all, let's make it clear: This issue turns out its ugly head iff we make use of our micro services running on our localhost. This is okay because we've not dockerized all the services yet and we perhaps don't want to as our microservices aren't fully done yet. Well, our gateway and eureka seem to mix up host configs. Eureka make use of host.docker.internal that's configured by docker and is 172.20.10.5 (on Windows 10); Spring Cloud Gateway per default uses ribbon as load-balancer implementation, which seems to erroneously forward our request to 172.20.10.5 (host.docker.internal) as well. And that's the issue. Our services (as long as we started them on localhost without dockerizing) ain't there up. They're up and running on 127.0.0.1.

Below you can find some solutions: https://localcoder.org/spring-boot-cloud-eurka-windows-10-eurkea-returns-host-docker-internal-for-clien https://dimitr.im/fix-eureka-localhost