Hello,
On Wed, Nov 05, 2025 at 11:32:17AM +0100, Karim Ayari wrote:
> hi,
>
> Since upgrading from HAProxy 1.8 to 2.4, access to our WebLogic 12 servers
> has been performing very poorly -- with longer response times and frequent
> error responses.
>
> Indeed, the WebLogic server returns the following error:
>
> > SEVERE (05/11/2025 - 10:56:01) - Error while accessing the specific
> > academic movement URL
> > javax.naming.CommunicationException [Root exception is
> > java.net.ConnectException: http://webservices.domain.fr:80: Bootstrap to
> > webservices.domain.fr/192.168.149.123:80 failed. It is likely that the
> > remote side declared peer gone on this JVM]
Looks strange, as if the process had died or something like this.
Maybe it's randomly crashing ? Where are you measuring the response
times, on the client or in haproxy logs ?
> Our HAProxy configuration is in *HTTP mode*, as shown below:
>
> #---------------------------------------------------------------------
> > # Global settings
> > #---------------------------------------------------------------------
> > global
> > log 127.0.0.1 local0 debug
> > chroot /var/lib/haproxy
> > pidfile /var/run/haproxy.pid
> > maxconn 8000
> > user haproxy
> > group haproxy
> > daemon
> > #tune.bufsize 32768
> > tune.bufsize 65536
> > tune.maxrewrite 16384
> > tune.ssl.default-dh-param 2048
> > stats socket /var/lib/haproxy/stats
> >
> > defaults
> > mode http
> > log global
> > option dontlognull
> > log-format "%ci:%cp [%tr] %ft %b/%s %TR/%Tw/%Tc/%Tr/%Ta %ST %B %CC %CS
> > %tsc %ac/%fc/%bc/%sc/%rc %sq/%bq %hr %hs %{+Q}r"
> > option dontlognull
> > option forwardfor except 127.0.0.0/8
> > option redispatch
> > retries 0
> > timeout http-request 5m
> > timeout queue 3m
> > timeout connect 5m
> > timeout client 5m
> > timeout server 5m
> > timeout http-keep-alive 100s
> > timeout check 100s
> > maxconn 8000
> >
> > frontend f_192_168_149_101_80
> > bind 192.168.149.101:80
> > mode http
> > http-request capture req.hdr(Host) len 80
> > option forwardfor
> > option http-no-delay
> > option accept-invalid-http-request
> > acl weblo path_beg -i /fia_wls_internal
> > use_backend b_webservices_weblo if weblo
> > default_backend b_webservices
> >
> > #==========================
> > # BACKEND WEBLO : weblo
> > #==========================
> > backend b_webservices_weblo
> > no option http-pretend-keepalive
> > balance source
> > #balance roundrobin
> > mode http
> > http-reuse safe
> > option http-keep-alive
> > timeout connect 5s
> > timeout server 1h
> > timeout http-keep-alive 1h
> > ###
> > option forwardfor
> > option accept-invalid-http-response
> > stick-table type string len 64 size 10k expire 12h
> > stick on cookie(JSESSIONID)
> > stick on cookie(PHPSESSID)
> > cookie SRV_WEBSERVICES insert indirect nocache
> > server web1 192.168.149.123:80 cookie web1 check weight 1 maxconn 3000
> > server web2 192.168.149.129:80 cookie web2 check weight 1 maxconn 3000
> >
>
> Here's a quick overview of the infrastructure:
>
> HAProxy 2.4 ------- Apache 2.4 ------- WebLogic 12.2
>
>
> We have tried several changes to the http-reuse setting, switching between
> never and safe, removed the option http-server-close, and added keepalive,
> but nothing seems to work.
>
> We would be very grateful for your help.
A few points to check:
- exact versions. haproxy 2.4 is a branch, but the up-to-date 2.4
version is 2.4.30, and anything below that is affected by known
bugs that you can check here: https://www.haproxy.org/bugs/bugs-2.4.html
(similar for apache and weblo BTW)
- between 1.8 and 2.4, many things changed in haproxy, threads are now
enabled by default, header fields are exchanged in lower case like in
HTTP/2 and HTTP/3, idle connections to servers are preserved. It is
for example possible that weblo doesn't see a specific header field
because it mistakenly searches it with a particular case (though I
think that Apache would re-normalize it anyway). It's also possible
that "maxconn 3000" is way too high for them and that in the past it
simply used to work by pure luck, for example because it didn't take
idle connections into account. You could start by trying to lower
these numbers.
- do the errors and slowdowns happen immediately on startup or only
after some time, as if stuff was accumulating ?
- what do you see in your logs for the failed requests ? Have a look
at the termination flags (e.g: sH indicates server timeout while
waiting for headers etc). You can pass the halog utility on your
logs to sort these codes:
halog -tc < /path/to/logs # sort by term code
halog -st < /path/to/logs # sort by HTTP status code
- what's your average load (req/s etc) and is the system overloaded
or even swapping ?
- do you have a particular reason to migrate *now* to a version that
reaches end of support in 6 months when others are available that
are still maintained for 5 years ? I'm asking because you seem to
be running really outdated and unmaintained versions (1.8 died 3
years ago) so I'm wondering how long you'll be running on 2.4 after
it dies :-/
- I'm worried when I see "option http-no-delay", because this is
exclusively used to work around bogus servers, so I'm wondering if
it was added in the past already to hide an identified bug. You
could recheck if 1.8 is still fast without that option.
- if you don't find anything with the checks above, you'll need to
take a network capture between haproxy and Apache, both in 1.8 and
2.4, to compare how a failed request behaves on both versions.
Hoping this helps,
Willy
