Describe the bug
We have started to observe some http connection drop after upgrading 26.0.0.7 --> 26.0.0.8, in some environments only.
The test environments where we reproduce have this flow:
Browser --> Openshift HAProxy (reencrypt) --> Liberty Pods
- Typically the openapi JS bundle fails from the browser (when loading openapi ui), but there can be other errors.
- But for example direct CURL CLI of the same JS bundle never fails.
Steps to Reproduce
Display Openapi ui in the browser.
Often the loading of the JS bundle fails:
Expected behavior
No connection drop, especially on low traffic.
Diagnostic information:
- OpenLiberty Version: 2026.0.0.8
- Java Version: Semeru 21
Additional context
- Reverting to 26.0.0.7 fixes the issue.
- In 26.0.0.8,, forcing http/1.1 in server.xml fixes the issue
From the info we have so far, the cause of the failure seems to be between haproxy backend side and liberty pods (not on frontend connections), and http2 specific.
Also the fact that simple CURL works on the same resource suggests this is sensitive to concurrent/multiplexed requests.
Describe the bug
We have started to observe some http connection drop after upgrading 26.0.0.7 --> 26.0.0.8, in some environments only.
The test environments where we reproduce have this flow:
Browser --> Openshift HAProxy (reencrypt) --> Liberty Pods
Steps to Reproduce
Display Openapi ui in the browser.
Often the loading of the JS bundle fails:
Expected behavior
No connection drop, especially on low traffic.
Diagnostic information:
Additional context
From the info we have so far, the cause of the failure seems to be between haproxy backend side and liberty pods (not on frontend connections), and http2 specific.
Also the fact that simple CURL works on the same resource suggests this is sensitive to concurrent/multiplexed requests.