lease feel free to email us for further clarification.
Note quote must be valid for 10 days
Warm regards,
Chris Rorie
Director, Corporate Procurement
Telephone: +1 210-998-1040
E-mail: chris.ro...@familydollarz.com
Web Site: www.familydollarz.com
ind Regards
*Thanks!*
*Chris Hayes**! Business Development Manager*
*Note:* - Our next conversation will be on my corporate Email ID. If this
is something you are interested in, please respond to this email. If this
is not your interest,
ind Regards
*Thanks!*
*Chris Hayes**! Business Development Manager*
*Note:* - Our next conversation will be on my corporate Email ID. If this
is something you are interested in, please respond to this email. If this
is not your interest,
Hello everybody,
I am one of the maintainers of the haproxy package for the OpenWRT
project. I am reaching out to you because - as of HAProxy version
2.1.5 - we experience build-issues on some of our build-targets.
We mostly use MUSL and uclibc as our c-libraries because they are more
suitable for
Hi Илья,
I agree! I just made a new patch which adds the missing documentation
for the new build-TARGET as well as the two new CPU-types.
thanks,
Chris
On Tue, Feb 11, 2020 at 8:29 PM Илья Шипицин wrote:
>
> there's AIX related build guide
>
> https://github.com/haproxy/ha
Hi Willy,
I am really sorry - it feel like I fell into every newby trap. I
attached the proposed patch to this mail. Also, I will never use Gmail
to send patches again.
Thank you for your patience,
Chris
On Tue, Feb 11, 2020 at 8:07 AM Willy Tarreau wrote:
>
> On Mon, Feb 10, 2020 at
atures for TARGET '$(TARGET)' (disable
with 'USE_xxx=') :"
$(Q)set -- $(foreach opt,$(patsubst USE_%,%,$(use_opts)),$(if
$(USE_$(opt)),$(opt),)); echo " $$*" | (fmt || cat) 2>/dev/null
--
2.25.0
Best regards,
Christian
On Mon, Feb 10, 2020 at 12:
r admin in regards to the longtime
prospects of this server and report back to you.
> thanks!
> Willy
You are welcome - I am happy I can contribute!
thanks,
Christian
On Thu, Feb 6, 2020 at 3:36 PM Willy Tarreau wrote:
>
> Hello Christian,
>
> On Mon, Feb 03, 2020 at 12:09:4
Hello everybody,
I spent some time making haproxy compile and run successfully on AIX
7.2 using GCC 8.3 and wanted to contribute my patch in the hope that
it could be merged. The patch is based on the current haproxy 2.1 head
revision. I can make one for the development branch too - but it
should
OK, thank you.
On Fri, Jan 10, 2020 at 11:07 AM Tim Düsterhus wrote:
> Chris,
>
> Am 10.01.20 um 16:17 schrieb Chris Software:
> > I am looking at the tags v2.1.1 and v2.1.2 on your main git repository
> > listed here: http://git.haproxy.org/?p=haproxy-2.1.git and don&
that has failed and needs to
be restarted? Perhaps they need to be pushed manually?
Thank you,
Chris
Hello haproxy,
My team member has completed a patch which allows someone to* configure* the
format of the proxied certificate's DN and Issuer DN.
I have attached the patch here. How can we submit this for inclusion to
haproxy?
Chris
On Fri, Dec 20, 2019 at 12:53 PM Chris Software
.
There is discussion about submitting this change back as a patch.
Chris
I am running haproxy in an Alpine Docker container. It is doing SSL
termination for https and injecting the client DN into the X-ForwardedFor
HTTP Header. But the format it uses for the client DN is not one that my
application supports.
Can I change the format somehow, perhaps using openssl.cnf? P
On 12/05/19 5:29 AM, Willy Tarreau wrote:
> On Fri, May 10, 2019 at 11:52:31AM +0200, Willy Tarreau wrote:
>>> Actually I think there's an additional change needed in my patch. By
>>> passing the parameters to HA_ATOMIC_CAS we end up attempting to
>>> dereference a void *. So this should needs to c
On 10/05/19 8:57 PM, Willy Tarreau wrote:
> On Thu, May 09, 2019 at 05:07:40PM +1200, Chris Packham wrote:
>> __ha_cas_dw() is used in fd_rm_from_fd_list() and when built without
>> USE_THREADS=1 the linker fails to find __ha_cas_dw(). Add a definition
>> of __ha_cas
__ha_cas_dw() is used in fd_rm_from_fd_list() and when built without
USE_THREADS=1 the linker fails to find __ha_cas_dw(). Add a definition
of __ha_cas_dw() for the #ifndef USE_THREADS case.
Signed-off-by: Chris Packham
---
Changes in v2:
- cast to int * to avoid dereferencing void *
include
On 9/05/19 9:50 PM, William Lallemand wrote:
> On Thu, May 09, 2019 at 03:52:45AM +0000, Chris Packham wrote:
>> Hi,
>>
>> I'm encountering the following linker error when building haproxy-1.9.7
>>
>> make CC=arm-softfloat-linux-gnueabi USE_OPENS
__ha_cas_dw() is used in fd_rm_from_fd_list() and when built without
USE_THREADS=1 the linker fails to find __ha_cas_dw(). Add a definition
of __ha_cas_dw() for the #ifndef USE_THREADS case.
Signed-off-by: Chris Packham
---
include/common/hathreads.h | 5 +
1 file changed, 5 insertions
Hi,
I'm encountering the following linker error when building haproxy-1.9.7
make CC=arm-softfloat-linux-gnueabi USE_OPENSSL=1
...
LD haproxy
/usr/bin/../lib/gcc/arm-softfloat-linux-gnueabi/8.3.0/../../../../arm-softfloat-linux-gnueabi/bin/ld:
src/fd.o: in function `fd_rm_from_fd
Previously, -sf and -sd command line parsing used atol which cannot
detect errors. I had a problem where I was doing -sf "$pid1 $pid2 $pid"
and it was sending the gracefully terminate signal only to the first pid.
The change uses strtol and checks endptr and errno to see if the parsing
worked. It
(from git format-patch -1 as per mail thread [PATCH] CONTRIB: log: emit warning
when -sf/-sd cannot parse argument)
Previously, -sf and -sd command line parsing used atol which cannot
detect errors. I had a problem where I was doing -sf "$pid1 $pid2 $pid"
and it was sending the gracefully termi
Previously, -sf and -sd command line parsing used atol which cannot
detect errors. I had a problem where I was doing -sf "$pid1 $pid2 $pid"
and it was sending the gracefully terminate signal only to the first pid.
The change uses strtol and checks endptr and errno to see if the parsing
worked. I
ES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-
> SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-
> AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-
> SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:
> DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!
> aECDH
I am trying to stop backend health check error messages from being logged to
the system console.
I have tried using "no option log-health-checks” in my configuration
defaults
log global
no option log-health-checks
mode http
option dontlognull
But I am still seeing error messa
> On 29 Mar 2016, at 18:22, Paul Draper wrote:
>
> As I understand it, there seems to no way to add a server to HAProxy without
> incurring significant disruption. Adding a server requires reloading
> configuration. This loses all statistics, all health check information, etc.
> So, for inst
is something that could be considered for a future
haproxy release?
Many thanks,
Chris
On 18 Mar 2016, at 03:03, Igor Cicimov
mailto:ig...@encompasscorporation.com>> wrote:
On Fri, Mar 18, 2016 at 10:38 AM, Chris Warren
mailto:ch...@beamly.com>> wrote:
Hi,
We use haproxy in an auto-scaling environment. On an auto-scaling event, the
haproxy configuration is rewri
Ideally I would like to return 429 Too Many Requests.
-Original Message-
From: Willy Tarreau
Date: Tuesday, February 9, 2016 at 11:27 PM
To: Chris White
Cc: "haproxy@formilux.org"
Subject: Re: Limiting the size of the backend queues
>On Tue, Feb 09, 2016 at 03:
, but no way of actually
limiting the total number of requests queued per backend proxy. I really want
to put limits on how many requests are queued per backend proxy, is there
anyway of doing this?
Chris White
Building RPMs from the provided haproxy.spec fails due to references to
config files that do not exist. Please see attached patch for suggested fix.
I should point out, this patch will inevitably create an empty /etc/haproxy
dir and I'm not sure that's desirable/intended.
Thanks,
C
called right
before signal_unregister_handler() so is it possible that something went
sideways while executing soft_stop(), leaving this PID sort of in limbo?
Regards,
Chris
On Fri, Oct 30, 2015 at 3:28 PM, Vincent Bernat wrote:
> ❦ 30 octobre 2015 15:14 -0400, Chris Riley :
>
> >
proc/11537/status
SigQ: 3/63840
SigPnd:
SigBlk: fffe7bfa7a26
SigIgn: 00001000
SigCgt: 000180300205
Regards,
Chris
On Fri, Oct 30, 2015 at 3:09 PM, Vincent Bernat wrote:
> ❦ 30 octobre 2015 14:50 -0400, Chris Riley :
>
> > Good idea. I just tried an
gdb shows this when attached to the same process:
0x003bf84e8f23 in __epoll_wait_nocancel () from /lib64/libc.so.6
Regards,
Chris
On Fri, Oct 30, 2015 at 2:38 PM, Vincent Bernat wrote:
> ❦ 30 octobre 2015 14:36 -0400, Chris Riley :
>
> > When the processes stack up, the ol
)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, {}, 200, 1000)= 0
epoll_wait(0, ^C
Process 11537 detached
-Chris
On Fri, Oct 30, 2015
When the processes stack up, the old ones don't respond to anything other
than 'kill -9'.
On Fri, Oct 30, 2015 at 1:20 PM, Willy Tarreau wrote:
> On Fri, Oct 30, 2015 at 12:23:57PM -0400, Chris Riley wrote:
> > Hi Willy,
> >
> > Thanks for your quick reply.
te/templates/haproxy.cfg.ctmpl"
destination = "/etc/haproxy/haproxy.cfg"
command = "/sbin/service haproxy reload || true"
}
I will let you know if I find anything of interest.
Regards,
Chris
On Fri, Oct 30, 2015 at 1:20 PM, Willy Tarreau wrote:
> On Fri, Oct 30, 2
the old process. I'm
following Willy's suggestions to try to determine what may be happening.
Regards,
Chris
On Fri, Oct 30, 2015 at 10:54 AM, Vincent Bernat wrote:
> ❦ 30 octobre 2015 10:50 -0400, Chris Riley :
>
> > I'm going to compile the 3.10 kernel from CentOS
is related to or that same as this one?
https://github.com/haproxy/haproxy/issues/48
Regards,
Chris
On Fri, Oct 30, 2015 at 11:50 AM, Willy Tarreau wrote:
> Hi Chris,
>
> On Fri, Oct 30, 2015 at 11:18:30AM -0400, Chris Riley wrote:
> > Hi Willy,
> >
> > The permissions
d SIGTTOU) or in
pause_proxy() the proxy state check is returning 1 at the top of the
pause_proxy() function. I'm going to add some additional logging statements
to see if I can isolate what's happening.
Regards,
Chris
On Fri, Oct 30, 2015 at 3:11 AM, Willy Tarreau wrote:
> On Fri, Oct 30,
t (cannot bind socket) is sent to stderr and is logged by
consul-template.
I'm going to compile the 3.10 kernel from CentOS 7 for CentOS 6 and see if
the behavior persists and report back.
Thanks,
Chris
On Fri, Oct 30, 2015 at 3:04 AM, Vincent Bernat wrote:
> ❦ 30 octobre 2015 00:34
Hi Vincent,
The kernel version is 2.6.32-358.23.2.el6.x86_64, the OS is CentOS 6.4.
-Chris
On Thu, Oct 29, 2015 at 6:29 PM, Vincent Bernat wrote:
> ❦ 29 octobre 2015 15:16 -0400, Chris Riley :
>
> > Reloading haproxy: [ALERT] 301/141300 (25939) : Starting proxy
> > hap
200.100 but it doesn't make any sense that HAProxy also reports
that it cannot bind on IPs:ports that are assigned to that server.
Does anyone have ideas as to why this might occur?
Best Regards,
Chris Riley
Amazon Linux (kernel version 3.14)
In addition to the "failed connection attempts", I also noticed that I was
getting an equal number of "resets received for embryonic SYN_RECV sockets".
On Sat, May 16, 2015 at 4:40 AM, Willy Tarreau wrote:
> On Wed, May 13, 2015 at
I've found the commit that caused this change in behavior.
>From 1.4.23:
- MEDIUM: checks: avoid accumulating TIME_WAITs during checks
commit fd29cc537b8511db6e256529ded625c8e7f856d0
So, it appears it is a feature and not a bug.
On Thu, May 7, 2015 at 3:30 AM, Chris Gilmore
wrote:
I've recently upgraded from haproxy 1.4.22 to 1.5.2.
Ever since then, I have noticed that I am now getting failed tcp connection
attempts on the remote servers. The rate is equal to the 'inter' value
(for example, 1 failed connection attempt every 2 seconds). Should I be
concerned about this? Ot
Great one :)
I was 10 seconds away from forwarding this to our web teams :)
On 01/04/2015 09:43, Willy Tarreau wrote:
Hi,
As some might have noticed, HAProxy development is progressively slowing
down over time. I have analyzed the situation and came to the following
conclusions :
- the c
Thank you very much!
Chris
> On Feb 14, 2015, at 05:19, Willy Tarreau wrote:
>
> Hi Chris,
>
> On Fri, Feb 13, 2015 at 01:02:22AM +0100, Lukas Tribus wrote:
>>> "service haproxy status" returns:
>>> haproxy dead but pid file exists
>>>
be a nice feature to have a version of the map functions
that take a default as a parameter. Something like:
map_ip_int(my_map_file, 10)
where 10 is the default returned if there is no match.
Thank you,
Chris
p.s. What do you call the %[] thing? I may be blind, but have yet to s
If it makes a difference, the stick-table in the dummy common_rate_table
backend is shared between several backends.
Thank you,
Chris
Baptiste writes:
> Hi Chris,
>
> Could you let us know why exactly you need to delay responses???
>
> Because here you propose a response (which doesn't work) to a problem
> you're facing without explaining us the problem.
> So it's hard to help.
Baptiste,
> Could you let us know why exactly you need to delay responses???
This is an API.
Unfortunately, the client behavior we are looking to address here cannot be
identified by client IP, ID, or anything else in the request. In fact, it
cannot be identified until the server has gone through consider
this possible/reasonable?
Thank you,
Chris
On 26/11/2014 00:19, Willy Tarreau wrote:
On Tue, Nov 25, 2014 at 09:33:30PM +, Chris Allen wrote:
On 25/11/2014 18:08, Lukas Tribus wrote:
I think SSL/TLS termination is the only use case where HAProxy
saturates a CPU core of a current generation 3,4Ghz+ CPU, which is why
scaling SSL/TLS
On 25/11/2014 18:08, Lukas Tribus wrote:
I think SSL/TLS termination is the only use case where HAProxy
saturates a CPU core of a current generation 3,4Ghz+ CPU, which is why
scaling SSL/TLS is more complex, requiring nbproc> 1.
Lukas
Ok that's strange then because we don't have a very co
On 25/11/2014 15:46, Emeric Brun wrote:
On 11/24/2014 05:46 PM, Chris Allen wrote:
We have a load balancer running haproxy 1.5.8. At times of heavy load
we're getting dangerously close
to running out of CPU. I'd be really grateful for some definitive
opinions on the relative merits
We have a load balancer running haproxy 1.5.8. At times of heavy load
we're getting dangerously close
to running out of CPU. I'd be really grateful for some definitive
opinions on the relative merits
of the two possible solutions detailed below - as I'm having trouble
finding detailed and consis
or trouble because
we can't tie interrupts to any particular core?
Any advice would be much appreciated. Many thanks,
Chris.
Ich kehre zurück am 08.09.2014.
Bei dringenden Angelegenheiten wenden Sie sich bitte an den Pallas
Helpdesk.
Montag-Freitag 09:00 bis 18:00 Uhr
02232-1896 96
helpd...@pallas.com
Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht
"Notificação de devolucao de cheque 25/08 08:07 (2
On 05/10/2014 09:44 AM, Willy Tarreau wrote:
Now the bind-process mess is fixed so that we now support per-listener
process binding using the "process" bind keyword, which ensures that
we won't need to change the config format during the stable release if
we want to slightly improve it. And that
On 05/07/2014 12:35 PM, Vincent Bernat wrote:
❦ 7 mai 2014 11:15 +0200, Willy Tarreau :
haproxy does not include DTrace probes by any chance right? :)
No, and I have no idea how this works either. But if you feel like it
can provide some value and be done without too much effort, feel fre
e backend connections int mode tcp
freed up sooner?
Thanks,
Chris
On 04/25/2014 05:17 AM, Willy Tarreau wrote:
No unfortunately. The starts report the*real* events and this is
extremely important. I regret that your boss will have to live with
the reality that his servers are facing !
It would be nice if there was some way from the stats socket to break
thi
http://comments.gmane.org/gmane.comp.web.haproxy/5856
'''Since we have not yet reworked the ACLs to rely on the pattern
subsystem, it's still not possible to make use of "hdr_ip(X-f-f,-1)" as
we do on the "balance" or "source" keywords.'''
Is the ACL rework mentioned for hddr_ip and a specifi
We are running 1.4.24 for an application that sees almost entirely small
http requests. We have the following timeouts:
timeout client 7s
timeout server 4s
timeout connect 4s
timeout http-request 7s
There are a significant number of cR/http-408 responses in the
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 conn
h to 'http-keep-alive' for the nginx and keep
'http-server-close' for the websockets server.
Is this a correct setup? Thanks.
Best,
Chris
On 2013-12-17 03:14, Annika Wickert wrote:
> - accesslist for statssocket or ldap authentication for stats socket
For ldap auth I presume you mean the web ui. You could accomplish this
today by proxying through httpd (or equivalent).
On 12/15/2013 09:41 PM, Willy Tarreau wrote:
- several hash algorithms are provided, and it is possible to select them
per backend. This high quality work was done at Tumblr by Bhaskar Maddala.
This is an interesting development. How do the included functions
compare to the currenlty
On 12/04/2013 11:24 AM, Chris Burroughs wrote:
On 12/03/2013 04:07 PM, Chris Burroughs wrote:
This could just be me not being adept at email patches. Sorry if this
is obvious but is this supposed to apply against 1.4 or 1.5?
To answer my own question this applies against 1.5. I'm not
On 12/09/2013 05:02 PM, James Hogarth wrote:
To answer yes it is against 1.5 ... The caveats are the peers don't work
and the session table and load balancing can get messed up due to the lack
of shared information between processes but if you just need to utilise
multiple stat sockets and the re
On 12/04/2013 02:10 AM, Willy Tarreau wrote:
We happen to have another CPU we purchased to be good with highly
>threaded Java apps: Intel Xeon CPU E5-2670 0 @ 2.60GHz
>
>It also has a L2 cache per core. This CPU has performed significantly
>better in both "many" and "a few" threaded workloads.
On 12/03/2013 04:07 PM, Chris Burroughs wrote:
This could just be me not being adept at email patches. Sorry if this
is obvious but is this supposed to apply against 1.4 or 1.5?
To answer my own question this applies against 1.5. I'm not sure of the
feasibility or desirabili
On 11/28/2013 03:10 AM, Annika Wickert wrote:
Is this a normal behaviour?
http://imgur.com/I7sRWy2
A graph of similar behavior at nbproc=3. Anecdotally the variance seems
to be higher under lower loads.
Hi James,
This could just be me not being adept at email patches. Sorry if this
is obvious but is this supposed to apply against 1.4 or 1.5?
This is also something that I think we would likely find very helpful in
1.4.
On 11/20/2013 11:32 AM, Avatar wrote:
Ou, we've been waiting it so much. Really delightful thing.
Thanks.
On Mon, Nov 18, 2013 at 9:49 PM, James Hogarth wrote:
Hi all,
We've been looking at improving the behaviour
On 11/26/2013 07:25 AM, Chris Burroughs wrote:
As far as I can tell from AMD docs and Vincent's handy /sys trick, each
of the 6 cores has a fully independent L2 cache, and the chip has a
single shared L3 cache.
I'm not sure I'm following the part about the "same part of the
On 11/23/2013 04:13 AM, Willy Tarreau wrote:
This is 25% user and 75% system. It's on the high side for the user, since
you generally get between 15 and 25% user for 75-85% system, but since you
have logs enabled, it's not really surprizing so yes it's in the norm. You
should be able to slightly
I am currently trying to migrate a somewhat over-complicated and
over-provisioned setup to something simpler and more efficient. The
application servers lots of small HTTP requests (often 204 or 3xx), and
gets requests from all sorts of oddly behaving clients or
over-aggressive pre-connecting
diff --git a/doc/configuration.txt b/doc/configuration.txt
index f2043a1..0217139 100644
--- a/doc/configuration.txt
+++ b/doc/configuration.txt
@@ -659,7 +659,7 @@ nopoll
nosepoll
Disables the use of the "speculative epoll" event polling system on Linux. It
is equivalent to the command-lin
Using 1.4.24 without USE_LINUX_SPLICE=1 results in an error when setting
'defaults option splice-auto', and maxpipes is reported as zero. This
makes sense.
With USE_LINUX_SPLICE=1 I get maxpipes == maxconn/4 as the docs say.
However, "current pipes" is always listed as 0/0, even under load.
On 11/18/2013 05:18 AM, Willy Tarreau wrote:
The typical case is a client establishing a connection, not sending anything
over it then closing (or expiring with the time out). When you run with very
short timeouts, it can be caused by request typed by hand and by network losses.
When you see the
I'm trying to track down a problem with "cR" and "CR" timeouts with
haproxy 1.4. A service I thought was nice and stable turns out to have
# 4xx/# 2xx ~= 0.2 according to hatop (which pulls in data from the
stats socket). Close to 20% client timeouts is far higher than I expected.
The logs l
A variety of nicely formatted mirrors of the docs used to be at:
https://code.google.com/p/haproxy-docs
But all such urls are now returng 403. I'm not sure if they are
"official" or not, but does anyone know what happened to them?
the best way to verify this? Will haproxy logs
show this, or do I need to perform some sort of strace on the haproxy PID
to watch it?
Thanks a million Baptiste, you are a life saver - not only to me, to but
many people on this amazing list
Sincerely,
Chris
-Chris
On Tue, Nov 12, 2013 at 12
2
mode http
stats uri /
Again, thank you very much.
Sincerely,
Chris
gth of
persistence, is that something controlled with a specific timeout variable?
Thank you so much again, I really appreciate your help a lot.
Chris
-Chris
On Tue, Oct 22, 2013 at 2:13 AM, Baptiste wrote:
> Hi Chris,
>
> My answers inline.
>
> On Mon, Oct 21, 2013 at 1
;m close, but just not sure if I'm sanely doing things. I've
tried to put piece of information together from several different posts
around the Internet, but I have found nothing that is concise enough to
really make me understand what I'm doing wrong.
Thank you SO much,
Chris
Thanks, that has cleared that up.
cheers
Chris
On 25 September 2013 16:15, Baptiste wrote:
> Hi Chris,
>
> Here is what your configuration doing:
> IF there is no 'www.' at the beginning of the Host header, then add it.
> IF there is no 'www.' at the
www.
reqirep ^Host:\ (.*)$ Host:\ www.\1 if !www_hdr
redirect prefix / code 301 if !www_hdr
If I then telnet to the haproxy I can see that the host line gets
rewritten correctly but I still get a 200 response not the expected
301.
Can anyone nudge me in the right direction please.
regards
Chris
It would be great if we could display a more usable error page than simply
the HTTP ERROR 503 users get when they hit a URL served by an haproxy
server group where all the hosts are down.
Is this possible in 1.3? I can't figure out how to do it from the
documentation.
Thanks in advance!
-Chris
Thank you *VERY* much for this tidbit Nenad.
With the early version of HAProxy we're using (v1.3.18) the actual syntax
is:
option httpclose
This worked perfectly, session afinity started performing as expected.
(Just wanted to record this for posterity)
-Chris
On Fri, Jun 14, 2013 at
Dinko Korunic wrote:
> On 18.06.2013 17:36, Chris Fryer wrote:
> [...]
>
>> I notice that each request is logged once, then logged again immediately
>> before the next request is logged. If there is no "next" request, the
>> request is logged a second ti
d. If there is no "next" request, the
request is logged a second time after a pause of between 60 and 70 seconds.
If I comment out the "log global" line from the frontend configuration,
only one request is logged.
This did not used to happen with HAProxy 1.4
Is this a bug?
C
ookie is NOT set, the request isn't printed when haproxy is
running in debug mode, and the backend "Total Sessions" doesn't increment
on the status page.
Here's our configuration, we'd sincerely appreciate any hints anyone may
have.
Thanks,
-Chris
-
global
log 1
the regrep, I am sent to the correct backend,
however this breaks what I am trying to achieve.
If someone could help me, that would be great.
Thanks,
Chris
Chris Brazier
Solutions Architect
IT
DD 020 8780 6987
E chris.braz...@capsticks.com<mailto:chris.braz...@capsticks.com>
W www.capstic
one connection.
I guess *option abortonclose* is also good to have in general, since it
helps defend against DDoS attacks? And I do not see much side-effect for
turning it on. Correct me if I'm wrong here.
Thanks again!
Regards,
Chris
On Sun, Jun 9, 2013 at 11:51 AM, Lukas Tribus
websockets, polling) do not have this problem, but
evensource transport shares the same issue.
Any idea what causes this? Thanks!
Regards,
Chris
That's AWESOME! Can't believe I didn't think of that, thanks a lot
guys :)
Chris
On 30/04/2013 13:53, PiBa-NL wrote:
Hi Chriss,
That seams possible already.?.
If you have the configuration for SSL offloading configured already
all you need to add is the "ssl&quo
1 - 100 of 187 matches
Mail list logo
