These are chat archives for spring-cloud/spring-cloud

2nd
May 2018
Sushant
@bsushant-athena
May 02 2018 04:18
hi,is gossip protocol being used in eureka?
Knut Schleßelmann
@kschlesselmann
May 02 2018 05:24
@spencergibb I was simply missing a @RefreshScope since I just tried a quick and dirty @Value in my @RestController and flipping feature toggles using the togglz spring boot starter. Neither worked. With @RefreshScope the @Value works like a charm … which leaves me with missing support in togglz :-(
Marcos Barbero
@marcosbarbero
May 02 2018 09:03
@bsushant-athena Eureka doesn't use gossip protocol, but Consul does. You can check the differences here
Dominik Mengelt
@domi55
May 02 2018 11:00

hello. I have a little issue with spring-cloud-config when defining a local git repository. I use cloud.config.server.git.uri: file://${user.home}/projects/config-repo and the config loading works fine but the refresh event is not broadcasted as mentioned in https://cloud.spring.io/spring-cloud-config/multi/multi__push_notifications_and_spring_cloud_bus.html (triggering the /monitor endpoint manually endpoint works as expected)

when taking a quick look at https://github.com/spring-cloud/spring-cloud-config/blob/171d2b261b8fe8ffff4cbd6d364eddbae311e935/spring-cloud-config-monitor/src/main/java/org/springframework/cloud/config/monitor/FileMonitorConfiguration.java#L190 I can see the if (resource instanceof FileSystemResource) check. Unfortunately my file:// url is recognized as FileUrlResource and therefore this check is never true. Would be cool if someone can help me here.

Marcos Barbero
@marcosbarbero
May 02 2018 13:50
@domi55 I do believe you misunderstood things a little bit, this path file://${user.home}/projects/config-repo is just a folder with configuration files in it right? Not really a git repository (hosted by a git server)
is it?
Dominik Mengelt
@domi55
May 02 2018 13:52

no. it is a local git repository ;) as mentioned here https://cloud.spring.io/spring-cloud-config/multi/multi__push_notifications_and_spring_cloud_bus.html

The default configuration also detects filesystem changes in local git repositories. In that case, the webhook is not used. However, as soon as you edit a config file, a refresh is broadcast.

Marcos Barbero
@marcosbarbero
May 02 2018 14:01
you're right.
which version are you using?
Dominik Mengelt
@domi55
May 02 2018 14:02
<spring-cloud.version>Finchley.RC1</spring-cloud.version>
Marcos Barbero
@marcosbarbero
May 02 2018 14:06
it can be a potential bug, as I can see this class FileUrlResource was introduced in spring-core version 5.0.2 and this validation you linked above was older than that.
Dominik Mengelt
@domi55
May 02 2018 14:07
yeah. I was thinking something like that as well.
Marcos Barbero
@marcosbarbero
May 02 2018 14:08
unless someone else knows how to trick it I would just file an issue
Dominik Mengelt
@domi55
May 02 2018 14:11
alright thanks. I will most likely do this
vikrantch-hk
@vikrantch-hk
May 02 2018 14:11
hi team which project I should use spring-cloud-starter-zuul or spring-cloud-starter-netflix-zuul which is latest
Marcos Barbero
@marcosbarbero
May 02 2018 14:14
spring-cloud-starter-netflix-zuul
Joshua Street
@jjstreet
May 02 2018 15:54
netflix ones
@vikrantch-hk they've changed to a new name that includes netflix
so zuul, hystrix, and hystrix-dashboard all have netflix in the name
i've gotta be missing something basic here
im trying to configure timeouts for zuul
following the documentation specifically about ReadTimeout and ConnectTimeout
for testing im just pointing my zuul proxy app to a localhost port that has nothing listening
i've configured a ConnectTimeout to 10000
thinking that i should wait 10s and then retry according to MaxAutoRetries
I get a message back from zuul (according to my fallback provider that just returns a 503) in 6000ms
Joshua Street
@jjstreet
May 02 2018 15:59
using Edgware.SR3 and disabled Hystrix timeouts
to avoid #2570
Joshua Street
@jjstreet
May 02 2018 16:05
my zuul proxy application.yaml:
hystrix:
  command:
    execution.timeout.enabled: false
    ciruitBreaker.forceClosed: true

ribbon:
  eureka.enabled: false
  MaxAutoRetries: 1
  MaxAutoRetriesNextServer: 0
  OkToRetryOnAllOperations: true
  ConnectTimeout: 10000
  ReadTimeout: 10000

zuul:
  retryable: true

  routes:
    someService:
      path: /somewhere
      sensitiveHeaders:
      stripPrefix: false

---
spring.profiles: default
server.port: 8097

someService:
  ribbon:
    listOfServers: http://localhost:8080
setting MaxAutoRetries to 0 makes zuul return a response in ~2100ms
thats suspiciously close to hystrix's default timeout
Joshua Street
@jjstreet
May 02 2018 16:10
ahh probably because i have the timeout property wrong
Joshua Street
@jjstreet
May 02 2018 16:16
updated config:
hystrix.command.default.execution.timeout.enabled: false
hystrix.command.default.circuitBreaker.forceClosed: true

ribbon:
  eureka.enabled: false
  MaxAutoRetries: 0
  MaxAutoRetriesNextServer: 0
  OkToRetryOnAllOperations: true
  ConnectTimeout: 10000
  ReadTimeout: 10000

zuul:
  retryable: true

  routes:
    someService:
      path: /somewhere
      sensitiveHeaders:
      stripPrefix: false

---
spring.profiles: default
server.port: 8097

someService:
  ribbon:
    listOfServers: http://localhost:8080
without hystrix timeouts and no retries, my request should take 10s from what i understand
if trying to connect to a port with no app running on it
making a request with postman returns in ~2000ms
Joshua Street
@jjstreet
May 02 2018 16:24
im gonna go down to Dalston.SR4 and see what happens i guess
same effect
Joshua Street
@jjstreet
May 02 2018 17:01
moved up to Finchley.RC1 to see if that helps
same effect
so with the below properties:
hystix:
  command:
    default:
      execution.timeout.enabled: false
      circuitBreaker.forceClosed: true

ribbon:
  eureka.enabled: false
  MaxAutoRetries: 0
  MaxAutoRetriesNextServer: 0
  OkToRetryOnAllOperations: true
  ConnectTimeout: 10000
  ReadTimeout: 10000

zuul:
  retryable: true

  routes:
    someService:
      path: /somewhere
      sensitiveHeaders:
      stripPrefix: false

---
spring.profiles: default
server.port: 8097

someService:
  ribbon:
    listOfServers: http://localhost:8080
it seems like the ribbon timeout properties are either overwritten or ignored
Joshua Street
@jjstreet
May 02 2018 17:07
setting ReadTimeout and ConnectTimeout to 100ms does shorten my response times to around what I expected
Joshua Street
@jjstreet
May 02 2018 17:34
i think im just confusing the shit out of myself
how can i test connect and read timeout properties are working?
Setting ConnectTimeout to 500 ms makes my requests through Postman complete ~1000ms
with no retries, wouldn't return somewhere closer to 500ms?
Joshua Street
@jjstreet
May 02 2018 18:23
I have WireMock returning a response after 3000ms
and setting ribbon.ReadTimeout to 2500ms works as expected
with no backoff policy, with retries 0 the request completes after ~2500 ms
with 1 retry it completes in ~5000ms
thats with disabling the timeout in hystrix
interestingly, removing the disable timeout config line doesn't change these results
Joshua Street
@jjstreet
May 02 2018 19:44
so instead of pointing to a port on my own machine (windows) i pointed to some other machine (linux) and i get the expected times for timing out
so its something related to windows i suspect
Joshua Street
@jjstreet
May 02 2018 19:59
or rather its something related to this machine's firewall settings