jhipster / generator-jhipster

JHipster is a development platform to quickly generate, develop, & deploy modern web applications & microservice architectures.
https://www.jhipster.tech
Apache License 2.0
21.53k stars 4.02k forks source link

Gateway is unable to connect to Microservice on Cloudfoundry #3677

Closed krishna383 closed 8 years ago

krishna383 commented 8 years ago
Overview of the issue

The gateway is unable to connect to the microservice. I am receiving 500 as the response from the microservice. Based on the logs, I dont see any requests to the microservice at all.

I have followed the instructions to deploy my microservices application. I can successfully see that my microservice is registered with the registry.

I am also able to see that under Gateway.

image

Motivation for or Use Case

But I am seeing the IP address of the server instead of the URL. I think that is the reason, the Gateway is unable to communicate the Microservice. The requests are responding with 500.

JHipster Version(s)

JHipster registry Version: 2.1.0 Jhipster Generator version: 3.3.0

No

JHipster configuration, a .yo-rc.json file generated in the root folder

Gateway: { "generator-jhipster": { "jhipsterVersion": "3.3.0", "baseName": "iepweb", "packageName": "com.datalakes.iep", "packageFolder": "com/datalakes/iep", "serverPort": "8289", "authenticationType": "jwt", "hibernateCache": "hazelcast", "clusteredHttpSession": "hazelcast", "websocket": "no", "databaseType": "sql", "devDatabaseType": "postgresql", "prodDatabaseType": "postgresql", "searchEngine": "no", "buildTool": "maven", "jwtSecretKey": "293ee97ee65c2b99e6df4618328134f150fb3692", "useSass": true, "applicationType": "gateway", "testFrameworks": [ "protractor" ], "jhiPrefix": "jhi", "enableTranslation": true, "nativeLanguage": "en", "languages": [ "en", "es" ], "enableSocialSignIn": false } }

Microservice: { "generator-jhipster": { "jhipsterVersion": "3.3.0", "baseName": "postgresconnect", "packageName": "com.datalakes.iep", "packageFolder": "com/datalakes/iep", "serverPort": "8081", "authenticationType": "jwt", "hibernateCache": "hazelcast", "databaseType": "sql", "devDatabaseType": "postgresql", "prodDatabaseType": "postgresql", "searchEngine": "no", "buildTool": "maven", "jwtSecretKey": "160515863d1a71291dd7b95c4fc0805e27259f80", "enableTranslation": false, "applicationType": "microservice", "testFrameworks": [ "gatling" ], "jhiPrefix": "jhi", "skipClient": true, "skipUserManagement": true } }

Entity configuration(s) entityName.json files generated in the .jhipster directory
Browsers and Operating System
Reproduce the error
Related issues
Suggest a Fix
jdubois commented 8 years ago

That's normal because there's a small config to do here -> did you deploy using the cloudfoudry sub-generator? That's supposed to do that config.

krishna383 commented 8 years ago

Yes I did. Are you referring to prefer-ip-address ? If so I see that to be false in the config/application-cloudfoundry.xml for the jhipster-registry. As it was not working I also made it false in my prod config for it.

Here is my registry config for reference: Registry Configuration.pdf

jdubois commented 8 years ago

I'm not sure I understand: you used the sub-generator, and it did set the prefer-ip-address property, but it wasn't working?

krishna383 commented 8 years ago

Yes I used the sub-generator. Yes it did set the prefer-ip-address to false in the registry project.

But yes it was still not working. If it works, does it show the actual URL instead of IP in the gateway?

jdubois commented 8 years ago

I'm sorry, but I don't understand what you mean by "does it show the actual URL instead of IP".

Reading your issue again, I realize that the gateway does see the microservice, and that both of them are correctly configured in the registry.

I also realize that the gateway does connect to the microservice, your issue is in fact that the microservice sends back a 500 error -> in that case the "prefer-ip-address" is indeed working correctly, as the gateway can send a request to the microservice.

The real error is this 500 error from the microservice: can you send a stacktrace? the error message?

krishna383 commented 8 years ago

Here is the response:

{"timestamp":"2016-06-03T15:05:12.361+0000","status":500,"error":"Internal Server Error","exception":"com.netflix.zuul.exception.ZuulException","message":"TIMEOUT"}

And I dont see any requests in the log of the microservice. Here are last lines from the log. Should I increase the log level?

2016-06-03T12:53:53.000+00:00 [APP] OUT 2016-06-03 12:53:53.872 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T13:23:53.000+00:00 [APP] OUT 2016-06-03 13:23:53.874 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T13:33:53.000+00:00 [APP] OUT 2016-06-03 13:33:53.875 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T13:58:53.000+00:00 [APP] OUT 2016-06-03 13:58:53.877 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T14:53:53.000+00:00 [APP] OUT 2016-06-03 14:53:53.882 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T14:58:53.000+00:00 [APP] OUT 2016-06-03 14:58:53.882 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T14:38:53.000+00:00 [APP] OUT 2016-06-03 14:38:53.880 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration 2016-06-03T15:03:53.000+00:00 [APP] OUT 2016-06-03 15:03:53.884 INFO 19 --- [trap-executor-0] c.n.d.s.r.aws.ConfigClusterResolver : Resolving eureka endpoints via configuration

jdubois commented 8 years ago

Sorry, but if you have a timeout on the gateway, then the 500 error comes from the gateway, not from the microservice... Do you have any log on your microservice?

Can you check that you have everywhere:

eureka:
    instance:
        prefer-ip-address: false
        hostname: ${vcap.application.uris[0]}

As from my understanding, the gateway just doesn't have the application hostname, and so it's just not finding it.

krishna383 commented 8 years ago

I am not seeing any log on the microservice. I think it is not reaching microservice and failing to reach microservice from the gateway.

I double checked the registry, microservice and gateway. All the 3 apps have the application-cloudfoundry.yml which has the above configuration (prefer-ip-address: false). I am assuming application-cloudfoundry.yml would override the application-prod.yml.

In application-prod.yml, the prefer-ip-address is set to false in the microservice and gateway.

If this configuration works correctly, does it show the host name in the below Gateway page instead of the IP Address?

image

krishna383 commented 8 years ago

It started working after updating all the application-prod.yml. Looks like it was not using the the application-cloudfoundry.yml

jdubois commented 8 years ago

OK, so we know what the right config is -> main issue is whether this config was correctly set up by the sub-generator, or not. I've tried it and it looked OK, then I have a higher version than you -> I'm guessing you either misconfigured something at some point, or that it was corrected in the meantime.

This is why I'm closing it, but I'm keeping an eye on this, and anyway I'll do a demo of this for a customer next week, so I will definitely test this again.