I have configured my zuul proxy to work with multiple instance of my microservice . The only thing that i have done is adding ribbon.listOfServers keyword to my configuration.
It is working fine with round robin policy.
But when i shutdown one of the microservice instances ribbon still sends requests to that one and returning error to the clients.
How can i enable healthCheck feature inside the ZuulProxy ?
My zuul configuration is shown below:
shared.microservice.customer.service1.url=ip1:port1/shared/microservice/customer/
shared.microservice.customer.service2.url=ip2:port2/shared/microservice/customer/
ribbon.eureka.enabled = false
zuul.routes.customer-micro-service.path: /shared/microservice/customer/**
zuul.routes.customer-micro-service.serviceId: customers
customers.ribbon.listOfServers = ip1:port1/shared/microservice/customer/,ip2:port2/shared/microservice/customer/
My Main Spring class has the following annotations:
#EnableZuulProxy
#SpringBootApplication
#ComponentScan(basePackages = { "com.my.gateway"})
public class ZuulProxyApplication
And i am getting the below exception :
com.netflix.zuul.exception.ZuulException: Forwarding error
at org.springframework.cloud.netflix.zuul.filters.route.RibbonRoutingFilter.forward(RibbonRoutingFilter.java:143) ~[spring-cloud-netflix-core-1.0.1.RELEASE.jar!/:1.0.1.RELEASE]
at org.springframework.cloud.netflix.zuul.filters.route.RibbonRoutingFilter.run(RibbonRoutingFilter.java:107) ~[spring-cloud-netflix-core-1.0.1.RELEASE.jar!/:1.0.1.RELEASE]
at com.netflix.zuul.ZuulFilter.runFilter(ZuulFilter.java:112) [zuul-core-1.0.28.jar!/:?]
at com.netflix.zuul.FilterProcessor.processZuulFilter(FilterProcessor.java:197) [zuul-core-1.0.28.jar!/:?]
at com.netflix.zuul.FilterProcessor.runFilters(FilterProcessor.java:161) [zuul-core-1.0.28.jar!/:?]
at com.netflix.zuul.FilterProcessor.route(FilterProcessor.java:120) [zuul-core-1.0.28.jar!/:?]
at com.netflix.zuul.ZuulRunner.route(ZuulRunner.java:84) [zuul-core-1.0.28.jar!/:?]
at com.netflix.zuul.http.ZuulServlet.route(ZuulServlet.java:111) [zuul-core-1.0.28.jar!/:?]
at com.netflix.zuul.http.ZuulServlet.service(ZuulServlet.java:77) [zuul-core-1.0.28.jar!/:?]
Caused by: com.netflix.hystrix.exception.HystrixRuntimeException: customersRibbonCommand failed and no fallback available.
at com.netflix.hystrix.AbstractCommand$16.call(AbstractCommand.java:782) ~[hystrix-core-1.4.4.jar!/:1.4.4]
at com.netflix.hystrix.AbstractCommand$16.call(AbstractCommand.java:769) ~[hystrix-core-1.4.4.jar!/:1.4.4]
at rx.internal.operators.OperatorOnErrorResumeNextViaFunction$1.onError(OperatorOnErrorResumeNextViaFunction.java:77) ~[rxjava-1.0.7.jar!/:1.0.7]
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:70) ~[rxjava-1.0.7.jar!/:1.0.7]
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:70) ~[rxjava-1.0.7.jar!/:1.0.7]
at rx.internal.operators.OperatorDoOnEach$1.onError(OperatorDoOnEach.java:70) ~[rxjava-1.0.7.jar!/:1.0.7]
Related
I do not have spring-cloud-starter-loadbalancer on the classpath on purpose since I want to explain Feign functionality to students without the additional load-balancing part.
When annotating with
#FeignClient(name = "product")
I get the following exception:
Caused by: java.lang.IllegalStateException: No Feign Client for loadBalancing defined. Did you forget to include spring-cloud-starter-loadbalancer?
at org.springframework.cloud.openfeign.FeignClientFactoryBean.loadBalance(FeignClientFactoryBean.java:382) ~[spring-cloud-openfeign-core-3.1.3.jar:3.1.3]
Then I tried putting the service-name into the "url" field:
#FeignClient(name = "product", url = "productservice")
But that tries to use "productservice" as some host name:
java.net.UnknownHostException: productservice
at java.base/java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:220) ~[na:na]
I know I can paste the proper URL into that field but what I want is to have that provided by the Eureka discovery.
Thanks for any help.
Versions:
Spring Boot 2.7.1
Spring Cloud 2021.0.3
I am trying to get the cluster information (esp nodes list) with the below Application code.
MBeanServer server = ManagementFactory.getPlatformMBeanServer();
String clusterMembers = (String) (server.getAttribute(new ObjectName("jboss.infinispan:type=CacheManager,name=\"ejb\",component=CacheManager"), "clusterMembers"));
(or)
Object obj = server.getAttribute(ObjectName.getInstance("jgroups:type=channel,cluster=\"web\""), "View");
Both are throwing InstanceNotFoundExceptions.
javax.management.InstanceNotFoundException: jgroups:type=channel,cluster="web"
2021-02-08 15:39:59,046 ERROR [stderr:71] (default task-1) javax.management.InstanceNotFoundException: jgroups:type=channel,cluster="web"
2021-02-08 15:39:59,047 ERROR [stderr:71] (default task-1) at org.jboss.as.jmx.PluggableMBeanServerImpl.findDelegate(PluggableMBeanServerImpl.java:1113)
2021-02-08 15:39:59,047 ERROR [stderr:71] (default task-1) at org.jboss.as.jmx.PluggableMBeanServerImpl.getAttribute(PluggableMBeanServerImpl.java:389)
There are a number of ways to do this. Programmatically, perhaps the simplest way is to use WildFly's clustering API. For details, see: https://github.com/wildfly/wildfly/blob/master/docs/src/main/asciidoc/_high-availability/Clustering_API.adoc#group-membership
Alternatively, you can also use WildFly's CLI to obtain cluster information.
e.g.
[standalone#embedded /] /subsystem=jgroups/channel=ee:read-attribute(name=view)
{
"outcome" => "success",
"result" => "[localhost|0] (1) [localhost]"
}
Alternatively, you can obtain cluster information using Infinispan or JGroups APIs directly.
e.g.
#Resource(lookup = "java:jboss/infinispan/cache-container/web")
private EmbeddedCacheManager manager;
#Resource(lookup = "java:jboss/jgroups/channel/default")
private JChannel channel;
public void foo() {
System.out.println(this.manager.getMembers());
System.out.println(this.channel.getView());
}
Lastly, if you prefer to go the JMX route, ensure that your WildFly configuration defines a JMX subsystem, otherwise no mbeans will be registered.
Infinispan mbeans are registered using the domain: "org.wildfly.clustering.infinispan". Make sure you are using 22.0.1.Final which includes a fix for https://issues.redhat.com/browse/WFLY-14286
Your jgroups jmx code name is almost correct - using the default configuration, each Infinispan cache manager uses a distinct ForkChannel based on a common JChannel, named "ee".
Per my question Apache Geode Web framework I've checked through various spring guides from here and spring data geode samples from here and written a short spring data geode application but it cannot connect to the remote GFSH started Geode locator. The Application class is:
package cm;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.data.gemfire.config.annotation.ClientCacheApplication;
import org.springframework.data.gemfire.config.annotation.ClientCacheApplication.Locator;
import org.springframework.data.gemfire.config.annotation.EnablePdx;
import org.springframework.data.gemfire.repository.config.EnableGemfireRepositories;
#SpringBootApplication
#ClientCacheApplication(name = "CmWeb", locators = #Locator, subscriptionEnabled = true)
#EnableGemfireRepositories(basePackageClasses= {CmRequest.class})
#EnablePdx
public class CmWeb {
public static void main(String[] args) {
SpringApplication.run(CmWeb.class, args);
}
}
and in the resources directory application.properties I've set up the remote locator:
# Configure the client's connection Pool to the servers in the cluster
spring.data.gemfire.pool.locators=1.2.3.4[10334]
Build and run the application and it discovers the locator (which it returns as the server name)
[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : AutoConnectionSource discovered new locators [UAT:10334]
A couple of seconds later it throws the error:
[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : locator UAT:10334 is not running.
and
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.waitForConnect(Native Method) ~[na:1.8.0_232]
at java.net.DualStackPlainSocketImpl.socketConnect(DualStackPlainSocketImpl.java:85) ~[na:1.8.0_232]
at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350) ~[na:1.8.0_232]
at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:204) ~[na:1.8.0_232]
at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188) ~[na:1.8.0_232]
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:172) ~[na:1.8.0_232]
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392) ~[na:1.8.0_232]
at java.net.Socket.connect(Socket.java:607) ~[na:1.8.0_232]
at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:958) ~[geode-core-1.9.2.jar:na]
at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:899) ~[geode-core-1.9.2.jar:na]
at org.apache.geode.internal.net.SocketCreator.connect(SocketCreator.java:888) ~[geode-core-1.9.2.jar:na]
at org.apache.geode.distributed.internal.tcpserver.TcpClient.getServerVersion(TcpClient.java:290) ~[geode-core-1.9.2.jar:na]
at org.apache.geode.distributed.internal.tcpserver.TcpClient.requestToServer(TcpClient.java:184) ~[geode-core-1.9.2.jar:na]
at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocatorUsingConnection(AutoConnectionSourceImpl.java:209) [geode-core-1.9.2.jar:na]
at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryOneLocator(AutoConnectionSourceImpl.java:199) [geode-core-1.9.2.jar:na]
at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl.queryLocators(AutoConnectionSourceImpl.java:287) [geode-core-1.9.2.jar:na]
at org.apache.geode.cache.client.internal.AutoConnectionSourceImpl$UpdateLocatorListTask.run2(AutoConnectionSourceImpl.java:500) [geode-core-1.9.2.jar:na]
at org.apache.geode.cache.client.internal.PoolImpl$PoolTask.run(PoolImpl.java:1371) [geode-core-1.9.2.jar:na]
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [na:1.8.0_232]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) [na:1.8.0_232]
at org.apache.geode.internal.ScheduledThreadPoolExecutorWithKeepAlive$DelegatingScheduledFuture.run(ScheduledThreadPoolExecutorWithKeepAlive.java:276) [geode-core-1.9.2.jar:na]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) [na:1.8.0_232]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) [na:1.8.0_232]
at java.lang.Thread.run(Thread.java:748) [na:1.8.0_232]
After a lot of investigation I thought it was that the spring data geode client expects a spring boot geode server according to Connecting GemFire using Spring Boot and Spring Data GemFire and so I downloaded the ListRegionsOnServerFunction jar and deployed it on the GFSH server get the same result (have not yet restarted the server...) but that causes the same error condition.
If by Spring-Data-Gemfire - Unable to contact a Locator service. Operation either timed out or Locator does not exist I try and change the application.properties from
spring.data.gemfire.pool.locators=1.2.3.4[10334]
to
spring.gemfire.locators=1.2.3.4[10334]
or other variations then the app can't find the remote locator and throws:
[Timer-DEFAULT-3] o.a.g.c.c.i.AutoConnectionSourceImpl : locator localhost/127.0.0.1:10334 is not running.
Writing this question I've finally found How to connect a remote-locator in Geode and also can't PING the GFSH server from the SPRING app. However, the server bind address is setup properly for remote locator clients and various other services and UI using a locally built Geode Native Client for Geode v 1.10 can connect. I suspect PING may be disabled across this (semi-internal) network by default. I also disabled the firewall rules for ports 10334, 1099, 40404 to allow all traffic but still get the same error condition.
It turns out that from repeated INFO messages in the Spring Boot app after the connection refused:
[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : updateLocatorInLocatorList changing locator list: loc form: LocatorAddress [socketInetAddress=UAT:10334, hostname=UAT, isIpString=false] ,loc to: UAT:10334
[Timer-DEFAULT-2] o.a.g.c.c.i.AutoConnectionSourceImpl : updateLocatorInLocatorList locator list from:[UAT:10334, /1.2.3.4:10334] to: [LocatorAddress [socketInetAddress=UAT:10334, hostname=UAT, isIpString=false], LocatorAddress [socketInetAddress=/1.2.3.4:10334, hostname=1.2.3.4, isIpString=true]]
and then running list clients on the server, the connection from the Spring Boot app to the Geode server v 1.10 is in fact established. Arrrgh!
It means the locator logic is working but this doesn't explain why after the first connection there's a java.net.ConnectException: Connection refused: connect error. Any ideas?
1 quick note about your Spring Boot application class...
#SpringBootApplication
#ClientCacheApplication(name = "CmWeb", locators = #Locator, subscriptionEnabled = true)
#EnableGemfireRepositories(basePackageClasses= {CmRequest.class})
#EnablePdx
public class CmWeb {
public static void main(String[] args) {
SpringApplication.run(CmWeb.class, args);
}
}
The following statements are true iff you are using Spring Boot for Apache Geode (or Pivotal GemFire), which is highly recommended.
When using SBDG (by declaring the correct org.springframework.geode:spring-geode-starter dependency on your application classpath), then you do not need to explicitly declare the #ClientCacheApplication, #EnableGemfireRepositories or the #EnablePdx annotations since SBDG auto-configures a ClientCache instance by default, auto-configures SD Repositories particularly when all entity classes are in the same package or sub-package as the Spring Boot app and SBDG auto-configures PDX by default, as well.
The locator = #Locator just specifies that the "DEFAULT" GemFire/Geode Pool when configured via the ClientCacheFactory should connect to the cluster via Locators, on localhost using the default Locator port, 10334. Therefore, this attribute is mostly useless and I would recommend the new #EnableClusterAware annotation from SBDG (see here).
The other attributes can be configured via Spring Boot application.properties, like so:
spring.application.name=CmWeb
spring.data.gemfire.pool.subscription-enabled=true
TIP: You can configure subscription on individually "named" Pools, even via properties, if you are using more than 1 Pool (of connections) in your application, perhaps to route different payloads based on workflows to different "grouped" servers in your cluster, etc.
You started to configure the "DEFAULT" Pool in application.properties already with...
# Configure the client's connection Pool to the servers in the cluster
spring.data.gemfire.pool.locators=1.2.3.4[10334]
Regarding...
After a lot of investigation I thought it was that the spring data geode client expects a spring boot geode server
No, SDG does not expect the cluster (of servers) to be configured or bootstrapped with Spring at all. Using Gfsh is perfectly valid. For instance. If the ListRegionsOnServerFunction is not available, SDG falls back to other means (provided by GemFire/Geode itself, which Gfsh knows and uses).
All the messages you are seeing in the Spring Boot app logs are coming from Geode itself, i.e. nothing to do with Spring. In a nutshell, and FWIW, SDG/SBDG is a facade around the Apache Geode (Pivotal GemFire) API and Java client driver. SDG/SBDG is at the mercy of this client doing the right thing, which of course, is partially dependent on proper configuration. Still... I am really just thinking out loud now since I suspect you are already well aware of (or have discovered) all of this.
I would also say the Java client and Native Client are not exactly an apple to apple comparison either. Meaning, if you developed a client using purely the Apache Geode (Pivotal GemFire) API without Spring, you'd have the exact same problem.
I have never seen a case where the first connection is establish but subsequent connections get a "Connection refused", o.O #argh
Have you tried this same configuration/arrangement with older Geode versions, e.g. 1.9?
Sorry for your troubles. I will think on this more.
I am facing issues using Zuul and Ribbon. I am using also Eureka for microservice registry.
I have ribbon-service(port 9000) communicating with the user-service using the REST API
user-service has 2 instances (on port 8081 and 8091)
on ribbon-service I have implemented client-side load balancing using hystrix and feign client
I consume ribbon-service API using Zuul route, and this API then triggers user-service API
When I start my microservice ecosystem and try to consume ribbon-service API(zuulservice:8761/ribbon-service/) I get the following error:
com.netflix.zuul.exception.ZuulException: Forwarding error
at org.springframework.cloud.netflix.zuul.filters.route.RibbonRoutingFilter.handleException(RibbonRoutingFilter.java:189) ~[spring-cloud-netflix-zuul-2.0.0.RELEASE.jar:2.0.0.RELEASE]
at org.springframework.cloud.netflix.zuul.filters.route.RibbonRoutingFilter.forward(RibbonRoutingFilter.java:164) ~[spring-cloud-netflix-zuul-2.0.0.RELEASE.jar:2.0.0.RELEASE]
at org.springframework.cloud.netflix.zuul.filters.route.RibbonRoutingFilter.run(RibbonRoutingFilter.java:112) ~[spring-cloud-netflix-zuul-2.0.0.RELEASE.jar:2.0.0.RELEASE]
at com.netflix.zuul.ZuulFilter.runFilter(ZuulFilter.java:117) ~[zuul-core-1.3.1.jar:1.3.1]
at com.netflix.zuul.FilterProcessor.processZuulFilter(FilterProcessor.java:193) ~[zuul-core-1.3.1.jar:1.3.1]
at com.netflix.zuul.FilterProcessor.runFilters(FilterProcessor.java:157) ~[zuul-core-1.3.1.jar:1.3.1]
at com.netflix.zuul.FilterProcessor.route(FilterProcessor.java:118) ~[zuul-core-1.3.1.jar:1.3.1]
at com.netflix.zuul.ZuulRunner.route(ZuulRunner.java:96) ~[zuul-core-1.3.1.jar:1.3.1]
at com.netflix.zuul.http.ZuulServlet.route(ZuulServlet.java:116) ~[zuul-core-1.3.1.jar:1.3.1]
at com.netflix.zuul.http.ZuulServlet.service(ZuulServlet.java:81) ~[zuul-core-1.3.1.jar:1.3.1]
at org.springframework.web.servlet.mvc.ServletWrappingController.handleRequestInternal(ServletWrappingController.java:165) [spring-webmvc-5.0.5.RELEASE.jar:5.0.5.RELEASE]
at org.springframework.cloud.netflix.zuul.web.ZuulController.handleRequest(ZuulController.java:44) [spring-cloud-netflix-zuul-2.0.0.RELEASE.jar:2.0.0.RELEASE]
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:52) [spring-webmvc-5.0.5.RELEASE.jar:5.0.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:991) [spring-webmvc-5.0.5.RELEASE.jar:5.0.5.RELEASE]
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:925) [spring-webmvc-5.0.5.RELEASE.jar:5.0.5.RELEASE]................
Caused by: com.netflix.client.ClientException: Load balancer does not have available server for client: ribbon-service
at com.netflix.loadbalancer.LoadBalancerContext.getServerFromLoadBalancer(LoadBalancerContext.java:483) ~[ribbon-loadbalancer-2.2.5.jar:2.2.5]
at com.netflix.loadbalancer.reactive.LoadBalancerCommand$1.call(LoadBalancerCommand.java:184) ~[ribbon-loadbalancer-2.2.5.jar:2.2.5]
at com.netflix.loadbalancer.reactive.LoadBalancerCommand$1.call(LoadBalancerCommand.java:180) ~[ribbon-loadbalancer-2.2.5.jar:2.2.5]
at rx.Observable.unsafeSubscribe(Observable.java:10327) ~[rxjava-1.3.8.jar:1.3.8]
at rx.internal.operators.OnSubscribeConcatMap.call(OnSubscribeConcatMap.java:94) ~[rxjava-1.3.8.jar:1.3.8]
at rx.internal.operators.OnSubscribeConcatMap.call(OnSubscribeConcatMap.java:42) ~[rxjava-1.3.8.jar:1.3.8]
at rx.Observable.unsafeSubscribe(Observable.java:10327) ~[rxjava-1.3.8.jar:1.3.8]
This error remains for some time, and after that time I get the following output:
2018-07-16 12:55:43.260 INFO 19233 --- [erListUpdater-0] c.netflix.config.ChainedDynamicProperty : Flipping property: ribbon-service.ribbon.ActiveConnectionsLimit to use NEXT property: niws.loadbalancer.availabilityFilteringRule.activeConnectionsLimit = 2147483647
After that output everthing works great again.
When I hit eurekaservice:8765/eureka/apps I have registered both ribbon-service and all the user-service instances.
This is my zuul service application.properties:
> #Service port
server.port=8765
#Service port
spring.application.name=zuul-service
# Discovery Server Access
eureka.client.service-url.defaultZone:http://localhost:8761/eureka/
eureka.instance.lease-renewal-interval-in-seconds=3
#User service configuration
zuul.routes.user-service.path:/user-service/**
zuul.routes.user-service.serviceId:user-service
#Product service configuration
zuul.routes.product-service.path:/product-service/**
zuul.routes.product-service.serviceId:product-service
#Product service configuration
zuul.routes.shoppingcart-service.path:/shoppingcart-service/**
zuul.routes.shoppingcart-service.serviceId:shoppingcart-service
#Product service configuration
zuul.routes.payment-service.path:/payment-service/**
zuul.routes.payment-service.serviceId:payment-service
#Product service configuration
zuul.routes.ribbon-service.path:/ribbon-service/**
zuul.routes.ribbon-service.serviceId:ribbon-service
This is my zuul-service bootstrap.properties:
> #Application name
spring.application.name=zuul-service
#hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds: 12600
ribbon.ConnectTimeout: 6000
ribbon.ReadTimeout: 60000
robbon.eureka.enabled: true
hystrix.command.default.execution.timeout.enabled=false
I am using spring 2.0.1 and spring cloud Finchley.RELEASE.
Can somebody explain what is going on?
Thank you!
The way DiscoveryClient works is that it fetches new list of changes from Eureka (Service discovery) for every defined time period called hearbeat. Until new changes with respect to registered applications propagates from service discovery to your Zuul instance it is bound to have errors.
The output you see in the logs is just the confirmation that it has received this information.
You may consider add strip path config for your zuul configuration.
add stripPrefix=false in every route config
I have built a spring boot application using spring-cloud and want to use RestTemplate within my client application (which is also a microservice) so that I can continue using mockMvc for integration testing. I am a using the default ribbon/eureka/hystrix client setup with my client microservice and eureka client within the service I'm calling. This is working (once I figured out that serviceIds are what identifies a service endpoint within restTemplate). My problem is that I cant seem to change the restTemplate read nor connection timeout from what seems like a default of 300ms.
Details on the call:
`#Configuration
#EnableAutoConfiguration
#ComponentScan
#EnableConfigurationProperties
#EnableHystrix
#EnableEurekaClient
public class Application { ... public static void main(String[] args) {} ... }
#Component
class EricComponentToDoHystrix { // apparently this has to be a component for hystrix to work btw
#Autowired
RestTemplate restTemplate;
..
#HystrixCommand(fallbackMethod="defaultRestTemplateCall")
public void doRestTemplateCall()
ResponseEntity<String> result = restTemplate.getForEntity("http://someservice/doSomething", String.class); // actually make a call
..
}
}`
with an application.properties containing:
spring:
cloud:
client:
serviceIds:
- someservice
someservice:
ribbon:
#listOfServers: localhost:7080
#NIWSServerListClassName: com.netflix.niws.loadbalancer.DiscoveryEnabledNIWSServerList
# the eureka vipAddress of the target service (Disabled)
DeploymentContextBasedVipAddresses: someservice
# Interval to refresh the server list from the source
ServerListRefreshInterval: 1000
# Connect timeout used by Apache HttpClient.. apparently not by restTemplate
ConnectTimeout: 30000
# Read timeout used by Apache HttpClient.. apparently not by restTemplate
ReadTimeout: 30000
eureka:
client:
#Region where eureka is deployed -For AWS specify one of the AWS regions, for other datacenters specify a arbitrary string
#indicating the region.This is normally specified as a -D option (eg) -Deureka.region=us-east-1
region: default
#For eureka clients running in eureka server, it needs to connect to servers in other zones
preferSameZone: false
us-east-1:
availabilityZones: default
instance:
#Virtual host name by which the clients identifies this service
virtualHostName: ${spring.application.name}
appGroupName: ericGroup
# disable Ribbon's cicruit breaker and rely soley on Hystrix.
# this helps to avoid confusion.
# see https://github.com/Netflix/ribbon/issues/15
niws:
loadbalancer:
availabilityFilteringRule:
filterCircuitTripped: false
Anybody know what properties I need so set to modify restTemplate's default timeouts? Documentation is very light on this subject and it seems the code just recently even allowed restTemplate to be used against ribbon/eureka spring boot defaults. Perhaps this has not been built yet.
The RestTemplate you are injecting is completely vanilla except for a RibbonInterceptor that chooses the physical host in the URI for you (see https://github.com/spring-cloud/spring-cloud-netflix/blob/master/spring-cloud-netflix-core/src/main/java/org/springframework/cloud/netflix/ribbon/RibbonAutoConfiguration.java). The timeouts and other properties are controlled in the RestTemplate through the ClientHttpRequest. You probably should just inject the RibbonInterceptor into your own RestTemplate and set up a ClientHttpRequestFactory to do the timeouts, e.g.
#Component
class EricComponentToDoHystrix {
private RestTemplate restTemplate;
#Autowired
public EricComponentToDoHystrix(RibbonInterceptor interceptor) {
restTemplate = new RestTemplate();
restTemplate.setInterceptors(Arrays.asList(interceptor));
restTemplate.setRequestFactory(...);
}
}
Since I can't comment, I'll answer. The RestTemplate integration only uses the Ribbon LoadBalancer, not RestClient or NFHttpClient.
You no longer need spring.cloud.client.serviceIds, btw. If it is in docs, I'll remove it.