Date 1 - 2 of 2
TCP Upgrade issue
Bagwe, Kunal <kunal.bagwe@...>
We are aware that cf release is no longer supported by community but we are using cf release in production environment. Migration to cf deployment is under progress.
We are using cf release v283 and routing release v163.When we upgrade routing from v163 to v164, we are getting error "Empty Reply from Server" when we curl the TCP application.
While upgrading routing release from v163 to v164, we have commented out "tcp_emitter" jobs, just kept the oauth_secret property for tcp_emitter inside routing manifest as mentioned in below specified link :
As mentioned in link "https://lists.cloudfoundry.org/g/cf-dev/attachment/7102/0/attachment.html",
also added following properties in CF manifest file :
routing_api.url: defaults to http://routing-api.service.cf.internal
routing_api.port: defaults to 3000
routing_api.auth_enabled: defaults to true
We also checked the logs inside tcp_router, found an error as "tcp-router.watcher.failed-to-get-next-routing-api-event".
Also checked the logs for routing_api which stats following errors:
Lost lock 'v1/locks/routing_api_lock'
Exit trace for group:\n lock-releaser exited with error: Exit trace for group:\n lock-maintainer exited with error: lock lost\n\nsql-route-pruner exited with nil\n metrics exited with nil\n route-register exited with nil\n conn-stopper exited with nil\n api-server exited with nil\n seed-router-groups exited with nil\n lock-acquirer exited with nil\n migration exited with nil\n.
Also set the log_level to debug for routing_api and tcp_router.
As tcp_emitter support has been removed from routing release version 164, so what configuration has to be done in place of it.
Please suggests configurations, modifications to be performed.
Thanks & Regards,
Atos Cloud Foundry
Eric Malm <emalm@...>
toggle quoted message Show quoted text
Since you're still using a cf-release-based deployment manifest, I expect you also have a separate diego-release-based manifest to deploy the Diego cells and control-plane components, including the route-emitter. If that's correct, you should set the `tcp.enabled` BOSH property in your Diego manifest (for example, https://github.com/cl
The README in routine-release v0.164.0 does mention at https://github.com/cloudfou
Eric, CF Diego PM
On Mon, May 14, 2018 at 5:30 AM, Bagwe, Kunal <kunal.bagwe@...> wrote:
|1 - 2 of 2|