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

27th
Jun 2016
Patrick Cornelißen
@pcornelissen
Jun 27 2016 04:04
good morning!
I have prepared a small PR, can someone have a look at orchit/spring-cloud-netflix@095cf9c This introduces a property to disable the hostname validation for the simpleRouteHostFilter via property. I am unsure how to test this properly without introducing wiremock into the project (because I found no way to check which hostnameValidation strategy is configured once the instances have been created...), which is a little bit out of scope for this PR, I think :-) I have added two tests to check the default value and the property key though.
If this is OK I'd issue the PR
(CLA is signed)
Spencer Gibb
@spencergibb
Jun 27 2016 04:10
I’d say it’s good enough to submit a PR.
Patrick Cornelißen
@pcornelissen
Jun 27 2016 04:27
spring-cloud/spring-cloud-netflix#1138
BigData & IoT Italia
@bigd_iot_italia_twitter
Jun 27 2016 07:09
I can use the api-gateway Zuul to relay WebSocket's traffic (not Stomp's traffic) of a microservice?
Spencer Gibb
@spencergibb
Jun 27 2016 07:44
No, zuul doesn't support persistent websocket connections. It should support a fallback mode.
Gleb Golda
@Salmondx
Jun 27 2016 11:48
@spencergibb can you explain, please, how to enable consul config watch. When i start app with Brixton.SR1 deps, i've got this exception
NoSuchBeanDefinitionException: No qualifying bean of type [org.springframework.cloud.consul.config.ConsulConfigProperties] found for dependency
No actual docs in spring-cloud-consul articles
Thibaud Lepretre
@kakawait
Jun 27 2016 12:28

@dsyer sorry for disturbing you again about X-Forwarded-* headers usage, but I have a new situation where RP is sending a X-Forwarded-Prefix: /foo to Zuul (without context path). Zuul is configured with new Spring 4.3 XForwardedFilter, thus X-Forwarded-Prefix is correctly interpreted and Zuul HttpServletRequest will be wrapped to now return /foo when asking getContextPath. However XForwardedFilter removes X-Forwarded-* headers so when request will be handle by PreDecorationFilter when filter try to determine if X-Forwarded-Prefix already exists https://github.com/spring-cloud/spring-cloud-netflix/blob/master/spring-cloud-netflix-core/src/main/java/org/springframework/cloud/netflix/zuul/filters/pre/PreDecorationFilter.java#L125 I will not find any header.

Do you think it could be a good idea to add same logic (prepending) if PreDecorationFilter finds an existing context-path?

if x-forwarded-prefix exists
  prepend x-forwarded-prefix to x-forwarded-prefix
if context-path exists
  prepend context-path to x-forwarded-prefix
Thibaud Lepretre
@kakawait
Jun 27 2016 12:35
@bigd_iot_italia_twitter you should wait Zuul 2.0 Netflix/zuul#112
about WebSocket possible support
Dave Syer
@dsyer
Jun 27 2016 12:58
@kakawait it's probably best if you open a JIRA issue in SPR
(Your question is about the servlet filter in Spring, right?)
Thibaud Lepretre
@kakawait
Jun 27 2016 13:13
@dsyer is not exactly the same issue as I opened few days ago about replacing/prepending. Just using this filter XForwardedFilter remove X-Forwarded-* headers from request that PreDecorationFilter relies on it (when stripPrefix is not false)
actually Spring zuul for routes with stripPrefix is not false it will add a X-Forwarded-Prefix header. Moreover if an existing X-Forwarded-Prefix header exists it will prepend. But if I'm loading XForwardedFilter I loose this functionaly because request.getHeader('X-Forwarded-Prefix') will be null
Marcos Barbero
@marcosbarbero
Jun 27 2016 13:23

Hi guys, I’m a question about service specific hystrix configuration. If my serviceId contains hyphen what should I do? Because it looks like that has no effect, maybe it’s translating from my-service-id to myServiceId.
Sample case:

shipping-br:
  hystrix.command.default.execution:
    isolation.thread.timeoutInMilliseconds: 120000

The shipping-br is my serviceId, if I remove the hyphen it works fine.

Jack.Zhang
@lucifer-zz
Jun 27 2016 13:32
anyone here ? I have a problem when I construct a eureka cluster
[TaskBatchingWorker-target_10.139.113.252-3] ERROR [com.netflix.eureka.cluster.ReplicationTaskProcessor] [ReplicationTaskProcessor.java:113] - Network level connection to peer 10.139.113.252; retrying after delay
com.sun.jersey.api.client.ClientHandlerException: org.apache.http.NoHttpResponseException: 10.139.113.252:8761 failed to respond
I found some err log
@dsyer
Dave Syer
@dsyer
Jun 27 2016 13:34
Not a lot of detail there
It worked for me last time I tried it
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:34
kaserver:8761 with status UP (replication=true)
2016-06-27 21:09:24,334 [TaskBatchingWorker-target_10.139.113.252-3] ERROR [com.netflix.eureka.cluster.ReplicationTaskProcessor] [ReplicationTaskProcessor.java:113] - N to peer 10.139.113.252; retrying after delay
com.sun.jersey.api.client.ClientHandlerException: org.apache.http.NoHttpResponseException: 10.139.113.252:8761 failed to respond
at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:187) ~[jersey-apache-client4-1.19.jar!/:1.19]
at com.netflix.eureka.cluster.DynamicGZIPContentEncodingFilter.handle(DynamicGZIPContentEncodingFilter.java:45) ~[eureka-core-1.3.4.jar!/:1.3.4]
at com.netflix.discovery.EurekaIdentityHeaderFilter.handle(EurekaIdentityHeaderFilter.java:27) ~[eureka-client-1.3.4.jar!/:1.3.4]
at com.sun.jersey.api.client.Client.handle(Client.java:652) ~[jersey-client-1.19.jar!/:1.19]
at com.sun.jersey.api.client.WebResource.handle(WebResource.java:682) ~[jersey-client-1.19.jar!/:1.19]
at com.sun.jersey.api.client.WebResource.access$200(WebResource.java:74) ~[jersey-client-1.19.jar!/:1.19]
at com.sun.jersey.api.client.WebResource$Builder.post(WebResource.java:570) ~[jersey-client-1.19.jar!/:1.19]
at com.netflix.eureka.transport.JerseyReplicationClient.submitBatchUpdates(JerseyReplicationClient.java:116) ~[eureka-core-1.3.4.jar!/:1.3.4]
at com.netflix.eureka.cluster.ReplicationTaskProcessor.process(ReplicationTaskProcessor.java:71) ~[eureka-core-1.3.4.jar!/:1.3.4]
at com.netflix.eureka.util.batcher.TaskExecutors$BatchWorkerRunnable.run(TaskExecutors.java:187) [eureka-core-1.3.4.jar!/:1.3.4]
at java.lang.Thread.run(Thread.java:745) [na:1.7.0_76]
Caused by: org.apache.http.NoHttpResponseException: 10.139.113.252:8761 failed to respond
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:143) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.conn.DefaultHttpResponseParser.parseHead(DefaultHttpResponseParser.java:57) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.io.AbstractMessageParser.parse(AbstractMessageParser.java:261) ~[httpcore-4.4.4.jar!/:4.4.4]
at org.apache.http.impl.AbstractHttpClientConnection.receiveResponseHeader(AbstractHttpClientConnection.java:283) ~[httpcore-4.4.4.jar!/:4.4.4]
at org.apache.http.impl.conn.DefaultClientConnection.receiveResponseHeader(DefaultClientConnection.java:251) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.conn.AbstractClientConnAdapter.receiveResponseHeader(AbstractClientConnAdapter.java:223) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.protocol.HttpRequestExecutor.doReceiveResponse(HttpRequestExecutor.java:272) ~[httpcore-4.4.4.jar!/:4.4.4]
at org.apache.http.protocol.HttpRequestExecutor.execute(HttpRequestExecutor.java:124) ~[httpcore-4.4.4.jar!/:4.4.4]
at org.apache.http.impl.client.DefaultRequestDirector.tryExecute(DefaultRequestDirector.java:685) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:487) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.client.AbstractHttpClient.doExecute(AbstractHttpClient.java:882) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:117) ~[httpclient-4.5.1.jar!/:4.5.1]
at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:55) ~[httpclient-4.5.1.jar!/:4.5.1]
at com.sun.jersey.client.apache4.ApacheHttpClient4Handler.handle(ApacheHttpClient4Handler.java:173) ~[jersey-apache-client4-1.19.jar!/:1.19]
... 10 common frames omitted
Dave Syer
@dsyer
Jun 27 2016 13:34
But that doesn't look fatal to me (it says it's retrying)
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:35
I hope it does not bother you, sir
Dave Syer
@dsyer
Jun 27 2016 13:35
Like I said. It works for me.
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:35
yes, it still works
Dave Syer
@dsyer
Jun 27 2016 13:36
Maybe you can ignore the error then?
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:37
if it means nothing, I can
I am not sure about it
is it just underlying issue ?
can i adjust any para to reduce or avoid it ? sir @dsyer
Dave Syer
@dsyer
Jun 27 2016 13:39
I don't know, sorry.
It looks like it's probably transient
When the servers first come up?
@marcosbarbero I don't know of a reason that wouldn't work (the hyphens). Hyphens are a bad idea in ribbon client names IIRC. Is that the problem?
@kakawait do you have a proposal that only requires changes here?
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:42
But these informations occur occasionally when they have run for a long time
Dave Syer
@dsyer
Jun 27 2016 13:42
I would have thought maybe the context path
Thibaud Lepretre
@kakawait
Jun 27 2016 13:44
@dsyer yes I think PreDecorationFilter should apply same strategy as X-Forwarded-Prefix (spring-cloud/spring-cloud-netflix#993). Moreover I will also fix issue (no X-Forwarded-Prefix at all) when Zuul has a custom context-path
I could open an PR and discuss more on it
Dave Syer
@dsyer
Jun 27 2016 13:44
OK.
Sounds good
Thibaud Lepretre
@kakawait
Jun 27 2016 13:44
I will try to handle every use case on tests to be sure that I will not break something
like X-Forwarded-Prefix and context-path is same time
I will first create a custom filter for my own project because I need to release something working soon and just after a polished PR (before the end of the week)
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:47
do i need care about it ? 2016-06-27 21:07:24,318 [pool-5-thread-1] INFO [com.netflix.discovery.DiscoveryClient] [DiscoveryClient.java:1111] - Getting all instance registry info from the eureka
2016-06-27 21:07:24,323 [TaskBatchingWorker-target_10.139.113.252-3] WARN [com.netflix.eureka.cluster.ReplicationTask] [ReplicationTask.java:35] - The replication of t9.132.144:eurekaserver:8761:Heartbeat@10.139.113.252 failed with response code 404
2016-06-27 21:07:24,323 [TaskBatchingWorker-target_10.139.113.252-3] WARN [com.netflix.eureka.cluster.PeerEurekaNode] [PeerEurekaNode.java:212] - EUREKASERVER/121.199.61:Heartbeat@10.139.113.252: missing entry.
I think there's something wrong with my eureka config, right ?
Dave Syer
@dsyer
Jun 27 2016 13:49
404 sounds like the server is there but not configured with the right path
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:50
the right path ? I just config basic config info
eureka:
server:
evictionIntervalTimerInMs: 1000
enableSelfPreservation: true
instance:
hostName: ${host.name}
client:
registerWithEureka: true
fetchRegistry: true
registryFetchIntervalSeconds: 1
serviceUrl:
defaultZone: ${eureka.peer}
Dave Syer
@dsyer
Jun 27 2016 13:51
Use fences (``` on a single line) to paste source code
${eureka.peer} is the URL
Maybe it's wrong?
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:52
java -Dhost.name=10.139.113.252 -Deureka.peer=http://10.253.1.220:8761/eureka/,http://10.253.2.104:8761/eureka/ -jar eurekaserver-1.0.0-SNAPSHOT.jar >eureka_server.log
I use this startup command
is there something wrong ?
Dave Syer
@dsyer
Jun 27 2016 13:56
Looks OK to me
Assuming it is actually running on those hosts
Jack.Zhang
@lucifer-zz
Jun 27 2016 13:57
yes, it works fine. I just want to find some way to avoid these annoying err log
it bothers me a lot
Marcos Barbero
@marcosbarbero
Jun 27 2016 14:05
@dsyer yeah, the hyphens are the problem. Well, if it’s not a good idea I’ll try to not use them.
Marcos Barbero
@marcosbarbero
Jun 27 2016 15:15
@dsyer I solved the problem registering the serviceId without hyphens and added manually a route with hyphen to the zuul.routes property