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

30th
Mar 2017
Thomas B.
@tblazz
Mar 30 2017 08:22
Hello, Do you know if there is the possibility with Zuul to map the following path : /test with "/test" with serviceId parameter. In fact my zuul proxy (configured with serviceId) forwards only to "/" of the service
Dave Syer
@dsyer
Mar 30 2017 08:23
What do you mean by "with serviceId parameter"?
The prefix is stripped by default, but there's a flag to put it back if you prefer that (it's in the user guide)
Roi Ezra
@ezraroi
Mar 30 2017 08:59
Hi, i have got question about the retry mechanism when using Spring-Retry with spring cloud.. Looks like only exceptions will be retried.. HttpStatusException will not be retried as they are not thrown as exceptions from the http client... is this right? only IOException or similar will be retried?
Dave Syer
@dsyer
Mar 30 2017 08:59
Do you have a link to some specific code in spring cloud?
Or is this a question about spring-retry?
Roi Ezra
@ezraroi
Mar 30 2017 08:59
cloud
one sec
it is in Feign code in spring cloud
Dave Syer
@dsyer
Mar 30 2017 09:00
You probably need to wait and ask @ryanjbaxter then
He's in the US
Roi Ezra
@ezraroi
Mar 30 2017 09:00
sure.. thanks...
Dave Syer
@dsyer
Mar 30 2017 09:00
There was some discussion the other day about which exceptions needed to be retried.
HttpStatusException is excluded currently on purpose IIRC
(if there's a 404 it's unlikely to be retryable)
Roi Ezra
@ezraroi
Mar 30 2017 09:01
yes i read his blog... oh.. cool.. i was fighting with it.. so you say it is by design?
i was sure that 5xx status code will be retried.. but looks like only exception that are not realated to any status code
The class is RetryableFeignLoadBalancer line 91
Dave Syer
@dsyer
Mar 30 2017 09:10
I'm not sure I understand all of that code yet. Let's wait for Ryan.
Roi Ezra
@ezraroi
Mar 30 2017 09:10
sure... thanks
Dave Syer
@dsyer
Mar 30 2017 09:10
40x responses are not supposed to be retryable though, are they?
It's a client error
Roi Ezra
@ezraroi
Mar 30 2017 09:10
yes
i totally agree
i would expect it to retry 5xx and IOExceptions such as the service went down during processing of a request
but looks like it is not working in this way currently
Dave Syer
@dsyer
Mar 30 2017 09:12
OK. We need to fix it then.
Roi Ezra
@ezraroi
Mar 30 2017 09:13
will check with @ryanjbaxter
thanks
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 12:48
Hi, quick question about the configserver. I've got this two config files in my github repository: /application-uat.yml and /myservice/uat/myservice.yml
They both get picked by the service but application-uat (shared across all services) has higher priority than the service specific file. I would've expected it to have lower priority and properties be overwritten by myservice.yml.
Am I missing anything here?
Dave Syer
@dsyer
Mar 30 2017 12:52
Could be a bug
Can you find a test case asserting the opposite?
Doesn't it depend on the search path that you configure in the server
(i.e. you control it)
I don't think /myservice/uat/myservice.yml is a default location
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 12:56
  profiles: uat
  cloud:
    config:
      server:
        git:
          uri: https://github.com/myorganisation/properties-config
          searchPaths: '{application}/{profile}'
    bus:
      enabled: false
this is how I have it configured
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:07
blob
doesn't the first line mean the same than my searchPath?
Dave Syer
@dsyer
Mar 30 2017 13:08
That's nothing to do with the search path is it?
It's a snippet from the user guide about the resource controller
Maybe I misunderstood the question
What is it that you see that isn't working as expected?
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:10
The expected behaviour would be the properties inmyservice/uat/myservice.yml overwritting the ones in application-uat.yml
whereas the reality is the oposite
Dave Syer
@dsyer
Mar 30 2017 13:11
How do you observe the properties being overridden?
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:12
the property I have is the server where it connects to and I can see it connecting to the wrong one. I have a default server defined in application-uat.yml for all my services but this service in particular has to use a different one, overwriting the value
Dave Syer
@dsyer
Mar 30 2017 13:17
Seems like it's adding the default locations in the wrong order then
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:18
Would it be a bug then? Or is it something I could fix by myself?
Dave Syer
@dsyer
Mar 30 2017 13:18
Or maybe not. It could be more subtle than that
given that no-one else seems to have noticed
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:21
I don't really know the internals of this but, when I hit /env I always see application-uat.yml coming in first place and then the myservice/uat/myservice.yml right after. Does that order dictate the priorities?
And also, it's using configserver running on Brixton.M5, don't know if that could be a bug in previous versions...
Dave Syer
@dsyer
Mar 30 2017 13:24
You should definitely upgrade before reporting it as a bug
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:24
I'm checking right now with Camden.RELEASE
see if that changes anything
Dave Syer
@dsyer
Mar 30 2017 13:25
And yes, the order is the order in the Spring Environment property sources, so that is significant.
Camden is up to SR6 now
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:25
cool, so I can confirm I've got 16 more services with the same issue hehe
Dave Syer
@dsyer
Mar 30 2017 13:25
Brixton.M5 isn't even a GA release.
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:26
sure, testing with Camden.SR6
Dave Syer
@dsyer
Mar 30 2017 13:26
(Which isn't to say that the issue is fixed. Just that you need to upgrade.)
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:28
I just tried with the latest version and application-uat.yml still comes first :(
Dave Syer
@dsyer
Mar 30 2017 13:29
The code hasn't changed since Brixton
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:29
makes sense then
Dave Syer
@dsyer
Mar 30 2017 13:30
You can work around it by putting your application.yml in a subdirectory, instead of at the root
The root will always come first.
But you can add a subdirectory in any order you want
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:31
what would be the name of that subdirectory? application?
Dave Syer
@dsyer
Mar 30 2017 13:31
I'm really not 100% sure if the default behaviour is a bug, or just something you have to be more aware of (i.e. a documentation issue)
The name of the subdirectory is up to you
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:31
it could be
Josh Fix
@joshfix
Mar 30 2017 13:31
i'm on camden sr6. not using any sub directories (all files are in the same dir), but i can confirm that my properties are always applied application.yml -> application-profile.yml -> service.yml -> service-profile.yml
Dave Syer
@dsyer
Mar 30 2017 13:31
Call it "elephant" if you want
Paul Balogh
@javaducky
Mar 30 2017 13:32
ditto
Dave Syer
@dsyer
Mar 30 2017 13:32
@joshfix that's expected
Josh Fix
@joshfix
Mar 30 2017 13:32
i know, i'm just confirming that i'm getting the expected behavior
Dave Syer
@dsyer
Mar 30 2017 13:32
It's the same as a spring boot app running with that search path
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:32
@joshfix is the first one the top priority or the least?
Josh Fix
@joshfix
Mar 30 2017 13:32
least
Dave Syer
@dsyer
Mar 30 2017 13:33
but that's the opposite order to the search path
Just for the sake of clarity
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:33
could it be because /{application}/{profile} is a searchPath, not a default path? (in my example)
do default paths have higher priorities than SearchPaths?
Dave Syer
@dsyer
Mar 30 2017 13:35
Yes.
That's the way it is implemented
Could be a mistake
Hard to say
But no-one else noticed
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:37
the way I understood it was that search paths were added to the list of paths along with the default ones following the same naming conventions and with same priorities, but having clarified that I guess I can workaround it
Dave Syer
@dsyer
Mar 30 2017 13:46
If you open an issue we can see if anyone chimes in with an opinion
Someone might be relying on the existing behaviour. Can't think why.
But we'd better have a discussion about it before changing the default.
Amin Abu-Taleb
@aabutaleb
Mar 30 2017 13:48
totally agree, thanks
Josh Fix
@joshfix
Mar 30 2017 14:03
i was curious what the smartest way was to disable spring cloud config for tests. i'm currently using spring.cloud.config.enabled=false, but i'm assuming spring is still building all of the config client classes from autoconfig. i've tried using spring.autoconfigure.exclude on ConfigClientAutoConfiguration, but it seems the service still tries to reach out to the config service.
not hugely important, just curious if there was a more prefered method
Dave Syer
@dsyer
Mar 30 2017 14:04
spring.cloud.config.enabled=false is probably best
People have suffered a lot from accidentally having a config server running and getting test results that are inconsistent across environments.
We don't have a "standard" good way to deal with that, other than the flag, which you have to remember to set.
Josh Fix
@joshfix
Mar 30 2017 14:07
ya, our team usually misses it when working locally because the default config points to localhost and everybody keeps a local config server running. we only seem to catch it when we push to github and jenkins builds and runs the tests.
i'll just keep disabling it then -- thank you dave
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:34
@ezraroi I would expect IOExceptions to be retriend you say they are not?
Roi Ezra
@ezraroi
Mar 30 2017 14:41
@ryanjbaxter ok... if this is the case... i think that it will be much more powerful to retry 5xx status also.. in my case for example ... one of my services is failing because of hystrix timeout and if i could retry on another instance would be great
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:42
still not clear on the issue
Roi Ezra
@ezraroi
Mar 30 2017 14:42
if it is supposed to retry only on IOExcpetions.. no issue
it was not clear from the docs and from your blog post..
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:43
right now I believe any Exception thrown when making the request will cause a retry
Roi Ezra
@ezraroi
Mar 30 2017 14:44
yes.. looks like it.. but it will be better if we could also retry on server errors. Currently the client that feign is using is not throwing exceptions when it is getting response from the called service
i am trying to see if i can make it throw exceptions on 5xx somehow
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:45
what is the response code you are getting back where an exception is not being thrown?
Roi Ezra
@ezraroi
Mar 30 2017 14:46
500
the called service has uncaught exception in the code that it is running which results in 500 status code
RetryableRibbonLoadBalancingHttpClient
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:49
and that 500 response does not cause an exception to be thrown by Feign?
Roi Ezra
@ezraroi
Mar 30 2017 14:49
line 94... it is just getting the 500 response and an exception is not thrown.. so this is why it is not being retried
mmmm
it is thrown by feign.. be the feign error decoder is called after in that sequence
when feign error decoder is called, we are no longer in the RetryTemplate as i understand it
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:51
ok
would it be possible to maybe put together a quick sample that demonstrates it? that way I can add it to my unit tests, you can put a comment in spring-cloud/spring-cloud-netflix#1540 with your use case and sample
Roi Ezra
@ezraroi
Mar 30 2017 14:52
if i understand it right.. i will have to write my own AbstractLoadBalancingClient that uses Spring retry and checks the status code of the response and throw exception on 5xx codes
Ryan Baxter
@ryanjbaxter
Mar 30 2017 14:54
yes I think so….
Roi Ezra
@ezraroi
Mar 30 2017 14:55
cool...i will add use case and sample in the comment.