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

14th
Oct 2015
hacbq
@hacbq
Oct 14 2015 02:05
@pmvilaca I'm also set path: /product** but Zuul can't forword localhost:/8765/products/{id} :worried:
Joao Duraes
@joaoduraes
Oct 14 2015 15:51
@hacbq maybe you need to set both routes.
one to /products** and one to /products/**
but I’m not sure if the /products/{id} will match the /products/** one or the /products**
Joao Duraes
@joaoduraes
Oct 14 2015 15:59
you should probably define a /product/**and a /products**, that should do the trick :)
turick
@turick
Oct 14 2015 17:15
when using spring cloud config, should the data in the config files in git only contain custom properties, or can they contain spring properties? my service is properly pulling the config from the server, and i have parameters such as my spring.redis.host and spring.zipkin.host etc, but i get connection errors and the service fails to start. if i move those properties back into my local application.yml inside my service, it works fine
Dave Syer
@dsyer
Oct 14 2015 17:16
You must be doing something wrong
Redis is needed before the config is available ?
A simple sample would help a lot
turick
@turick
Oct 14 2015 17:20
i'm using redis for spring session, so it attempts to connect when the service is starting up. however one of the very first lines in the log is that is properly located the property source in my git repo that has all of the host/port properties for redis... the exception doesn't come until much later in the startup sequence. so that seems odd to me, because it should already have loaded the properties
the errors produced by my service are simple connection refused errors for zipkin
but again, when i move those properties back locally, it connects fine
would you need a sample of just my service that's producing the errors?
Dave Syer
@dsyer
Oct 14 2015 17:30
Probably that would help
Nothing sounds weird on the face of it
Maybe the local config settings don't actually work either and you app is just using defaults.
I don't know
Dave Syer
@dsyer
Oct 14 2015 17:43
If you get rid of Spring Session does that help?
Can you paste the logs up to the first exception?
turick
@turick
Oct 14 2015 17:46
i'll check... just a sidenote as well, the aop.proxy-traget-class=true works when i have the config local. when i move that to the cloud config server, i start getting the proxy errors again. to get past that, i had to annotate my Application class with @EnableAspectJAutoProxy(proxyTargetClass = true). so it's as if, even though it's properly pulling the config file, it still isn't really loading those values for spring into the environment
Dave Syer
@dsyer
Oct 14 2015 17:47
That's suspicious too probably
turick
@turick
Oct 14 2015 17:47
it's going to take me just a minute as the entries have rolled past my terminal window buffer
here's one other interesting bit of info. the remote configs do contain properties that are used inside my code, to obtain the endpoint for the service i'm searching against, max number of records, etc. those all work properly when they're loaded from the cloud config service and not included in the local config.
Dave Syer
@dsyer
Oct 14 2015 17:52
There's an early instantiation cascade I bet
Spring Session or Spring Security or some AOP config
turick
@turick
Oct 14 2015 17:54
i added "log.txt" to the root of the project
turick
@turick
Oct 14 2015 18:01
i removed spring session, but still getting the connection refused for zipkin.
turick
@turick
Oct 14 2015 18:08
i removed sleuth and it seems to boot up now
added spring session back in and it has started up again -- so it looks like we're getting this narrowed down to something with sleuth
Dave Syer
@dsyer
Oct 14 2015 18:11
There is some AOP in sleuth
turick
@turick
Oct 14 2015 18:19
dave i'm incredibly sorry... i just totally wasted your time
i had to change some config on my gitlab server and somehow lost access to push from my local machine, so it never pushed my updates containing the zipkin host/port
i got that squared away and was able to push the right config and it looks like it is all working
Dave Syer
@dsyer
Oct 14 2015 18:31
Good
turick
@turick
Oct 14 2015 18:43
hmm i may have spoke to soon. i saw this problem a couple of weeks ago and gave up on using spring cloud config because of it. i've just been able to revisit today. it's only when i'm using spring cloud, but eureka always shows the service as down even the the /health URL for the service itself reports up
Spencer Gibb
@spencergibb
Oct 14 2015 18:48
eureka reports services as down when it doesn’t receive a heartbeat from the client.
turick
@turick
Oct 14 2015 18:50
this issue only pops up when include spring.cloud.config.discovery.enabled=true in my service config. as soon as i disable config/discovery and just use a local configuration, the discovery problem goes away
could there be anything inherent to cloud config that could possible interfere with the discovery/heartbeat process?
turick
@turick
Oct 14 2015 18:59
almost seems like it might have something to do with the environment? i am actually not seeing the issue when I deploy from my local dev box, only on a VM that resides on our dev network with the rest of the spring cloud services
this seems to be the interesting part of the logs:
2015-10-14 14:58:00.395 INFO 7905 --- [ main] c.n.e.EurekaDiscoveryClientConfiguration : Unregistering application nclSearchService with eureka with status DOWN
2015-10-14 14:58:00.395 INFO 7905 --- [ main] com.netflix.discovery.DiscoveryClient : Saw local status change event StatusChangeEvent [current=DOWN, previous=UP]
2015-10-14 14:58:00.447 INFO 7905 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_NCLSEARCHSERVICE/172.18.100.145: registering service...
2015-10-14 14:58:00.454 INFO 7905 --- [nfoReplicator-0] com.netflix.discovery.DiscoveryClient : DiscoveryClient_NCLSEARCHSERVICE/172.18.100.145 - registration status: 204
2015-10-14 14:58:00.487 INFO 7905 --- [ main] com.netflix.discovery.DiscoveryClient : DiscoveryClient_NCLSEARCHSERVICE/172.18.100.145 - deregister status: 200
2015-10-14 14:58:00.488 INFO 7905 --- [ main] c.n.e.EurekaDiscoveryClientConfiguration : Registering application nclSearchService with eureka with status UP
2015-10-14 14:58:01.348 INFO 7905 --- [ main] o.s.j.e.a.AnnotationMBeanExporter : Registering beans for JMX exposure on startup
it goes from unregistering to registering, to deregistering, to registering the service with status up... however Eureka shows it down for some period of time before dropping off the list altogether
turick
@turick
Oct 14 2015 19:27
also, here are the logs i'm seeing on eureka
2015-10-14 15:26:22.394 INFO 24862 --- [nio-8761-exec-7] c.n.eureka.AbstractInstanceRegistry : Registered instance NCLSEARCHSERVICE/172.18.100.145 with status DOWN (replication=false)
2015-10-14 15:26:22.437 INFO 24862 --- [nio-8761-exec-2] c.n.eureka.AbstractInstanceRegistry : Registered instance NCLSEARCHSERVICE/172.18.100.145 with status DOWN (replication=true)
2015-10-14 15:26:22.438 INFO 24862 --- [nio-8761-exec-5] c.n.eureka.AbstractInstanceRegistry : Cancelled instance NCLSEARCHSERVICE/172.18.100.145 (replication=false)
2015-10-14 15:26:22.438 INFO 24862 --- [nio-8761-exec-5] c.n.eureka.resources.InstanceResource : Found (Cancel): NCLSEARCHSERVICE - 172.18.100.145
2015-10-14 15:26:22.936 WARN 24862 --- [nio-8761-exec-8] c.n.eureka.AbstractInstanceRegistry : DS: Registry: cancel failed because Lease is not registered for: NCLSEARCHSERVICE:172.18.100.145
2015-10-14 15:26:22.936 INFO 24862 --- [nio-8761-exec-8] c.n.eureka.resources.InstanceResource : Not Found (Cancel): NCLSEARCHSERVICE - 172.18.100.145
2015-10-14 15:26:22.940 WARN 24862 --- [-Cancel-process] c.n.eureka.cluster.ReplicationTask : The replication of task NCLSEARCHSERVICE/172.18.100.145:Cancel@PeerEurekaNode: http://172.18.100.120:8761/eureka/apps/: failed with response code 404
2015-10-14 15:26:22.941 WARN 24862 --- [-Cancel-process] c.netflix.eureka.cluster.PeerEurekaNode : NCLSEARCHSERVICE/172.18.100.145:Cancel@PeerEurekaNode: http://172.18.100.120:8761/eureka/apps/: : missing entry.
turick
@turick
Oct 14 2015 20:21
i just re-verified. i moved the required properties back in to my local application.yml file and fire up the jar file with "java -jar NclSearchService.jar --spring.cloud.config.discovery.enabled=false" and there are no issues with the registration/heartbeat.
both machines are running java build 1.8.0_60-b27... i can't imagine what else would cause this behavior only on one machine
Spencer Gibb
@spencergibb
Oct 14 2015 20:24
ok, I’ll look at it
Dave Syer
@dsyer
Oct 14 2015 20:26
Make sure you get a snapshot of spring cloud netflix
We tweaked that discovery first scenario since M1
Spencer Gibb
@spencergibb
Oct 14 2015 20:26
he’s using M1
Dave Syer
@dsyer
Oct 14 2015 20:26
(Or don't use discovery first)
Spencer Gibb
@spencergibb
Oct 14 2015 20:26
@turick try with 1.1.0.BUILD-SNAPSHOT
Dave Syer
@dsyer
Oct 14 2015 20:28
Brixton snapshot for the parent even better
In case there were companion changes in commons
Spencer Gibb
@spencergibb
Oct 14 2015 20:37
yeah, he isn’t using the Brixton pom which may also be part of the problem
turick
@turick
Oct 14 2015 20:38
i just took netflix and sleuth out of dependency management and added the starter-parent into dependency management and i'm rebuilding my service. should i do the same for my eureka service (well, and all my other services? sidecar, etc?)
Spencer Gibb
@spencergibb
Oct 14 2015 20:39
yes
turick
@turick
Oct 14 2015 20:42
ok will do. may take me a bit, but i'll report back when i get it all done. thanks so much for all of your help. our first official implementation of all of this stuff starts on our next sprint this monday :) i have about 6 microservices targeted and having all of these core capabilities baselined will be a huge help. can't say enough how much i appreciate you guys
turick
@turick
Oct 14 2015 20:52
it works! i only updated my service, but it fixed the problem! thank you!!!!
Spencer Gibb
@spencergibb
Oct 14 2015 20:54
NP