...
- Preferred approach. Returns HTTP 200 if layout is able to be returned. Returns HTTP 500 if uPortal is unable to connect to the database (by default reads occur from UP_MESSAGE table and render event writes occur to UP_RAW_EVENTS (unless event aggregation configuration has this disabled). Data (guest layout) is heavily cached and rarely pulled from the database so this is a moderately low load health check. There is still a fair bit of computation that occurs to generate the response so this can also provide a rough indication of target system response time indication for load leveling.
| Tip |
|---|
If the load balancer has trouble following HTTP 302 redirects, configure it to send a fixed cookie value that Tomcat/Java would not create in the request. For example: wget --header="Cookie: JSESSIONID=23485898E75DB49-LoadBalancer" http://localhost:8080/uPortal/layout.json The first request will get HTTP 302 redirected through /Login as normal, but subsequent requests will return immediately with an HTTP 200. However it is better to follow HTTP 302 redirects (might need to enable Connection: keep-alive for this). |
| Tip |
|---|
Configuring the load balancer to send a fixed cookie value will continue to re-use a single HTTP session and not create many unnecessary HTTP sessions in Tomcat just for a health check. Though not a big operational impact, this strategy is a useful optimization that helps minimize the heap memory impact of operational health checks. |
...