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

18th
Feb 2015
Dave Syer
@dsyer
Feb 18 2015 08:15
Yeah that's probably right. The discovery client is not available until it has been properly initialized, so it's guarded that way.
Ken
@schultzy51
Feb 18 2015 15:51
After sleeping on it I realized that you only need to update the uri via discovery when polling. When you utilize push via spring cloud bus for config you don’t need to update the uri as it’s no longer used after initialization.
Ken
@schultzy51
Feb 18 2015 16:48
Although the health indicator would fail in this case.
Dave Syer
@dsyer
Feb 18 2015 17:34
The health indicator for the config server? I'm not really clear on your use case.
Ken
@schultzy51
Feb 18 2015 17:35
if the initial config server went away and another one tooks it’s place wouldn’t the health check continue to fail for the config server since the url isn’t updated after initialization?
Assuming the config server doesn’t give the clients the updated url via a push.
Dave Syer
@dsyer
Feb 18 2015 17:40
I think that might be a bit complicated for most scenarios. If you need multiple config servers for availability, wouldn't it make more sense to load balance them on the server side (so they all have to same URL)?
Ken
@schultzy51
Feb 18 2015 17:42
Then why use eureka at all and discover it? I thought the whole point of finding the config server with discovery is that it’s treated like any other eureka registered machine. It could go away at any moment and another takes it’s place.
Eureka with Ribbon is the load balancing in cases like this. Although in this particular case Ribbon isn’t being used currently
Dave Syer
@dsyer
Feb 18 2015 17:55
Again, I don't see the benefit for the config server. You can still discover the URL from eureka if that's the way your mind works, but load balancing on the client doesn't make much sense (you only need once it at startup, or maybe occasionally thereafter).
Ken
@schultzy51
Feb 18 2015 18:02
I’m trying to not treat it as a special case. I’m not worried about load balancing in this case since the number of instances are a known quantity. But if you check the health of the application at regular intervals and the url for the config server changed (assuming no load balancer) then the application health would begin to fail as well. I haven’t seen the case where you register a load balancer with eureka. That seems like a very special case.
Dave Syer
@dsyer
Feb 18 2015 18:09
It's pretty normal in a PaaS.
Ken
@schultzy51
Feb 18 2015 18:17
Interesting. I’ve always thought each instance registered with eureka as being replaceable and the details changing with only the application type remaining the same, but I guess that could work too. It might be worth something to note in the documentation then since I thought the default NetflixOSS philosophy assumes you can replace an instance whenever you want which is why you need to continually look up an instance with eureka and never assume it will always be there.
Dave Syer
@dsyer
Feb 18 2015 18:35
Well it is, but the config server is a bit special - nothing works without it, but nothing needs it once it has bootstrapped. And discovery mode isn't the default for config clients, so we kind of loosely recommend making config server the anchor (as opposed to eureka, which is what Netflix do). You do have the choice though.
Ken
@schultzy51
Feb 18 2015 18:36
Wouldn’t you use it for dynamic configuration after things are running?
Dave Syer
@dsyer
Feb 18 2015 18:38
I guess so, but I expect updates to be infrequent. And in 1.0 the client has to ask for the change.
Not all config changes can be applied without a restart anyway
Ken
@schultzy51
Feb 18 2015 18:45
I’m thinking about cases like archaius configurations, which are meant to be dynamic.
I believe there is a bridge from the Spring Environment to Archaius
Dave Syer
@dsyer
Feb 18 2015 18:53
Yes. But changing config (even in Archaius) doesn't automatically mean changing behaviour
You still have to react to the change
Archaius is really not a great fit for Spring applications. And it's really butt ugly.
So the bridge (so far at least) goes the other way
Ken
@schultzy51
Feb 18 2015 18:58
haha