search

spring-cloud / spring-cloud-netflix

Integration with Netflix OSS components
http://cloud.spring.io/spring-cloud-netflix/
Apache License 2.0
4.86k stars 2.44k forks source link

Eureka instance is using non-secure port to construct `secureHealthCheckUrl` #3655

Open LittleBaiBai opened 4 years ago

LittleBaiBai commented 4 years ago

Given eureka instance configuration as follows:

eureka:
  instance: 
    secure-port: 443
    secure-port-enabled: true
    non-secure-port: 80
    non-secure-port-enabled: false

The generated EurekaInstanceConfigBean uses the non-secure-port to construct both healthCheckUrl and secureHealthCheckUrl. (https://github.com/spring-cloud/spring-cloud-netflix/blob/master/spring-cloud-netflix-eureka-client/src/main/java/org/springframework/cloud/netflix/eureka/metadata/DefaultManagementMetadataProvider.java#L58)

spencergibb commented 4 years ago

In fact the url construction only uses server.port or port. See https://github.com/spring-cloud/spring-cloud-netflix/blob/master/spring-cloud-netflix-eureka-client/src/main/java/org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration.java#L149

enhbat commented 4 years ago

I'm using only secure ports:

eureka:
  instance:
    nonSecurePortEnabled: false
    securePortEnabled: true
    securePort: ${server.port}

this gives exception:

java[2580]: 2019-09-19 20:01:01.093 ERROR 2580 --- [nio-8765-exec-3] o.a.coyote.http11.Http11NioProtocol      : Error reading request, ignored
java[2580]: java.lang.NullPointerException: null
java[2580]: at org.apache.tomcat.util.net.NioEndpoint$NioSocketWrapper.getSslSupport(NioEndpoint.java:1392) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:853) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1593) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[na:na]
java[2580]: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[na:na]
java[2580]: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]
java[2580]: 2019-09-19 20:01:01.094 ERROR 2580 --- [nio-8765-exec-3] org.apache.tomcat.util.net.NioEndpoint   : Error running socket processor
java[2580]: java.lang.NullPointerException: null
java[2580]: at org.apache.coyote.http11.Http11InputBuffer.recycle(Http11InputBuffer.java:265) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.coyote.http11.Http11Processor.recycle(Http11Processor.java:1331) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.coyote.AbstractProtocol$ConnectionHandler.release(AbstractProtocol.java:1055) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:1023) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1593) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) ~[na:na]
java[2580]: at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) ~[na:na]
java[2580]: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) ~[tomcat-embed-core-9.0.24.jar!/:9.0.24]
java[2580]: at java.base/java.lang.Thread.run(Thread.java:834) ~[na:na]

Fallback to version 2.1.7 and Greenwich.SR2 working fine (from 2.1.8 and Greenwich.SR3)

spencergibb commented 4 years ago

@enhbat, totally unrelated, please open a new issue

rtomchinsky commented 4 years ago

I believe this is causing an issue for my application. We are migrating one of our services to run under a Kubernetes cluster and our solution was to have the service register itself with the url of the Ingress.

Setting the environment variable EUREKA_INSTANCE_HOSTNAME to the url of the Ingress works as expected, however the port is always set to ${server.port} regardless of setting EUREKA_INSTANCE_NON_SECURE_PORT=80. This is a problem because the k8s load balancer is on port 80 and therefore the registered service can never be reached because it tries to access the cluster on the wrong port.

Is my assessment correct? Is there any workaround?