Conversation
| - host: "*.developers.facilities.rl.ac.uk" | ||
| http: &http_rules | ||
| paths: | ||
| - path: /publish/merge(/|$)(.*) |
There was a problem hiding this comment.
Are you sure want this as a target rewrite?
This will essentially stop any requests apart from /publish/merge/* from ever reaching a service? Also it makes any requests to /publish/merge/ to be rewriteen to /
There was a problem hiding this comment.
I don't see any harm in blocking any requests apart from /publish/merge/* . I don't understand your second question
There was a problem hiding this comment.
So lets say the app is running and expecting the path to be <some-domain>/publish/merge/123 this ingress will match on application but the path that will arive at hte service will be /<some-domain>/123 is that what you expect?
There was a problem hiding this comment.
There are also endpoints for checking message status at /status/summary and /status/{id} and liveness and readiness tests at /q/health/live and /q/health/ready.
There was a problem hiding this comment.
So lets say the app is running and expecting the path to be
<some-domain>/publish/merge/123this ingress will match on application but the path that will arive at hte service will be/<some-domain>/123is that what you expect?
Am I correct in understanding that if we use this path then <some-domain>/publish/merge/123 will never be called because its changed to /<some-domain>/123 and our application doesn't support this route. @vovsike
There was a problem hiding this comment.
There are also endpoints for checking message status at /status/summary and /status/{id} and liveness and readiness tests at /q/health/live and /q/health/ready.
I did put in the probes earlier but they errored out the pod, so I thought Ill put them later once we have the publisher publish messages on dev.
There was a problem hiding this comment.
I don't understand that last comment. If the liveness/readiness tests show as failing the publisher isn't working correctly and we shouldn't be trying to publish messages with it?
| spec: | ||
| ports: | ||
| - name: debug | ||
| protocol: TCP | ||
| port: 7005 | ||
| targetPort: 7005 |
There was a problem hiding this comment.
Is the debug port evev exposed? on the java side?
There was a problem hiding this comment.
@dmbrownless do we need debug port exposed for publisher ?
There was a problem hiding this comment.
This is for remote debugging the running java correct? We certainly won't want it in production 😄 but dev; is it routinely exposed on our dev services?
It's not something I routinely use and I don't think we are or should be running our containers with java_enable_debug set, it's a performance hog.
3 participants
closes: #56