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

23rd
Aug 2017
Acris Liu
@Acris
Aug 23 2017 08:30
Hello, is Spring Cloud Zuul will replaced by Spring Cloud Gateway?
nmquyet
@nmquyet
Aug 23 2017 08:38
I think they are 2 different projects
Acris Liu
@Acris
Aug 23 2017 08:41
blob
In this post, it said Spring Cloud Gateway is viewed as a replacement for Zuul.
nmquyet
@nmquyet
Aug 23 2017 08:43
yeah, you can use it as a zuul 1 alternative
2 projects for the same purpose
Acris Liu
@Acris
Aug 23 2017 08:45
Thank you, maybe we should wait until Spring Cloud Finchley released to find the anwser.
Tommy Ludwig
@shakuzen
Aug 23 2017 08:52
It’s not very clear what Netflix’s plans are on open sourcing Zuul 2. There isn’t a publicly released version of Zuul 2 (AFAIK), and looking at GitHub it looks like they’re already working on a (also unreleased) version 3
nmquyet
@nmquyet
Aug 23 2017 08:53
I think that is the reason Spring Cloud Gateway is borned :D
James Howe
@OrangeDog
Aug 23 2017 13:19
I'm looking at @RefreshScope - is there something extra you have to do to make it reload yaml properties?
I've got a @Bean @RefreshScope @ConfigurationProperties, but when it's constructed after the refresh, the properties haven't changed
Might be spring-cloud/spring-cloud-config#183
James Howe
@OrangeDog
Aug 23 2017 13:27
No, it's not just a list property, it's all of them
Oh, it might be because i'm not changing the right file...
James Howe
@OrangeDog
Aug 23 2017 13:48
No, I'm pretty sure it's the correct yaml file - the one it loaded at startup
James Howe
@OrangeDog
Aug 23 2017 14:05
Does it matter than I'm calling refreshAll() directly via JMX?
Checking the /env actuator, it doesn't see the updated properties either
James Howe
@OrangeDog
Aug 23 2017 14:10
Is it because I'm on Windows? See @dsyer 's comment.
https://stackoverflow.com/q/26985843/476716
James Howe
@OrangeDog
Aug 23 2017 15:07

Does it matter than I'm calling refreshAll() directly via JMX?

Yes I think so. The /refresh actuator does some environment stuff first.
However, that appears to hang inside addConfigFilesToEnvironment()

James Howe
@OrangeDog
Aug 23 2017 15:12
Some sort of infinite loop or incredible slowness inside loadFailureAnalyzers
James Howe
@OrangeDog
Aug 23 2017 15:21
OK, that appears to have been incredible slowness. It did then get around to calling refreshAll(), which is now deadlocked in StandardBeanLifecycleDecorator
public Context<ReadWriteLock> decorateDestructionCallback(final Runnable callback) {
if (callback == null) {
  return null;
}
final ReentrantReadWriteLock readWriteLock = new ReentrantReadWriteLock();
return new Context<ReadWriteLock>(new Runnable() {
  public void run() {
    Lock lock = readWriteLock.writeLock();
    lock.lock();  // <------- HERE
    try {
      callback.run();
    } finally {
      lock.unlock();
    }
  }
}, readWriteLock);
}
James Howe
@OrangeDog
Aug 23 2017 16:07
I tried on Linux instead and there were no problems.
James Howe
@OrangeDog
Aug 23 2017 16:56
Running the application builder again seems like a terrible way to do this. Surely it can be done just by iterating through ConfigurableEnvironment.getPropertySources()and not having to construct and process the entire context configuration
James Howe
@OrangeDog
Aug 23 2017 17:07
Hmm, would have to rely on the source naming scheme as they're just MapPropertySource by that point