Hello list,
After some discussion in #haproxy channel about MAX_SYSLOG_LEN, i think
we should raise this default value from 1024 to 2048.
Multiple arguments for that, RFC5426
(http://tools.ietf.org/html/rfc5426#section-3.2) encourage all receivers
to support up to 2048 and recommend that syslog
I really like this feature, and it was something actually on my todo
list of things to look into adding to haproxy.
However there is one thing I would consider supporting. Instead of
requiring the index of the capture keyword in the config, which is very
cumbersome and awkward in my opinion,
Hi,
On Thu, Feb 06, 2014 at 10:05:49AM -0800, Qingshan Xie wrote:
Willy,
in your release announcement, you mentioned
Some code is still pending for a next version. Thierry has finishedthe
map+acl merge which will allow to manipulate ACLs on the fly just
like maps today, ..
(...)
does
Hello,
Since I did not get any responses on this, I decided to try
motivating a reponse
by attempting an implementation. I am attaching a patch that does
this. Admittedly
this patch is an iteration and I am not submitting it for anything
more than receiving
feedback, on the requirement,
On Thu, Feb 06, 2014 at 02:05:07PM -0600, Kuldip Madnani wrote:
Hi,
I am trying to connect my RabbitMQ cluster through HAProxy.When connected
directly to RabbitMQ nodes it works fine but when connected through HAProxy
it raises following exception :
What are your client/server timeouts?
Dear all,
In the latest HAProxy 1.5 release (dev22), it is indicated that
keep-alive is now enabled by default for both client and server sides.
I have some questions regarding its use in the following scenario.
I use HAProxy in front of an array of servers: one nginx for
delivering static
Hi,
I am trying to connect my RabbitMQ cluster through HAProxy.When connected
directly to RabbitMQ nodes it works fine but when connected through HAProxy
it raises following exception :
com.rabbitmq.client.ShutdownSignalException: connection error; reason:
java.io.EOFException
at
I have the following setting for HAProxy and no settings in client for
connectionFactory:
defaults
log global
modetcp
option tcplog
option dontlognull
retries 3
option redispatch
maxconn 4096
timeout connect 5s # default 5 second time out if a backend is not
On Thu, Feb 06, 2014 at 02:15:31PM -0600, Kuldip Madnani wrote:
I have the following setting for HAProxy and no settings in client for
connectionFactory:
defaults
log global
modetcp
option tcplog
option dontlognull
retries 3
option redispatch
maxconn
I configured my rsyslog with below settings and was able to generate
haproxy.log in my directory /opt/app/haproxy but it gets generated with
owner root and file permission rw--.Does anybody know or implemented as
to how to change the ownership and file permissions for the log directory.I
know
Hi,
Just providing some closure to this interesting edge case...
Thank you for this detailed report, this is *very* useful. As you tracked
the crash to happen inside openssl, I think you should file a report to
centos/redhat because it's a security issue.
CentOS is bug-for-bug compatible
Hi,
On Thu, Feb 06, 2014 at 02:25:02PM -0600, Ryan O'Hara wrote:
On Thu, Feb 06, 2014 at 02:15:31PM -0600, Kuldip Madnani wrote:
I have the following setting for HAProxy and no settings in client for
connectionFactory:
defaults
log global
modetcp
option tcplog
Stupid question, but what ports do you have defined in your “bunnies.config”
file? I see you listening on 5678 but I know the default port for Rabbit is
5672. I see 5672 listed in your haproxy config but RabbitMQ might be listening
elsewhere. Also, what client are you using to make the
Hi James,
On Thu, Feb 06, 2014 at 08:36:00PM +, James Hogarth wrote:
CentOS is bug-for-bug compatible (see recent libsvr2 issue there) and
seeing as we don't at this time have a support contract with RH plus it it
is not reproducible on the current release (the glibc in 6.5 fixes it) I
Hi,
In the latest HAProxy 1.5 release (dev22), it is indicated that
keep-alive is now enabled by default for both client and server sides.
I have some questions regarding its use in the following scenario.
I use HAProxy in front of an array of servers: one nginx for
delivering static
we are in the process of switching from a foundry load balancer (really
old) to haproxy.
we originally went with 1.4 and stunnel, however stunnel caved at 1000
connections and we had to find a new solution, so we are now running 1.5.
we've done a lot of testing, but we feel that we just don't
Thanks for your suggestion, Lukas.
For my own understanding, are you saying that there is no difference
between having http-keep-alive and having http-server-close to a
backend server once websocket connection to that server is establish,
and both settings allow for establishing websocket
(a) It's not clear to me how the threshold upgrade is determined? What
triggers the record size bump internally?
The forwarding mechanism does two things :
- the read side counts the number of consecutive iterations that
read() filled the whole receive buffer. After 3 consecutive
TCP mode load balancing would treat each TCP quad (source ip/source port,
dest ip/dest port), stream, or flow as a session or in other words, the
TCP stream is the basic unit of TCP load balancing.
You can enable the stats http interface and monitor that in your browser
for some useful metrics
Hi Ilya,
On Thu, Feb 06, 2014 at 04:14:14PM -0800, Ilya Grigorik wrote:
(...)
I preferred to only rely on CF_STREAMER and ignore the _FAST variant
because it would only favor high bandwidth clients (it's used to
enable splice() in fact). But I thought that CF_STREAMER alone would
do the
20 matches
Mail list logo